アプリデータをコピーするとコンテナ内のファイル所有者が変わるのはなぜですか？

数値形式のUID/GIDが保持されない場合や、コピー先のランタイムがそれらを再マッピングまたは書き換える場合、コピー後にコンテナ内のファイル所有者が変わることがあります。

ホームNASでは、所有権が数値として保存され、各環境が異なるアカウントデータベースを通じてその数値を解決するため、同じファイルがホスト上ではあるユーザー名、コンテナ内では別のユーザー名で表示されることがあります。GUI、SMB共有、アーカイブ、rootシェル、移行ツール、コンテナのエントリーポイントを介したコピーでも、所有権が置き換わる可能性があります。まず数値IDを診断し、その後、アプリデータツリー全体の権限を変更する前に、コピー動作、ランタイムユーザー設定、起動スクリプト、ユーザーネームスペース、ネットワークファイルシステムのマッピングを切り分けてください。

ユーザー名を比較する前に、数値UIDとGIDを比較する

所有権は名前だけでなく数値で確認し、コピー元とコピー先を調べます。ホスト上とコンテナ内の両方で、代表的なファイル1つとその親ディレクトリについて、UID、GID、モード、ACL、拡張属性、ファイルシステムを記録してください。

Dockerのバインドマウントでは、異なるユーザーデータベースを使用するプロセスにホスト上のファイルが公開されます。Dockerコミュニティの権限に関する議論では、アクセスを確実にするには、ユーザー名だけを一致させるのではなく、数値UID/GIDの整合が重要だと説明されています。

数値が同じで表示名だけが異なる場合、所有権自体は変わっていない可能性があります。データを再帰的に書き換えるのではなく、ドキュメントまたはアカウントマッピングを修正してください。数値が異なる場合は、その証拠を保持したまま、コピーとランタイムの各段階を確認します。

コピーによって所有権が保持されたのか、再作成されたのかを確認する

正確なコピー経路を書き出します。ホストのファイルマネージャー、cp、rsync、tarアーカイブ、SMB/NFSクライアント、バックアップの復元、Dockerのコピーコマンド、一時的な移行コンテナなどです。方法ごとに、所有者、グループ、ACL、拡張属性のデフォルト動作が異なります。

rootで実行したコピーでは、明示的なアーカイブオプションを使用すると数値所有権が保持される場合があります。一方、別のツールでは、コピーを実行したアカウントが宛先のすべてのファイルの所有者になることがあります。最近のコンテナ移行に関する問題では、宛先のUIDがアプリケーションのランタイムIDと異なる場合、コピーしたアプリデータが読み取れなくなることが示されています。

小さなテストディレクトリ1つを使って操作を繰り返し、アプリケーションの起動直前に所有権を確認してください。数値がすでに誤っている場合は、コピー方法または復元フラグを修正します。起動後にだけ変化する場合は、コピーには手を加えず、コンテナのエントリーポイントを調べます。

コンテナのランタイムユーザーをホストのストレージ所有者に合わせる

実行中のコンテナ内で有効なユーザーと、バインドマウントされたアプリデータディレクトリの数値所有者を確認します。Composeのuser:、補助グループ、プラットフォーム固有のPUID/PGID変数、イメージ固有のアカウント設定も確認してください。

root以外のユーザーとしてコンテナを実行しても、別の数値IDが所有するホストディレクトリへのアクセス権が自動的に付与されるわけではありません。Dockerフォーラムの事例では、ディレクトリを誰でも書き込み可能にするのではなく、コンテナユーザーとホストの権限を一致させることで問題を解決しています。

アプリケーション用に安定した所有権モデルを1つ選び、Composeに記録してください。共有アクセスに必要なグループだけを追加します。chmod 777は避けてください。これはIDの不一致を隠し、分離性を弱め、今後作成されるファイルに意図した所有者を設定できなくなります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

エントリーポイントが起動時に所有権を変更していないか確認する

多くのイメージは一時的にrootで起動し、不足しているディレクトリを作成し、設定されたUID/GIDを適用してから、権限を落とす前に所有権を再帰的に変更します。そのため、最初のコンテナ起動後に、正しくコピーされたデータが勝手に変わったように見えることがあります。

コンテナランタイムやイメージには、所有権を変更するマウント機能が備わっている場合もあります。Podmanの問題報告では、:Uオプションによってマウント元の所有権が書き換えられることが説明されています。エントリーポイントのスクリプトでも、アプリケーションの起動時に同様の再帰的変更が実行される場合があります。

ログを表示した状態でコンテナを一度起動し、小さなテストサブツリーを監視します。エントリーポイントとイメージのリリースノートで、chown、ユーザー移行、PUID/PGID、権限修正の手順を検索してください。イメージが安定した代替手段をサポートしている場合にのみ、その動作を無効化または限定します。

Rootless Docker、ユーザーネームスペース、ネットワークファイルシステムを考慮する

Rootless Dockerとユーザーネームスペースの再マッピングでは、コンテナIDが別のホスト側の範囲に変換されます。NFS、CIFS、一部のNASマウントオプションでも、rootをsquashしたり、すべてのファイルに設定済みのUIDとGIDを強制したりすることがあります。

Rootless Dockerの権限に関する報告では、コンテナのIDがホストのサブオーディネートID範囲を介してマッピングされるため、ファイルが予期しない所有権で表示されることが示されています。診断の手がかりは、通常のコピー失敗ではなく、ユーザーネームスペースによる所有権マッピングです。

データパスがローカル、NFS、CIFS、FUSE、その他のマウント済みファイルシステムのどれに該当するかを確認し、UID/GID、root-squash、ACLの動作を記録します。ホストとコンテナから、それぞれ個別に所有権の作成をテストしてください。サーバー側のIDポリシーを理解する前に、ネットワーク共有を再帰的にchownしないでください。

既知のアプリケーションIDを基準に所有権を修復する

アプリケーションを停止し、現在のメタデータをバックアップして、イメージが想定する正確なUID、GID、ディレクトリモード、ファイルモード、ACL、セキュリティラベルを定義します。共有メディアや無関係なデータセットを除外し、アプリケーションが所有するパスだけを修正してください。

正しい所有権でも書き込みができない場合は、権限エラーと読み取り専用マウントを切り分ける方法を次に確認してください。

コンテナを再起動し、実際のサービスユーザーとしてテストファイルを1つ作成、変更、削除します。その後、コンテナを再作成してテストを繰り返してください。コピー、起動、再起動、コンテナの再作成後も所有権が安定し、広範な権限例外なしでアプリケーションが読み書きできる場合にのみ、修復は完了です。