
このページのスレッド一覧(全787スレッド)

内容・タイトル | ナイスクチコミ数 | 返信数 | 最終投稿日時 |
---|---|---|---|
![]() |
3 | 0 | 2021年12月3日 02:24 |
![]() |
0 | 1 | 2021年12月25日 09:18 |
![]() |
2 | 0 | 2021年9月21日 10:10 |
![]() |
2 | 4 | 2021年9月20日 17:39 |
![]() |
4 | 9 | 2021年8月14日 23:44 |
![]() |
0 | 2 | 2021年8月2日 14:05 |

- 「質問の絞込み」の未返信、未解決は最新1年、解決済みは全期間のクチコミを表示しています


NAS(ネットワークHDD) > WESTERN DIGITAL > WD Cloud WDBAGX0020HWT
【2022年1月15日をもちまして、WD Cloud OS 5対応デバイスでは、WD Cloud OS 3を含む前世代のWD Cloud OSのサポートは終了】
とのことで、WD Cloud OS 5に更新しましたが、WD CloudのOS2アカウントからOS5アカウントへの切り替えでつまづきました。
どうしてもアカウントを登録できないので調べたところ「パスワードが単純すぎた」のが原因でした。エラーにその旨はでないのですがシステムログにはちゃんと理由が出ているそうです。
di = 8cwWl0V6XB info adminUI:{"msgid": "cloud_access_page"、 "corid": "AUI:5c6acdd6-3aaa-47df-a122-68da91a5d2d2"、 "function": “ create_cloud_account”、“ message”:{“ message”:“管理者ユーザーがクラウドアカウントを作成できませんでした。”、“ response”:{“ name”:“ PasswordDictionaryError”、“ message”:“ Password is too common”、“ code”:“ invalid_password”、“ description”:“パスワードは許可されていません。一般的すぎる可能性があります。”、“ statusCode”:400}}}
3点



TS-253Dです。
オペレーティングシステムQTS 5.0.0.1853 build 20211114ではWordPressとMySQLアプリがありません。
一つ前のQTS 4.5.4.1800 build 20210923ではWordPressはありますがMySQLはありません。
phpadminは存在するのでMySQLの代わりにMariaDB5.5.57を有効にしたらWordPressが稼働しました。
最新ファームウェアにWordPressアプリが無いのは残念です。
詳細はここに記述。
http://odwrsrv.mydns.jp/chi2npui2/qnap-nas-%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc%e3%82%92ts-253d%e3%81%ab%e6%9b%b4%e6%96%b0/
0点




NAS(ネットワークHDD) > IODATA > HDL-C1.0
ルーターに繋いで、簡易NASのように使用していました。思えば結構長い間使用していたのですが、昨日、再起不能となりました。
電源部がダメになったようですが、約10年、電源は入りっぱなしでしたので仕方ないですね。
データのバックアップを取っていなくて焦ったのですが、HDDを取り出して安い汎用のケースに入れたところあっさり認識し、データを助け出せました。
HDDの診断をすると、ここまで9万時間ほど使用していたようです。電源の起動回数は88回と少なかったです。
思えば、電源が切れなかったり、簡易NASが不安定だったりと怪しい挙動が多かったです。
しかし、よく持ってくれたと思います。
HDDはサムスン製が入っておりました。以上、報告でした。
2点



NAS(ネットワークHDD) > QNAP > TS-451D2-4G
ノーマルのメモリーは4GBなのですが、同規格のメモリーで8GB×2枚の16GBはbootしませんでした。
ノーマルメモリーはADATA製 DDR4 2666 PC4-21300の4GBですが、試したのはADATA製 DDR4 2666 PC4-21300の8GB×2枚です。
システムでチェックが入ってしまった?ようなので、4GBの2枚で我慢ですね。
書込番号:24351364 スマートフォンサイトからの書き込み
0点

