複数のNAS共有間でコンテナのユーザーIDを設定する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Configure Container User IDs Across Multiple NAS Shares

複数のNAS共有でコンテナのユーザーIDを設定するには、各コンテナプロセスの実際の数値IDを、必要なすべての共有の所有者、グループ、ACL、マウントモードに対応付けます。

すべてのデータセットを1つのUIDに所有させたり、統合方法としてchmod 777を使用したりしないでください。メディアサーバーは写真への読み取り専用アクセスのみを必要とし、ダウンローダーは取り込み用共有への読み書きアクセスを必要とする場合があります。また、バックアップコンテナには別の保護された保存先が必要になることがあります。主な責任には所有権を使用し、共有アクセスにはグループまたはACLを使用してください。

権限を変更する前に3つのIDを記録する

各サービスについて、NAS側の所有者UID/GID、コンテナ内プロセスの数値ユーザーIDとグループID、さらにPUID/PGIDなどのイメージ固有のID規則を記録します。ユーザー名が同じように見えても数値IDが異なることがあるため、これら3つの値は混同されがちです。

PUIDとPGIDはDockerの設定ではないことを説明した記事では、この違いが明確に示されています。PUIDとPGIDは、選択したコンテナイメージが解釈する変数であり、Docker共通の設定ではありません。

コンテナ内でidを実行して実行中のプロセスを確認し、ホスト上のファイルは数値の所有権を使って調べてください。イメージがその方法に対応していない限り、Composeに記述した値が実際にプロセスを制御すると考えてはいけません。

プライマリ所有者と共有グループを使ってサービス間でデータを共有する

1つのアプリケーションだけが使用する共有には、専用の所有者を設定できます。複数のサービスが書き込む共有は、必要な操作だけを許可する共有グループまたはACLを意図的に設定して管理する方が、通常は簡単です。

数値UIDとGIDの所有権についての実用的な解説では、バインドマウントされたファイルがホストの数値所有権に従う理由と、これらのIDを一致させる、または意図的に対応付けることで、root所有の出力や権限エラーを防げる理由が説明されています。

たとえばメディアワークフローでは、ダウンローダーがステージングファイルを所有し、ダウンローダーと整理サービスの両方をmediaグループに所属させることができます。ディレクトリの継承、デフォルトACL、または適切なumaskの動作を設定し、新しいファイルにも共有アクセスが自動的に維持されるようにしてください。

各共有にはコンテナが必要とするマウント権限だけを与える

IDは1つの層にすぎません。UIDを正しく対応付けても、読み取り専用のバインドマウントには書き込めません。また、コンテナが広範なファイルシステム権限を持っていても、ライブラリを読み取り専用でマウントすることで安全に制限できます。

2026年の実行時ユーザーの上書きに関する解説では、バインドマウントがホストの所有権を使用する仕組みと、実行時のuser:設定でプロセスIDを一致させる方法が説明されています。同時に、ユーザーを強制すると、異なる権限を前提とするイメージの起動処理が壊れる可能性についても警告しています。

各ホストパス、コンテナパス、マウントモード、必要な操作、担当サービスを文書化してください。サービスが読み取るだけのライブラリには読み取り専用マウントを使用し、実際に必要な最小限のパスだけに書き込み権限を与えます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

複数のNAS ACLモデルを意図的に扱う

SMB/NFSv4 ACL、POSIX ACL、NFSのIDマッピング、単純なUnixモードビットでは、アクセス権の見え方が異なる場合があります。NASユーザーとしてSMB経由では使用できる共有でも、ホスト上で異なる数値IDを使用するコンテナプロセスからは拒否されることがあります。

ZimaSpaceのNASの権限変更に関する関連記事では、保存先のACL継承、SMBのID、コンテナのUID/GID、umaskを別々の層として診断する必要がある理由が説明されています。

複数のプロトコルが1つのデータセットにアクセスする場合は、1つの権限モデルを選び、それを文書化してください。NASのGUIでACLを変更しながら、シェルでchmodやchownを繰り返し実行すると、次のファイルの動作が前のファイルと異なる可能性があります。

再帰的な適用の前に、すべての書き込み元からファイル作成をテストする

意図した所有権とACLを設定した使い捨てのテストディレクトリを作成します。各コンテナから、サービスに必要な操作だけをテストしてください。具体的には、一覧表示、読み取り、作成、名前変更、削除を行います。その後、NASから新しいファイルの数値所有者、グループ、モード、継承されたACLを確認します。

古いファイルは動作するのに新しく作成したファイルが別のサービスで使えない場合は、作成経路を修正してください。確認すべき点は、グループメンバーシップ、デフォルトACL、umask、アプリケーション固有のファイルモードです。古いデータを再帰的に修復しても、同じ不一致が翌日に再発するのを防ぐことはできません。

すべての書き込み元が、権限を昇格させることなく、次に必要なサービスで利用できるファイルを作成できることを確認してから、本番環境へ展開してください。適切なUID/GID設計が復旧可能なのは、すべてのコンテナがたまたま同じユーザーで実行されるからではなく、マッピングが文書化され、繰り返し適用できるからです。