2025 年 11 月のこのスレッドでの当初の目的は明確でした。ミニ PC の内蔵 512 GB SSD に ZimaOS とアプリケーションを置き、5 TB の外付け Seagate USB HDD をメディアとダウンロード用に使うことです。問題は、ZimaOS がすでにストレージをどのように管理しているかを理解する前に、外付けディスクを一般的な Linux サーバーのマウントのように扱ったことから生じました。
ユーザーは手動マウントを次の場所で試しました。 /varにマウントし、その後サーバーがクラッシュしたため、ZimaOS を再インストールしました。その後、ディスクを ZimaOS のデータパスの下にマウントして SABnzbd に割り当てましたが、アプリケーションでは依然として権限エラーが返されました。したがって、このスレッドから得られる教訓は 2 つあります。まず安全な管理対象ホストパスを選び、その後でコンテナの権限を個別に解決することです。
任意の USB マウントポイントとして /var を使用しない
ZimaOS は、システムパスを管理するアプライアンス型のオペレーティングシステムです。元のユーザーは外付けドライブを /var 最初は動作したように見えたが、その後サーバーが完全にクラッシュし、再インストールすることになった。
マウント自体がクラッシュを直接引き起こしたとは、このスレッドからは断定できません。ただし、メディアディスクの通常の保存先としてシステムディレクトリを推奨すべきでない十分な理由にはなります。
外付けドライブの管理を現在の ZimaOS に任せる
現在の ZimaOS は、このスレッドの 2025 年当時の環境よりも USB ストレージを幅広くサポートしています。USB ディスクは「設定」>「ストレージ」から追加でき、手動で架空の Linux マウントポイントに接続するのではなく、通常のストレージとして使用できます。
新しい環境では、現在の ZimaOS で USB ストレージを追加する手順を利用してください。ディスクを管理対象にしたら、アプリケーションのボリュームマッピングで実際のストレージフォルダーを使用します。
ソースディスクは最終的に ZimaOS の管理パスの下に表示された
2025 年のインストールで表示された正確なパスを、別のサーバーにそのままコピーしないでください。 sda, sdb、および sdc 起動順序や接続されているハードウェアによって変わることがあります。
raw ブロックデバイスではなくフォルダーをマッピングする
Docker アプリケーションには通常、raw デバイスではなく、downloads や media などのディレクトリを渡してください /dev/sda1。ZimaOS はファイルシステムをマウントし、コンテナーはそのマウント済みファイルシステムからホストフォルダーを受け取ります。
ホストストレージがコンテナーボリュームになる仕組みについての現在の説明は、ディスクデバイス、マウントポイント、コンテナーパスを混同しないために役立ちます。
正しいマウントでも権限エラーが発生することがある
そのユーザーの環境では、最終的に /DATA/HDD1 SABnzbd にマッピングしましたが、アプリケーションは選択したダウンロードディレクトリを使用できませんでした。つまり、問題はストレージの可視性だけではありませんでした。
Docker プロセスは、コンテナ内のユーザーまたはグループとして実行されます。ホストフォルダーが別のユーザーによって所有され、アクセス権が制限されている場合、コンテナからパスは見えても、ファイルを作成できないことがあります。
PUID 999 を無条件にコピーしないでください
あるコミュニティの返信では、ユーザーに PUID を 1000 から 999 に変更するよう勧めていました。これは回答者の ZimaOS のアカウントモデルには合っていたのかもしれませんが、普遍的な固定値ではありません。
PUID または PGID を変更する前に、実際のホストフォルダーの所有者と、アプリケーションがどのユーザーとして実行される想定かを確認してください。ある環境で機能する数値が、別の環境では別のアカウントを指す場合があります。
再帰的なchmodとchownは強力で破壊的です
後のコミュニティ返信では、再帰的な chmod 775 および chown ダウンロードパスに対して実行します。これらのコマンドはLinux管理に役立ちますが、対象の下にあるすべてのファイルとディレクトリを変更します。このスレッドでは、IceWhaleのスタッフが投稿したものではありません。
所有権を再帰的に変更する前に：
- 正確な対象パスを確認する；
- ファイルシステムが通常のLinux所有権をサポートしていることを確認する；
- そのフォルダーをすでに使用しているユーザーやサービスを把握する；
- フォルダーを複数のアプリケーションで共有している場合は、重要なメタデータや権限をバックアップしてください。
ファイルシステムの種類によって権限モデルが変わることがあります
ext4ディスクは、LinuxのUID、GID、モードビットを直接保存します。exFATや一部のNTFS構成では、代わりにマウント時のオプションによって所有権を示すことがあります。PUIDを変更しても効果がない場合は、アプリケーション設定を繰り返し変更する前にファイルシステムを確認してください。
メディアアプリ向けの、より整理されたレイアウト
実用的な構成は次のとおりです：
- 内蔵SSD：ZimaOSのシステムと小規模なアプリケーションランタイムに使用する；
- 大容量の外付けHDD：メディア、ダウンロード、バックアップ、その他の大容量データに使用する；
- 永続的なAppData：十分な容量とバックアップ体制のあるストレージ場所に配置する；
- 各アプリには、必要なフォルダーだけを明示的にボリューム割り当てする。
これにより、メディアのダウンロードでシステムドライブがいっぱいになるのを防ぎ、アプリケーション設定を大容量のメディアファイルとは別にバックアップしやすくなります。
ZimaOSの外付けHDDに関するFAQ
外付けHDDを/varの下に手動でマウントすべきですか？
通常の現行ZimaOSの利用では、いいえ。Storageインターフェースと管理対象のストレージパスを使用してください。
SABnzbdは/dev/sda1を直接割り当てるべきですか？
いいえ。マウントされたファイルシステム上の通常のホストディレクトリを、コンテナが想定するダウンロードパスに割り当ててください。
アプリはフォルダーを認識できるのに、なぜ書き込みに失敗するのですか？
ホストのファイルシステムの権限や所有権、またはコンテナのPUID/PGIDによって、書き込みが許可されていない可能性があります。
PUID 999は標準的なZimaOSの値ですか？
いいえ。コミュニティ固有の提案であり、実際のシステムで確認する必要があります。