CPUのメモリコントローラが、最大8GBですね。
https://ark.intel.com/content/www/jp/ja/ark/products/197307/intel-celeron-processor-j4025-4m-cache-up-to-2-90-ghz.html
書込番号:24351395
2点

ありがとうございます。
CPUの制限でしたか…。
それは残念でした。
この場合は、8GBの一枚差しでも動かなかったんですが、一枚差しでもシングルだとダメなのでしょうか?
出荷時は4GBの一枚差しでした。
書込番号:24352116 スマートフォンサイトからの書き込み
0点

>JGBY32さん
別機種のTS-453D(Celeron J4125)では、Dual Rank(2Rank)での動作報告はいくつかネットで見た気がします。
逆にSingle Rank(1Rank)のメモリーではダメだったという情報も見た気がします。
QNAPの仕様でも8GBまでですし、他社メモリーでの使用の場合はサポートしてくれない場合もありますので
元のメモリーは保証期間がすぎるまでは、手元に残されるのが無難かと思います。
書込番号:24352150
0点

>たく0220さん
ありがとうございます。そうなんですよね。チラホラ8GB二枚差しで動作したって見ますので出来るのかなと思ってしまいました。
とりあえず、ノーマルと同じと思われる4GBを一枚オーダーしましたので、4GB+4GBで使ってみます。
書込番号:24353135 スマートフォンサイトからの書き込み
0点



NAS(ネットワークHDD) > QNAP > TS-453BT3-8G
2021年7月の最新ファーム(4.5.4.1741)の一つ前あたりのファームに更新したあたりから、管理画面にファイルシステムフル(/)の警告が出るようになり、いつの間にか管理画面にもアクセスできなくなりました。利用者側環境はいじっておらず変更点はなし。
ファームを疑い、サポートチケット発行して対応してもらいました。
切り分けで最新ファームファイルを改めて適用したが、ブートプロセスの表示がブート中のまま、でも実はNASとしては稼働している状態に陥りました。
フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。
サポートでは、ターミナルで状況を見させてくれというので、TeamViewerで画面共有して、ファイルシステム見てくれました。
以前、似たようなバグがあったそうですが、ファームが最新でなおっているはずなので技術者チームに連携して確認してくれるようです。
早く問題解決することを願うばかりです。メインで使っていなくてよかった。
ここからは単なる私見
仕事柄、台湾のソフトウェア開発チームとやりとりしますが、開発しているのは大陸。というパターンが多いです。QNAPはどうなんでしょう。
日本でも、大手SIerの先は中小、またその先は大陸。よくあります。コミュニケーションの問題も発生しやすい。
面倒なバグで長らく苦しんでいると、結局はOS(今回はLinux)のバグだったというあるある話もありますし、ちょっとしたところを手直しするサイレントチェンジしたところで躓くのはよくあることなので、気長に待つことにします。
0点

経過を読んでみると、ソフトウェア製品が未完成のまま
売られていて、なので、サポートが必要、という典型のようです。
RMAプロセスを訴求するのは、検査が半端なものを出荷しているからでしょう。
書込番号:24282727
1点

『いつの間にか管理画面にもアクセスできなくなりました。』
という状態ですと、
『管理画面にファイルシステムフル(/)の警告が出るようになり、』
エラーメッセージを画面キャプチャーでアップロードできませんか?
「ファイルシステムフル(/)」ということですと、内蔵HDDの空きエリアが無い状態のようですが...。
『フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。』
「強制的に電源OFF-ON」してしまうとファイルシステムの破壊などにより、起動不可となる可能性もあるかと思います。
「ファイルシステムをチェック」で自動修復できれば良いのですが、状況によっては自動修復できず、マウントもできない状態も予想されます。
『
NAS システムログに [File system is not clean ( ファイルシステムが乱れています)] と表示されるのはなぜですか?
「ファイルシステムに問題があります」というメッセージは、データを含んでいるボリュームが正しくアンマウントされなかった場合に表示されます。これは次のような状況で起こります。
』
https://www.qnap.com/ja-jp/how-to/faq/article/nas-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%AD%E3%82%B0%E3%81%AB-file-system-is-not-clean-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%8C%E4%B9%B1%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99-%E3%81%A8%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B
書込番号:24283518
1点

