Plex、Radarr、Sonarr、またはその他のDockerアプリが、ZimaOSの再起動後に毎回リモートSMB NASへのアクセスを失う場合は、アプリケーションを変更する前にホスト側のマウントを確認してください。コンテナからネットワーク共有を参照できるのは、ZimaOSが正常にマウントし、Dockerのバインドパスがそのマウント先を引き続き指している場合に限られます。
Synologyの共有に関するコミュニティ事例では、Docker Composeのパス選択画面で同じフォルダーを再度選択するたびに復旧していました。これはマウントまたはパスの永続化に関する問題を強く示唆しますが、ZimaOSが常に新しい内部マウントIDを生成していたというフォーラムの説明は、IceWhaleが確認した根本原因ではなく、コミュニティによる推測でした。そのため、適切なガイドではマウント、パス、起動順序をそれぞれ個別にトラブルシューティングする必要があります。
まず、再起動後にSMB共有がマウントされているか確認する
PlexやRadarrを開く前に、ZimaOSのFilesを開いてリモートNASの共有を参照してください。共有自体を利用できない場合、Dockerアプリは最初に確認すべき問題ではありません。
共有が見つからない場合
リモートNASがオンラインであること、IPアドレスまたはホスト名が引き続き解決できること、SMBが有効になっていること、保存済みの認証情報が有効であることを確認してください。必要に応じて、ZimaOSのネットワークストレージワークフローから共有を再接続します。
共有がFilesに表示される場合
次にDockerのマッピングを確認します。ホスト側のマウントは存在していても、アプリケーションが古いパスや利用できないパスを参照している可能性があります。
手書きのfstabエントリではなくZimaOSのネットワークストレージを使用する
元のユーザーは編集を検討しました /etc/fstabこれは、すでにUIでネットワークストレージを管理しているアプライアンス型OSで、最初に行う対処としては最適ではありません。
現在のZimaOSドキュメントでは、移行およびネットワークストレージのワークフローの一環として、SMBを使用して別のNASにアクセスする方法が示されています。まずはこの管理された手順を使用し、ZimaOSが認証情報とマウント状態を一貫して管理できるようにしてください。
ZimaOS NAS移行ガイドに、最新の手順が記載されています。
コンテナーパスだけでなく、Dockerのホストパスを確認する
Dockerのボリュームマッピングには2つの側があります。
- ホストパス： ZimaOSがマウントされたSynologyフォルダーを認識する場所。
- コンテナーパス： Plex、Radarr、またはSonarrがコンテナー内で認識する安定したパス。
再起動後にホスト側が無効になっている場合、アプリのUIではコンテナーパスが正しく見えていても、実際には何もない場所を指している可能性があります。
現在のZimaOS Dockerパスガイドでは、この違いについて説明しています。
診断テストとしてフォルダーを一度選び直す
Filesでリモート共有が表示されるのにアプリからアクセスできない場合は、アプリまたはComposeの設定を開き、ZimaOSのパス選択画面でホストフォルダーを選び直してください。
認証情報やコンテナーパスを変更せずにアクセスがすぐ戻るなら、問題が管理対象のマウントとDockerのバインドマッピングの間にあるという強い証拠です。
再起動するたびに起動順序を確認する
リモートSMBストレージは、ネットワーク、DNS/IPへの到達性、認証、そしてNASの準備が整っていることに依存します。Dockerコンテナーは、リモートマウントが利用可能になるよりも先に起動する場合があります。
簡単なテスト
- ZimaOSを再起動する。
- Filesでリモート共有を参照できるようになるまで待つ。
- 影響を受けたDockerアプリだけを再起動する。
- メディアまたはダウンロードが戻っているか確認する。
それが安定して機能するなら、パスは安定しており、実際の問題はマウント識別子の変更ではなく、起動タイミングにある可能性があります。
両方のシステムで権限を確認する
SMBマウントに使用するSynologyアカウントには、メディアフォルダーへのアクセス権が必要です。次に、ZimaOSのマウント先にはDockerプロセスからアクセスできなければなりません。最後に、アプリケーションでは正しいコンテナーパスを使用する必要があります。
権限の問題はマウントがない場合と似て見えることがあるため、「permission denied（権限が拒否されました）」と「path not found（パスが見つかりません）」または「no such file（そのようなファイルやディレクトリはありません）」を分けて確認してください。
fstabを手動で変更すると、復旧が難しくなる理由
カスタムマウントでは、ZimaOS の UI で管理されない認証情報ファイル、起動時の依存関係、タイミングフラグ、障害時の動作が発生する可能性があります。そのカスタムマウントが起動時に失敗すると、アプリは空のディレクトリを対象に起動してしまうことがあります。
使用 fstab 管理対象のネットワークストレージワークフローでは要件を満たせず、アップデート後もマウントを維持する準備ができている場合に限ります。
メディアアプリの回復性を高める方法
- 安定した NAS の IP アドレスまたは信頼できるローカル DNS 名を使用してください。
- リモート共有はネットワークストレージで設定した状態を維持してください。
- 1 つの安定したホストフォルダーをコンテナにマッピングします。
- Radarr、Sonarr、ダウンロードクライアント、メディアサーバーでは、同じコンテナパスを一貫して使用してください。
- アップデートやストレージの変更後は、アプリケーションのライブラリを変更する前にマウントを確認してください。
LAN トラブルシューティングガイドは、障害がネットワーク層で発生しているかどうかの切り分けに役立ちます。一方、Docker パスの基礎では Docker のコンテキストを確認できます。
よくある質問
ZimaOS の再起動後、Docker アプリが Synology 共有を失うのはなぜですか？
最も可能性が高いのは、SMB 共有が再マウントされていない、アプリが古いホストパスを使用している、またはリモート共有の準備が整う前にコンテナが起動している、という問題です。それぞれを個別にテストしてください。
/etc/fstab を編集すべきですか？
最初の対処としてはおすすめしません。共有をシステムに管理させるため、ZimaOS のネットワークストレージを優先してください。手動マウントでは、メンテナンスや起動順序が複雑になります。
同じフォルダーを再選択すると、なぜアプリが直るのですか？
ホスト側のバインドマッピングが更新されます。表示されるフォルダー名が変わっていなくても、これはマウントまたはパスに問題がある証拠です。
Plex や Arr アプリでリモート SMB 共有を使用できますか？
はい。ZimaOS が安定してマウントし、権限が正しく、すべてのコンテナでホスト側とコンテナ側のパスが一貫していれば使用できます。
