Jellyfin、Emby、またはPlexでZimaOS-HDしか見えず、メディアが実際に保存されているHDD、NVMe、RAIDが見えない場合、通常はDockerに「NASへのアクセス権がない」ことが原因ではありません。コンテナが参照できるのは、ZimaOSがボリュームとしてマッピングしたホストフォルダーだけです。
これが、2024年6月の元スレッドでの核心的な解決策でした。ETWang1991は、アプリの設定を開き、新しいストレージをボリュームとして追加するようユーザーに伝えました。元の投稿者は、それで「完璧に」動作したと返信し、後に別のJellyfinユーザーもスクリーンショットを見て同じ結論に達しました。
DockerアプリからZimaOSホストのファイルシステム全体は見えない
コンテナの分離は意図的なものです。Jellyfinから見えるのは /Media そのパスがメディアを含む実際のホストディレクトリにマッピングされている場合にのみ、コンテナ内からそのパスを参照できます。
ZimaOSの「ファイル」にドライブが表示されても、すべてのApp Storeコンテナから自動的に見えるようになるわけではありません。
アプリの設定を開いてボリュームを編集する
実際のホスト側メディアフォルダーを選択する
ライブラリを含む実際のストレージ領域内のディレクトリを選択し、次のような推測した最上位パスを入力しないでください /Main-Storage.
ホストパスとコンテナパスには異なる役割があります
コンテナ側のパスは、次のようにシンプルで安定したものにします /media または /MediaJellyfin内では、ホストの実際のパスではなく、そのコンテナパスを使ってライブラリを追加します。
複数のユーザーが、ボリュームのマッピングが不足していた手順だと確認
元の投稿者は変更が機能したと述べました。RAID 5のMain-Storageを使用していた別のユーザーは、最初はOSディスクしか表示されませんでしたが、スクリーンショットを見てヒントを得たと返信しました。「Jellyfinにボリュームを追加する必要がありました。」
これは推測に基づく権限回避策ではなく、情報源によって確認された解決策です。
個別に追加したディスクは2024年当時のUI上の問題だった
一部の参加者は、古い選択画面で個別に有効化したディスクやRAIDストレージを選択するのに苦労しました。IceWhaleのスタッフは、個々のドライブを有効化して使用できると回答し、その後、インターフェースを改善したと説明しました。
これらの2024年の制限は初期のZimaOSに関するものです。現在のZimaOSでは、ストレージとアプリの設定から管理対象ストレージをより明確に確認できます。
現在のZimaOSではアプリのストレージパスを明確に文書化している
現在のIceWhaleのドキュメントでは、App Storeコンテナが実際のホストフォルダーに永続データを保存すること、また各アプリのボリュームマッピングを設定から確認・変更できることが説明されています。
Jellyfin、Emby、Plex、その他のアプリをマッピングする際は、現在のZimaOS Dockerアプリパスモデルを使用してください。
AppDataの場所とメディアの場所は別々
アプリケーションの設定ファイルやデータベースファイルは設定済みのApp Dataの場所に置き、大容量のメディアファイルは別のRAIDまたはHDDプールに置けます。アプリの設定ボリュームを映画フォルダーに割り当てたり、AppDataを移動すればすべてのメディアライブラリも移動すると考えたりしないでください。
現在のZimaOSでは管理対象アプリデータを移動できる
現在のデータ移行では、DockerイメージとDockerアプリケーションデータを別のストレージ領域へ移動できます。これはメディアボリュームの追加とは異なる問題を解決します。前者はアプリ自体が永続状態を保存する場所を制御し、後者はコンテナにユーザーのメディアへのアクセスを与えます。
現在の管理対象アプリデータ移行ワークフローをご覧ください。
アプリがファイルを変更する必要がない場合は、読み取り専用のメディアマウントを選択する
メディアサーバーは通常、映画や音楽を読み取る必要がありますが、ソースライブラリを削除したり整理したりする権限までは必ずしも必要ありません。現在のアプリパッケージで許可されている場合は、メディアを読み取り専用でマッピングすると、侵害されたコンテナや設定ミスのあるコンテナによる被害を抑えられます。
ファイルの名前変更、移動、インポートを意図的に行うアプリケーション（ダウンロード管理や写真管理のスタックなど）には、異なる書き込み権限モデルが必要です。
ボリュームマッピングとファイルシステム権限は別々に確認する必要があります
正しいホストフォルダーを追加することが最初の要件です。さらに、コンテナのプロセスには、そのフォルダーを読み書きするのに十分なファイルシステム権限が必要です。マッピングされたディレクトリが表示されるのに空の状態で開かれたり、権限エラーが返されたりする場合は、広範な権限を付与する前に、コンテナのUID／GIDとホスト側の所有者を確認してください。 chmod 777 回避策。
2024年のソースでの問題は、主にボリュームマッピングの欠落でした。後から発生した権限の問題は、正しいパスが実際にマウントされていることを確認してから診断すべきです。
再インストール後もコンテナ側のパスを一定に保つ
Jellyfinのライブラリが /Media、コンテナ側のパスを /mnt/media2 再インストール中に行うと、ホスト上のファイルが移動していなくても、既存のライブラリが見つからないように見えることがあります。
可能な限り同じコンテナ側のパスを維持するか、マッピングを変更した後にアプリケーションのライブラリ設定を意図的に更新してください。
現在のUIは2024年の選択画面より優れていますが、Dockerのルールは変わっていません
IceWhaleはソース内で、以前のストレージ選択画面が分かりにくかったことを認め、その後インターフェースを改善しました。現在のZimaOSでは、アプリデータの場所、ホスト／コンテナのパス、ストレージの移行、アプリのキャッシュ使用量がより直接的に表示されます。
基本的なDockerのルールは変わりません。コンテナが認識できるのは、コンテナにマウントされたものだけです。
アプリのストレージアクセスに関するよくある質問
なぜZimaOSのFilesではドライブを認識できるのに、Jellyfinでは認識できないのですか？
Filesはホストレベルで動作しますが、Jellyfinはコンテナ内で動作し、マッピングされたボリュームしか認識できません。
ソーススレッドでは、ボリュームを追加すると動作することが確認されていましたか？
はい。ストレージ／メディアボリュームを追加した後に成功したという報告が複数あります。
Jellyfinはホスト側の実際のパスを参照すべきですか？
いいえ。Jellyfinは、ホストのマッピングされたフォルダーに割り当てられたコンテナ側のパスを参照する必要があります。
