この構成では、ZimaOSをアプリケーションサーバーとして使用し、すべてのメディアを既存のUnraid NASに保存していました。Plex、Emby、OpenWebUIはZimaOS上で動作し、当初はリモートデータに正常にアクセスできていました。しかし、約1週間後、そして再起動後にも、アプリケーション環境からネットワーク共有が消えました。Filesで再接続し、アプリを再起動するとアクセスが復旧しました。
これは、「コンピュートノード＋別NAS」の構成で重要な設計上の境界を示しています。Filesアプリで見えるネットワークロケーションは、再起動や再接続のイベントを経ても、すべてのDockerコンテナが依存できる永続的なホストマウントと自動的に同じものになるわけではありません。
リモート共有が消えたため、アプリからメディアにアクセスできなくなった
PlexやEmbyでデータベース障害が発生したという報告はありませんでした。単に、Unraid上のデータを指していたパスへのアクセスを失っただけです。ユーザーが共有を再追加すると、アプリケーションは再構築または再スキャンを開始しました。
これは、破損したPlexまたはEmbyのインストールではなく、ストレージへの到達性の問題である可能性を示しています。
FilesへのアクセスとDockerボリュームへのアクセスは異なる層である
ZimaOSのFilesは、SMB経由でLANストレージに接続できます。この接続により、ユーザーはWebインターフェースからファイルを参照したり移動したりできます。
Dockerアプリケーションには、コンテナの起動時にも利用可能な状態が維持されるホストパスが必要です。基盤となるネットワークマウントが消失したり、異なるライフサイクルで再作成されたりすると、Filesが後から再接続できる場合でも、アプリからはパスが空、または存在しないように見えることがあります。
UUIDに関する助言は、通常のSMB共有には当てはまらない
ある返信では、「UUIDを使って」マウントすることが提案されました。別の参加者は、リモートのUnraid共有はローカルのブロックデバイスではなく、IPアドレスとSMBを使って接続されていると正しく指摘しました。
UUIDは、ローカルファイルシステムやブロックデバイスを識別するのに便利です。SMB共有は、ネットワークサーバーと共有パス、認証情報、マウント設定によって識別されます。
コミュニティから/etc/fstabが提案された
別の参加者は、/etc/fstabで永続的なSMBマウントを設定したところ、安定して動作していると述べました。これは一般的なLinux管理手法であり、機能する可能性はありますが、あくまでコミュニティからの助言であり、元の投稿者は最終的に動作する構成を確認していません。
アプライアンス型OSでは、ホストのマウント設定を手動で行うことは、起動順序、認証情報、再接続の挙動、アップデート間の互換性についても自分で管理することを意味します。
現在のZimaOSでも、FilesでLANストレージを利用できる
IceWhaleの最新ドキュメントでは、FilesのサイドバーからLANストレージを追加し、リモートNASのIPアドレスと認証情報を入力する方法が示されています。これは、別のNASからデータを参照または移行するためのサポート対象の方法です。
ファイルへのアクセスや移行が目的の場合は、現在のLANストレージ接続手順を使用してください。
アプリ用の永続的なマウント方法がサポート対象として確立されたわけではない
IceWhaleの開発者から、「このSMB共有をDockerアプリ用に永続的にマウントする方法」という文書化された手順は返信されておらず、元の投稿者も、Filesでの接続が確認されたライフサイクル全体を通じて維持されることに懐疑的なままでした。
そのため、確定的な記事では、コミュニティから提案されたfstabの方法を公式の解決策として扱うのではなく、この未解決の状態を維持する必要があります。
メディアサーバーでは、安定したマウント境界をどこに置くか決める
電源障害後にPlexやEmbyを自動的に復旧させる必要がある場合、リモートメディアのパスはコンテナの起動前にマウントされ、再接続中も安定して利用できなければなりません。これは複数のLinuxアーキテクチャで実現できますが、具体的な方法は現在のZimaOSリリースでテストする必要があります。
常時稼働する重要な構成では、ストレージパスを本番環境で利用可能と判断する前に、コールドブート、リモートNASの再起動、スイッチの再起動、一時的なネットワーク停止を確認してください。
不要なメディアの再スキャンを防ぐ
メディア共有が一時的に消えると、ライブラリ設定によっては、PlexやEmbyがそれをコンテンツの削除と解釈することがあります。リモートマウントの挙動が安定していると確認できるまでは、ライブラリの自動削除を伴うクリーンアップを無効にしてください。
リモートNASのアプリ用マウントに関するFAQ
Filesで共有に再接続すると、アプリも復旧しましたか？
ユーザーからは、共有に再接続してアプリを再起動するとアクセスが復旧したと報告されています。
SMB共有をファイルシステムUUIDでマウントできますか？
ローカルディスクと同じ意味ではできません。SMBでは、ネットワーク共有のパスと認証情報を使用します。
このスレッドで、IceWhaleはDockerアプリ用の永続的なマウント修正を確認しましたか？
いいえ。公開スレッドは、そのような回答がないまま終了しました。