>ZUULさん >LsLoverさん
私のためにお時間を割いていただきありがとうございます。感謝いたします。
>ZUULさん
私見ですが、ファームウェアの更新回数がNETGEARのそれと比にならない位多いですね。
機能数が違いますので簡単に比較することはできませんが、ユーザからの故障申請に対応して品質を上げていく手法、"シフトライト"なのかも知れません。いや、リリース後ですから、シフトライトのさらに右ですね。 あっ、人柱かも(苦笑)。 にしては結構なお値段。
シフトレフトの方が、みんなが幸せになれるのですが、拙速を旨とする競争の世界では致し方のないことかも知れません。
あと、ひょっとするとエラー発生時のリカバリ実装がそれほどでも無いのかも知れません。
>LsLoverさん
fsckのおすすめ、ありがとうございます。早速実行し、無事完了しました。
管理画面に出でくるファイルシステムフルの表示は簡易なもので起きたこと最小限のことを伝えています。
裏で、FULL.logとしてdf,duの出力結果が格納されていました。(最下部に貼ります。文字数の関係で抜粋です)
/var/log/qulog/mariadb.err のサイズが大きいです。
事象発生以前の何らかのオペレーションをきっかけに、リカバリ実装のないところで不具合が生じたのかも知れません。
qfullなるアプリを入れて、リモートセッション有効にして待ち状態です。
----ここからFULL.log抜粋-----
=== df output ===
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /
devtmpfs 3.8G 12.0K 3.8G 0% /dev
tmpfs 64.0M 2.8M 61.2M 4% /tmp
tmpfs 3.8G 188.0K 3.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
/dev/mmcblk1p5 7.7M 46.0K 7.7M 1% /mnt/boot_config
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 57.4M 436.1M 12% /mnt/HDA_ROOT
cgroup_root 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/CACHEDEV1_DATA
/dev/md13 417.0M 390.3M 26.7M 94% /mnt/ext
tmpfs 1.0M 0 1.0M 0% /share/external/.nd
tmpfs 1.0M 0 1.0M 0% /share/external/.cm
tmpfs 1.0M 0 1.0M 0% /mnt/hm/temp_mount
tmpfs 48.0M 88.0K 47.9M 0% /share/CACHEDEV1_DATA/.samba/lock/msg.lock
tmpfs 16.0M 0 16.0M 0% /mnt/ext/opt/samba/private/msg.sock
tmpfs 8.0M 0 8.0M 0% /var/syslog_maildir
tmpfs 16.0M 0 16.0M 0% /share/NFSv=4
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/NFSv=4/Public
hdsfusemnt 16.0M 0 16.0M 0% /share/CACHEDEV1_DATA/.qpkg/HD_Station/share
/dev/mapper/vg1-lv1312
1.8G 1.1M 1.8G 0% /mnt/pool1
/dev/mapper/vg1-snap10003
14.1T 5.3T 8.8T 37% /mnt/snapshot/1/10003
tmpfs 512.0M 115.7M 396.3M 23% /mnt/.fw_update_dir
/dev/mmcblk1p2 216.9M 206.0M 11.0M 95% /root/FLASH_RFS1
/dev/mmcblk1p3 216.9M 206.0M 11.0M 95% /root/FLASH_RFS2
/dev/mmcblk1p6 3.9M 39.0K 3.8M 1% /tmp/nasconfig_tmp
=== du output ===
6.8M /usr/local/bin
--省略--
104M /var/log/qulog/mariadb.err
104M /var/log/qulog
107M /var/log
--省略--
108M /var
4.4M /bin
401M /
----ここまでFULL.log抜粋-----
書込番号:24283840
0点

