元の問題は、パスが消えることよりも危険でした。再起動後、Synology の SMB 共有が実際にマウントされる前に SABnzbd が起動する可能性がありました。コンテナからは想定されたホストパスにディレクトリが存在しているように見えるため、ダウンロードが完了して正常に移動したように見えても、実際にはリモート NAS ではなく、ローカルの ZimaOS ストレージに保存されていることがありました。
コミュニティでは最終的に、CIFS/fstab を手動で設定する動作する解決策が構築され、元の投稿者も再起動後にマウントが維持されることを確認しました。ただし、リスクも実証されています。無効な fstab エントリによって通常の起動が妨げられる可能性があり、エスケープされていないスペースを含むマウントポイントは設定を壊しました。これらのコマンドは、現在の ZimaOS 公式ネットワークストレージ手順ではなく、情報源で確認されたコミュニティによる管理方法として扱ってください。
根本的な障害はマウントのタイミングでした
情報源にあったパスは次のようなものでした。
/media/192.168.2.125/Movies再起動後、SABnzbd の起動時には SMB マウントの準備ができていませんでした。システムが安定した後に同じボリュームを再追加すると再び動作したため、マウント ID が変わったというより、タイミングや起動順序の問題である可能性が強く示されました。
リモートマウントがないと、ローカルディレクトリに誤って保存されることがあります
Docker に、リモートファイルシステムが存在しない状態でもローカルに存在するホストディレクトリのパスを渡すと、アプリケーションがそのローカルディレクトリに書き込むことがあります。ログにはファイルが /movies に移動したと表示されても、Synology には何も表示されない場合があります。
大容量のダウンロードを開始する前に、マウントポイントのディレクトリが存在するだけでなく、想定したリモートファイルシステムが実際にマウントされていることを確認してください。
コミュニティではマウント先を安定した /DATA パスに移しました
提案された構成では、SMB 共有を次のような安定したローカルパスにマウントします。
/DATA/Media/Moviesその後、この安定したホストパスを SABnzbd に割り当てます。これにより、リモートファイルシステムをホスト側で管理しながら、コンテナ内のパスを予測しやすくできます。
情報源のユーザーは /etc/fstab が再起動後も維持されることを確認しました
コミュニティの例では、_netdev、特定の SMB ダイアレクト、UID/GID、モード値などの CIFS オプションを使用していました。ユーザーは、fstab のエントリが維持され、再起動後も動作したと述べています。
保護された認証情報ファイルの使用を検討せずに、認証情報を誰でも読み取れる設定ファイルへ直接記載しないでください。
無効なエントリで起動が妨げられた後、nofail が重要になりました
情報源のユーザーは、無効または利用できないマウントによって起動に支障が出る可能性があることを発見しました。返信では、リモート NAS が利用できない場合でも ZimaOS が起動を続行できるよう、nofail を指定することが推奨されました。
_netdev は、これがネットワークに依存するマウントであることをマウントシステムに伝えます。
マウントポイントのスペースは正しく処理する必要があります
2 つ目の fstab エントリは、マウントポイントに TV Shows が含まれていたため失敗しました。fstab では空白がフィールドの区切りに使われるため、スペースは適切にエスケープするか、TV_Shows のようなシンプルなディレクトリ名を使用して避ける必要があります。
その後、元の投稿者はスペースを含まない別のフォルダーを使用し、正常に動作させました。
再起動前には必ず mount -a でテストしてください
情報源で推奨されていた安全な手順は次のとおりです。
sudo mount -aエラーが返された場合は、再起動する前に fstab の構文やパスを修正してください。また、マウントされたファイルシステムに想定したリモートファイルが含まれていることも確認してください。
用途に合う場合は、現在の ZimaOS ネットワークストレージを優先してください
現在の ZimaOS では、ファイル機能やネットワークストレージのワークフローを通じて SMB/LAN ストレージに接続できます。アプリに必要な永続性や起動順序を提供できる場合は、まず管理されたインターフェースを使用してください。
現在の Synology SMB 接続ワークフローを参照してください。
本当に堅牢なコンテナは、リモートマウントが確認されるまで書き込みを行いません
fstab を使用していても、ネットワーク NAS が後からオフラインになる可能性があります。重要なダウンロードやインポートの処理では、SABnzbd がジョブを処理する前にリモートの保存先がマウントされていることを確認するヘルスチェック、起動時チェック、または運用手順を追加してください。
SABnzbd SMB マウントに関する FAQ
情報源では、再起動後に SMB マウント ID が変わったことが証明されていますか？
いいえ。証拠が示していたのは、マウントのタイミングに関する問題でした。
情報源のユーザーにとって、fstab は維持されましたか？
はい。ただし、形式が正しくないエントリや利用できないエントリによって、修正するまで起動の問題も発生しました。
なぜダウンロードが成功したように見えるのに、Synology にファイルがないのですか？
リモート SMB ファイルシステムが実際にはマウントされていない場合、アプリケーションがローカルのマウントポイントディレクトリに書き込むことがあるためです。
