コミュニティソリューション

ZimaOSアプリから外付けドライブにアクセスする:ホストパス、コンテナパス、現在のストレージマッピング

A November 2025 beginner tutorial showing how to identify a storage mount point and map it into an app with separate host and container paths. Community replies corrected the raw-mount approach, IceWhale clarified external media lives under /media by default, and the author later noted newer ZimaOS releases make the process easier.

この初心者向けチュートリアルは、実際の混乱の原因を解消しました。ZimaOS Filesに表示される名前とパスは、アプリケーションがDockerコンテナ内で認識するパスと自動的に同じではありません。元の投稿者はウェブターミナルでディスクのマウントポイントを確認し、その後、ホストのストレージフォルダーを次のような、よりシンプルなコンテナパスの下でImmichまたはSyncthingにマッピングしました。 /SYNC.

その後、このスレッドに重要な訂正が加えられました。ZimaOSが管理対象のストレージパスを提供できる場合、生のマウントパスをアプリストレージの長期的な推奨インターフェースとして扱うべきではありません。現在のZimaOSでは、2025年のワークフローよりもはるかに簡単に行えます。

元のチュートリアルは開発者モードで開始

「Developer Mode」と「Web Terminal」が表示されたZimaOS設定画面
元のチュートリアルでは、内蔵のウェブターミナルを使ってストレージデバイスのマウント先を特定しました。

ユーザーはマウントポイントを確認するためにlsblkを使用

ストレージのマウントポイントが強調表示されたlsblk出力を示すZimaOSターミナル
重要な項目はマウントポイントでしたが、その後の返信では、すべての生のマウントパスを安定したアプリストレージの保存先として扱わないよう注意が促されました。

アプリ設定を開いてボリュームを追加

「Configuration」が選択されたZimaOSアプリメニュー
アプリの設定パネルで、ホストストレージをコンテナに公開します。

ホスト列とコンテナ列は異なる意味を持つ

コンテナ内の /SYNC にマッピングされたZimaOSホストストレージパスを示すSyncthingアプリのボリューム設定
左側は実際のZimaOSホストパス、右側はアプリケーションがコンテナ内で認識するパスです。

コンテナ内のパスが /SYNCの場合、アプリケーションは /SYNC または次のようなサブフォルダー /SYNC/Photos。ホストのマウントパスを再び指定してはいけません。

内部フォルダーのパスとして /SYNC を使用するSyncthingのフォルダー設定
ボリュームをマッピングすると、アプリケーションはコンテナ側のパスだけで動作します。

コミュニティの返信で、生の /mnt パスを使用しないよう警告

別の参加者は、ディスクの更新、プールの再構築、その他のストレージ操作の後に直接指定した生のマウントパスが変わる可能性があり、ZimaOSのストレージ層の前提を回避することがあると指摘しました。

回答者は、次のようなZimaOSが管理する安定したストレージをマッピングすることを推奨しました。 /DATA/Media または意図したAppDataの場所を使用し、任意の生のマウント識別子を基にアプリを構築しないようにします。

IceWhale、外部メディアはデフォルトで /media 配下にあると明確化

Zima-Giorgioは、外部ストレージメディアのパスが /media デフォルトでは。この公式注記により、内部アプリデータの例で示されている外部ストレージと /DATA.

現在のZimaOSではパスの仕組みがより明確になっています

2026年8月までに、元のチュートリアルの著者は後のユーザーに対し、新しいZimaOSのバージョンではこのプロセスがはるかに簡単になったと伝えていました。

現在のIceWhaleのガイダンスでは、ZimaOSのホストストレージとコンテナパスがアプリ設定でどのようにマッピングされるかを説明しています。低レベルのマウント出力から手動でパスを構築する前に、まずこれを確認してください。

ファイルピッカーまたは管理ストレージを利用できる場合は使用する

通常のアプリでは、現在の最も安全な方法は、アプリのボリューム設定で目的のZimaOSストレージ領域にある実際のフォルダーを選択し、アプリが想定するコンテナパスを選択または維持して保存し、その後アプリケーション内でそのコンテナパスを使用することです。

アプリケーションフォルダーとして生のデバイスノードを使用しないでください

元のスクリーンショットには、次の文字列で始まるパスが含まれています /dev/... 実験的なボリュームマッピング内では、ブロックデバイスノードはマウントされたファイルシステムのディレクトリと同じものではありません。SyncthingやImmichなどの通常のアプリには、マウントされていない生のディスクデバイスではなく、マウントされたフォルダーを渡すべきです。

/DATAはZimaOSのデータ保存場所であり、すべてのディスク用のプレースホルダーではありません

後に別の初心者が、次の場所について尋ねました /DATA 単に「すべてのパスをここから開始する」という意味です。そうではありません。 /DATA これは、システムが管理するアプリケーションデータやユーザーデータに使用される、ZimaOSの管理対象データの場所です。分離された外部ストレージは、ここに表示されることがあります /media または、ZimaOSによる登録方法に応じた別の管理ストレージパスです。

重要なルールは、目的のストレージ領域にある実際のホストフォルダーを選択し、それを安定したコンテナパスにマッピングすることです。

チュートリアルの著者は後に、新しいZimaOSではこれが簡単になったと述べました

2026年8月、元の著者が戻り、別の初心者に対して、新しいZimaOSリリースでは手順が簡単になったと説明しました。その後のコメントは、歴史的な区切りをさらに明確にしています。ホストとコンテナのパスを理解するには2025年のターミナル画面を使い、現在のすべてのマウントポイントを手動で見つける必要はありません。

外部ドライブアクセスに関するよくある質問

Dockerボリュームのどちら側が実際のディスクパスですか?

ホスト側です。

Immich、Syncthing、または別のアプリは、内部でどのパスを使用すべきですか?

ボリュームマッピングで設定されたコンテナ側のパスです。

すべてのアプリを、/mntまたはデバイスノードに直接指定すべきですか?

いいえ。ZimaOSが安定した管理ストレージパスを提供している場合は、そちらを優先してください。

IceWhaleは、外部メディアがデフォルトでどこにマウントされると言っていましたか?

Zima-Giorgioは、外部ストレージメディアがここにあると述べました /media デフォルトでは。