『----ここからFULL.log抜粋-----
=== df output ===
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /』
root(/)パーティションが400MBすべてを使用している状態のようです。
以下の内容は、参考になりませんか?
ファイルシステムの設計時に何故400MBに設定したんだろう...?
『
"No space left on device" msg although there is space free #3994
I just had a very similar issue with my qnap nas.
Running a simple borg info resulted in "No space left on device".
How to fix:
Check free space with df -h
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 32.0k 100% /
After running rm -r ~/.cache/borg/
Filesystem Size Used Available Use% Mounted on
none 400.0M 207.9M 192.1M 52% /
Change cache dir to fix the problem
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables
You should use something in /share/CACHEDEV1_DATA as your cache dir
』
https://github.com/borgbackup/borg/issues/3994
『
General
Borg consists of a number of commands. Each command accepts a number of arguments and options and interprets various environment variables. The following sections will describe each command in detail.
』
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables
書込番号:24284006
1点

>LsLoverさん
ありがとうございます。
サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
推移という意味で、4-5時間で
前 none 409600 298760 110840 73% /
今 none 409600 302508 107092 74% /
と徐々に増えていってます。うまいことログローテイトの機能(に類似のもの含めて)が働いていれば、問題はないのでしょうが、そこまで見てみる余裕が今はないのが悩ましいところです。
/を400Mとしたのは、足りると思ったのでしょうね。または、組込としての容量制限とか…
一杯にならないよう、余裕のあるパーティションに逃すのも一手ですね。
開発チームがどういう見立てをしてくるのか楽しみではあります。
書込番号:24284512
0点

『サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
推移という意味で、4-5時間で
前 none 409600 298760 110840 73% /
今 none 409600 302508 107092 74% /
と徐々に増えていってます。』
具体的にどのディレクトリのデータがroot partition(/)を圧迫しているのか不明ですが、前73%->今74%と使用率が増えていることが気がかりです。
書込番号:24284631
1点

>LsLoverさん
ありがとうございます
ルートパーティションだと、どのファイルが増えているか、マウントテーブルで対象外除外しつつ探すと地味に時間がかかりますね。
ざっと見てみたところでは、
/var/log/qulog/mariadb.err
/var/log/qulog/qulogd.log
が地味なサイズながら着実に増えていってます。qulogd.logはログローテイトしていますね。
crontab見てみます。久しぶりなので、思い出すのに時間がかかりそうです。
他にもサイズ増えているファイルありそうな気がします。
mariadb.errは
YYMMDD hh:mm:ss [ERROR] qulogdb: Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed
qulogd.logは
YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
数十秒間隔で出ています。データベーステーブル壊れているみたいですね。壊れ方にもよりますがリペアするだけで済みそうな気が…
QNAPサポート、このログまで収集していったはずなので、次のアクション指定がどうなるか、期待しつつ待つことにします。
(設定バックアップして、シャットダウン。HDD外して再起動してリセット、その後は復旧手順 といったところでしょうか。)
QNAP NAS Community Forumにも似た投稿があるようです。
サポートとのやり取りですが、何故か英語で始まってしまったので、ずっと英語で時々google先生のお世話になりながらやりとりしています。
最初から日本語ならば、日本語ができる人がアサインされるようですが、途中からだとバトンタッチしてくれないようです。お願いしたけど、スルーされました。人員数の関係でしょうか。日本市場のスケールでは仕方ないかも知れません。
Forum等が充実しているIT機器のサポートの場合、サポートより自身の調査の方が、結論に先に辿り着いてしまうことが少なくないと感じています。(内外問わずですが… )
かといって、個人が知りうる情報は限られていますので、サポートの解析を待とうと思っています。
書込番号:24286328
0点

追記
QuLog Centerが本日(つい先ほど)リリースされインストールしたところ、mariadb.errのログは出力されなくなり、qulogd.logの
YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
が出力され続けています。
書込番号:24287010
0点

