このコミュニティのヒントは、非常に具体的な外部ストレージ障害について説明しています。NVMeドライブは正常にマウントされ、Plexでメディアを再生できていましたが、約10分間操作しないとマウントが消失しました。再接続するか手動で再マウントすると、アクセスが復旧しました。
ここで役立つ教訓は、単に「exFATを使わない」ということではありません。このスレッドが示しているのは、Plexで似たような症状を引き起こす可能性のある、次の3つの別々の層です。エンクロージャーのファームウェアによるスリープ、LinuxのUSB自動サスペンド、そしてファイルシステムおよびマウントの復旧動作です。
Plexの「ファイルが見つかりません」はPlexの外部から始まる可能性がある
Plexが認識しているのは、指定されたライブラリフォルダーだけです。公式のPlexライブラリの作成では、メディアフォルダーにサーバーから継続的にアクセスできる必要があります。USBブリッジが切断され、マウントポイントが消失すると、基盤となるストレージパスが存在しなくなるため、Plexはメディアが見つからないと報告します。
NASメディアセンターガイドは、通常のZimaOS Plex構成を理解するのに役立ちます。一方、Plexハードウェア要件では、メディアサーバーの負荷要件と、切断を繰り返すストレージエンクロージャーの問題が区別されています。
エンクロージャーのスリープとLinuxの自動サスペンドは別のもの
元の投稿者は、ORICOエンクロージャー自体がアイドル状態になると「インテリジェントスリープ」に入ったと報告しています。Linuxにも、これとは独立したUSB電源管理層があります。LinuxのUSB電源管理によると、power/control=autoではUSBの自動サスペンドが許可され、onではそのデバイスに対するカーネル主導の自動サスペンドが防止されます。
したがって、Linuxの自動サスペンドを無効にしても、エンクロージャーのファームウェアが独自の強制スリープポリシーを実装している場合、問題が解決するとは限りません。これは切り分けテストとして使用し、USBブリッジが正常である証拠とは考えないでください。
ext4がexFATより安定しているように見える理由
このスレッドでは、exFATよりもext4のほうが復旧動作が良好だったと報告されていますが、exFATが切断の原因だったことを証明する管理されたテストは行われていません。ファイルシステムの選択は、物理的なUSBブリッジとスリープ動作を把握した後に検討する変数の1つとして扱ってください。
ドライブをコンテナからも使用する必要がある場合は、外部ドライブのマウント手順で、アプリケーションがそのパスを利用する前に、ホスト側の安定したマウントポイントが必要な理由を説明しています。
より安全なトラブルシューティングの順序
- USBデバイス全体が消えているのか、それともPlexだけがライブラリを失っているのかを確認します。
- アイドル時間が経過した後も、マウントポイントが存在しているか確認します。
- LinuxのUSB自動サスペンドと、エンクロージャー側のスリープを分けてテストします。
- ハードウェアの復帰動作を把握してから、ext4とexFATを比較します。
- 常時稼働するメディアライブラリには、Linux環境で確実に復帰するエンクロージャーを優先します。
結論
このコミュニティの事例は、Plexのライブラリ障害として表面化した、エンクロージャーの復帰問題として理解するのが適切です。exFATによって復旧の信頼性が低下した可能性はありますが、ファイルシステムを変更してもファームウェアレベルのスリープを無効にすることはできません。常時稼働するZimaOSメディアサーバーでは、アイドル状態になった後も安定して動作し続けるUSB/NVMeブリッジを優先してください。
