このソースは、実際の所有権が決まるレイヤーを正しく示しています。コンテナがマウントされた ZimaOS フォルダー内にディレクトリを作成すると、新しいディレクトリは通常、親フォルダーが自動的に強制するはずだと期待した権限ではなく、コンテナ内で実行されているプロセスのユーザー情報と umask の動作を引き継ぎます。
そのため、全ユーザーに書き込み権限がある親ディレクトリでも、新しく作成されたサブフォルダーが root:root の 0755 になることがあります。アプリケーションが root として実行され、デフォルトの umask を使用している場合、イメージが PUID/PGID、特定のコンテナユーザー、setgid によるグループ継承、デフォルト ACL、その他の権限モデルに対応していない限り、root 所有の子ディレクトリが作成されるのは想定される動作です。
元の例はマウントされたバックアップフォルダーでした
ユーザーは、次のようなパスを説明していました。
/media/Daten/Backupこのフォルダー内で、新しく作成されたサブフォルダーが次のようになっていました。
root:root
drwxr-xr-xその結果、UID 999 などの非 root ユーザーは、新しい子ディレクトリ内のファイルを読み取ることはできても、作成することはできませんでした。
親ディレクトリを 0777 にしても子の所有者は強制されません
親ディレクトリの書き込み権限によって、コンテナ内のプロセスは子を作成できます。しかし、ファイルシステムやグループのルールでその動作を設定していない限り、子の所有者やグループが親から自動的に継承されるわけではありません。
通常の結果は、作成元プロセスの UID/GID と、そのプロセスの umask によって決まります。
コンテナイメージが対応している場合のみ PUID/PGID を使用する
LinuxServer 系のイメージの多くは、PUID と PGID の環境変数を提供しています。一方、これらの変数を完全に無視し、Docker の user: フィールドやアプリケーション固有の設定を必要とするイメージもあります。
IceWhale の現在の Syncthing ガイダンスでは、次のコマンドを使って実際の ZimaOS ユーザー ID を確認するよう明示的に案内しています。
id -u username
id -g usernameその後、確認した値をアプリの PUID/PGID フィールドに入力します。
現在の ZimaOS の PUID/PGID 例を参照してください。
umask は作成時に除去される権限ビットを制御します
一般的な umask である 022 の下で、アプリが基本モード 0777 のディレクトリを作成すると、ディレクトリの権限は 0755 になります。グループで共同作業する運用では、アプリケーションが対応している場合、別の umask を使用することがあります。
1 つのアプリを修正するためだけに、システム全体で極端に制限の緩い umask を設定しないでください。
setgid は新しいサブフォルダーで共有グループを維持するのに役立ちます
Linux ネイティブのファイルシステムでは、共有ディレクトリに setgid ビットを設定すると、新しく作成された子がそのディレクトリのグループを継承するようにできます。これは、複数のサービスやユーザーが意図的に 1 つのグループを通じて共同作業する場合に便利です。
ただし、作成元プロセスのユーザー ID は変更されません。また、マウントオプションによって Unix の所有権を再現する NTFS/exFAT マウントでは、同じように動作しない場合があります。
デフォルト ACL によって、より明示的な継承を設定できます
POSIX ACL に対応するファイルシステムでは、デフォルト ACL エントリによって、新しく作成される子が受け取る権限を定義できます。バックアップジョブのたびに再帰的な chmod を実行するよりも、こちらのほうが整理された方法になることがよくあります。
特定のストレージパスについて、現在の ZimaOS UI が ACL の完全な設定手順を提供しているかどうかは、シェルだけの設定に依存する前に確認してください。
元の内容は、既存の ZimaOS 設定ではなく機能要望でした
投稿者は、グローバルな PUID/PGID 制御、継承切り替え、umask 処理、setgid 対応、再帰的な修正を行う GUI を要望していました。このスレッドには、IceWhale がこれらの機能の実装を確認した回答はありません。
要望の一覧を、現在利用できる「設定」項目として説明しないでください。
ディスク全体を再帰的に変更する前に、アプリのユーザー情報を修正する
バックアップアプリが root 所有のフォルダーを繰り返し作成する場合、ジョブのたびに chown -R を実行するのは症状への対処にすぎません。まずコンテナのユーザー情報、グループ、umask を正しく設定し、その後で影響を受けたツリーだけを修復してください。
現在の ZimaOS アプリ設定では、ユーザーがボリュームのマッピングとアプリ設定を確認できます。ただし、利用できる正確な権限関連の変数はイメージによって異なります。
マウントされたフォルダーの所有権に関する FAQ
書き込み可能な親ディレクトリの下で、なぜ子フォルダーが root:root になるのですか？
コンテナ内のプロセスが root として作成したためです。親ディレクトリが作成元のユーザー情報を自動的に上書きすることはありません。
すべての Docker イメージで PUID と PGID は機能しますか？
いいえ。これらはイメージ固有の環境変数の慣例であり、Docker 共通の変数ではありません。
IceWhale は、グローバルな権限継承切り替え機能を元の内容で確認しましたか？
いいえ。このスレッドは機能要望であり、実装を確認する情報はありません。
