NAS共有用コンテナのユーザー・グループマッピングチェックリスト

エヴァ・ウォン

IceWhale author

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

Container User and Group Mapping Checklist for NAS Shares - Zima Store Online

安全なアプローチは、NASエクスポートからホストのマウント、実行中のコンテナプロセスまでの数値IDマッピング確認を、単一のコマンドではなく、観測可能な複数のゲートとして扱うことです。

SMBまたはNFSで接続されたNAS共有を使用するLinuxコンテナホストでは、コンテナからNASのマウントパスは見えているのに、権限エラーによって読み取りや書き込みに失敗することが実際のリスクになります。現在のIDと復旧ポイントを記録し、まずは最も影響の小さい判別手順から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーしか公開されていない場合は停止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーションの境界に達した時点でのみ終了します。

実際のコンテナプロセスIDを特定する

イメージのドキュメント、Composeのuser設定、環境変数、エントリーポイントの動作、実行中のアプリケーションプロセスのUID、GID、補助グループを確認します。PUIDとPGIDという名前の変数はイメージ固有の慣例であり、Dockerの共通機能ではないため、そのイメージが対応していることを確認してください。

LinuxServerコミュニティのコンテナのPUIDおよびPGID権限に関する事例では、一見正しいPUIDとPGIDを設定していても、バインドマウントにアクセスできない場合があることが示されています。この事例は、すべてのイメージが同じ初期化ロジックを実装している証拠ではなく、実行中のプロセスとマウントを確認するための注意喚起として利用してください。

コンテナ内とホスト上でidを使用し、数値を記録します。権限エラーが以前に発生したためにアプリケーションがrootとしてのみ実行されている場合は停止してください。rootアクセスはマッピングの不具合を隠し、サービスが侵害された場合の影響を大きくします。

NASからホストのマウントまで所有権を追跡する

NAS上で、対象ディレクトリの数値形式の所有者、グループ、モード、ACL、デフォルトACLを確認します。コンテナホスト上でも、同じマウント済みオブジェクトを確認し、数値を比較します。名前が異なっていても数値が一致していれば、ラベル上の違いにすぎません。数値が異なる場合、認可経路が実際に異なっています。

NFSでは、エクスポートオプション、NFSバージョン、IDマッピング、root squash、クライアントのマウントIDを確認します。SMBでは、マウント認証情報、サーバー側でマッピングされたID、uidまたはgidの表示オプション、Unix拡張機能やACL変換が使用されているかどうかを確認します。

サーバーACLとクライアントのマウントオプションを同時に変更しないでください。既知の数値所有者を設定したテストファイルについて、アンマウント、再マウント、再起動の後もホストが安定したマッピングを認識できれば、その段階は合格です。

バインドマウントと補助グループをテストする

コンテナのソースパスが、ネットワーク共有のマウント前に作成された空のローカルディレクトリではなく、想定したホストのマウントであることを確認します。実行時のマウントを調べ、使い捨てのサブディレクトリで、アプリケーションユーザーとして一覧表示、読み取り、作成、名前変更、削除をテストします。

Server Faultの事例では、所有者とACLエントリが一致しているように見える場合でも発生するNFSのACL権限不一致が記録されています。これは、ACLマスク、サーバー側のマッピング、実効IDをすべて調査する必要がある理由を示しています。ディレクトリと作成したファイルの両方でgetfaclの結果を取得してください。

グループアクセスを意図している場合は、対応する数値の補助グループを追加し、プロセスのグループは起動時に固定されるため、コンテナを再作成します。アプリケーションが空のパスを対象に起動する場合は、コンテナの空パス診断に関するZimaSpaceのガイドを使用してください。これはACLの問題ではなく、マウント順序の問題です。

-15% OFF

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

Single board computer zimaboard2

最も限定的なID修正を適用して再テストする

アプリケーションがサポートするUID、GID、または補助グループをNASのポリシーに合わせることを優先します。複数のサービスが共同で使用する場合は、共有グループと継承ACLを使用します。回避策として、全ユーザーに書き込み可能な権限、無関係なデータセット全体への再帰的な所有権変更、特権コンテナを使用しないでください。

コンテナを再作成し、マッピングオプションを変更した場合は共有を再マウントして、同じ操作を繰り返します。ホストを一度再起動して、マウント順序と数値IDが起動後も維持されることを確認します。新しく作成されたファイルが、コンテナに不要な権限を与えることなく、意図した人間のクライアントから引き続き書き込み可能であることを確認します。

アプリが元のワークロードに成功し、拒否されるべき操作が引き続き拒否され、再起動後も所有権が安定していれば、チェックリストを完了します。ユーザーネームスペース、rootlessマッピング、またはNASのIDサービスによってIDが書き換えられ、選択したイメージでは対応できない場合は、エスカレーションしてください。