一度投稿しましたが、消えていたので再投稿(申し訳ないですが、思い出すのも面倒なので一部だけ)します。
トラブル事象は無くなったとサポートから連絡がありました。
無くなったとはいっても、実際は一次対処しただけです。/dev/nullにリンクしログを捨てているだけです。
/var/log/qulog/配下
前 -rw-rw---- 1 admin administrators 1184541 2021-08-12 21:37 mariadb.err
後 lrwxrwxrwx 1 admin administrators 9 2021-08-13 11:08 mariadb.err -> /dev/null
パーティションフルを出なくした、という意味では解消ですが… 個人的には、穴ほって埋めて隠されたといった感じです。
正常動作しない機能がないことを祈ってます。
書込番号:24290109
0点



NAS(ネットワークHDD) > Synology > DiskStation DS418j
ご存知でしたら、アドバイスお願いします。
Plasystation3を接続したTVで、Synology DS418jに保管した動画をDLANを活用して閲覧しています。
最近DSM7.0にUpdateしたところ、フォルダリストの表示順序が不規則になってしまいました。
Windows上での表示と異なり、一部はそれっぽく規則的になっていますが、気持ちが悪い表示順序となってしまいました。
再インデックスも実行してみましたが、改善されません。
サポートにも「DSM7.0にUpdateしたら状態が変わった!」っと問い合わせしてみましたが、公開されているサポート情報の連絡と、「Playstation3側の問題です!」っと返事があったのみ…
「今時Playstation3?」と言われそうですが、我が家ではDLANで大活躍中です。
お手数ですが、何か対策方法をご存知でしたら、アドバイスよろしくお願いします。
0点

>セロリが苦手なパパさん
サポートの言う事も間違いではないんです。
どのPCも同じですが、整理整頓されて順番に保存されているわけではないのです。
バラバラに保存されていて、読み出す時に読み出す側の指定通り表示しています。
わかりやすく言えば、
「ファイル名だけ呼び出し、名前順に表示」
「ファイル名、制作日時を呼び出し、制作の古い順に表示」
「指定日に保存されたファイルだけ呼び出して名前順表示」
等いろいろあります。
ただ、サーバー側にも、表示を変えることも出来ます。
具体的には、PS3なら名前表示、携帯なら古い順 といった感じです。
また、そのファイルの明細情報を取得しその順番で並び替えることもできます。
取得出来るかどうかはわかりませんが、「公開日時順」だったり「製作者順」だったりも可能かもしれません。
DSMのマニュアルを見ましたが
「動画情報を自動的に取得:インターネットから取得したメタデータ ( ポスター、字幕、その他の動画詳細) で動画を識別。情報の取得のためには、ビデオ情報プラグイン機能を有効にします。
([Video Station] > [ 設定] > [ 詳細設定])。
とあるので、それで治るような気がしますが、前回の表示がどうなのかわからないのでいろいろやってみるしかないかもしれません
参考になれば幸いです
書込番号:24269459
0点

テキトーが一番さん、早速のアドバイスありがとうございます。
Update前のDSM6.2では、何も問題がなく綺麗にWindowsと同じくフォルダが昇降表示されていました。
それがDSM7.0にUpdateしたとたん、表示順が変化したので、何かしらUpdateが影響しているのではないか??っと疑ってました。
メーカーにも何かDefaultの設定が変更されてませんか??っと質問したのですが、特に回答もなく…
アドバイスをいただいた、Video Stationの設定を早速試してみます。
書込番号:24269508
0点


クチコミ掲示板検索
新着ピックアップリスト
-
【欲しいものリスト】冬ボーナスで買うもの
-
【欲しいものリスト】メインアップグレードv4.23
-
【欲しいものリスト】予算23万程度
-
【みんなでランク付け】5年持つ?コスパ配慮AMDゲーミングPC構成締切:あと2日
-
【欲しいものリスト】イヤホン
価格.comマガジン
注目トピックス

(パソコン)
NAS(ネットワークHDD)
(最近3年以内の発売・登録)





