復元したフォルダーで明示的なACLは保持されるのに、親からの継承は失われるのはなぜですか？
復元されたフォルダーは明示的なアクセス許可を維持していても、復元時に保存済みACLが保護された状態で再作成されたり、継承メタデータが省略されたりすると、親からの継承を失うことがあります。
ファイルの内容、所有者、明示的なアクセスエントリ、継承状態は、それぞれ別の復元結果です。バックアップによって指定ユーザーやグループが正しく復元されても、「保護された」ACLが維持され、新しい親からのルールを受け入れなくなる場合があります。POSIXファイルシステムでは、復元されたディレクトリにデフォルトACLがないこともあります。NFSv4またはSMBベースのデータセットでは、継承フラグが変更されたり、別の形でマッピングされたりする可能性があります。再帰的なアクセス許可の変更を適用する前に、復元されたフォルダーと、新しく作成した同階層のフォルダーを比較してください。
復元されたフォルダーと新しく作成した同階層フォルダーを比較する
同じ親の下に、同じSMBまたはローカルIDを使用して、テスト用のフォルダーを作成します。所有者、グループ、モード、完全なACL、デフォルトACL、継承フラグ、実効アクセスを比較してください。
Microsoftは、復元または移動されたフォルダーが、現在の親ACLを自動的に受け取らず、保護されたアクセス許可を保持する場合があると説明しています。
新しい同階層フォルダーでは正しく継承されるのに、復元されたフォルダーでは継承されない場合、親はおそらく正しく設定されています。共有全体を再構築するのではなく、復元されたオブジェクトの保護状態と保存済みACLを確認してください。
明示的なACLエントリと継承されたエントリを分けて確認する
すべてのアクセスエントリを一覧表示し、それぞれが明示的か継承されたものか、拒否か許可か、ファイルのみかディレクトリのみか、さらに継承可能かを確認します。1つの管理者アカウントに対する実効アクセスだけを根拠にしないでください。
Red Hatは、POSIX ACLファイルシステムでは、ディレクトリのデフォルトACLが継承を制御すると説明しています。
フォルダーに有効なアクセスACLがあっても、デフォルトACLがない場合があります。その場合、現在のアクセスは維持されても、今後作成される子要素に意図したルールが付与されません。現在のアクセスと、将来の継承の両方を修復してください。
復元時に保護されたWindows ACLが維持されたか確認する
以前に継承されていたエントリが明示的なエントリに変換されたまま、継承が無効になっていないか確認します。この状態では、親のACLが変更されるまで、復元されたフォルダーが正しく見えることがあります。
SambaのWindows ACLガイドでは、共有とファイルシステムの設定によって継承や完全なセキュリティ記述子が左右される、Samba共有でのWindows ACLの扱いについて説明しています。
継承を再び有効にするためだけに、すべての明示的なエントリを削除しないでください。復元されたフォルダー固有の意図的なエントリは保持し、想定される親子関係を記録してから保護を解除してください。
データセットのACLモデルと継承フラグを確認する
保存先がPOSIX ACL、NFSv4 ACL、拡張属性に保存されたWindows ACL、またはNAS固有のプリセットのいずれを使用しているか記録します。元のバックアップ保存先と比較してください。
FreeBSDのZFSハンドブックでは、ZFSがNFSv4形式のACLをネイティブに保存できることを説明しています。これには、従来の所有者、グループ、その他のモードビットより高度な継承動作も含まれます。
あるモデルで作成されたACLを別のモデルへ復元すると、一部のIDは保持されても、継承の意味が失われることがあります。元と保存先でACLモデルが異なる場合は、テスト用データセットで復元してください。
復元ツールのACLおよび拡張属性オプションを確認する
ACL、拡張属性、所有権、数値ID、セキュリティ記述子、プラットフォーム固有のメタデータについて、実際に使用したバックアップおよび復元オプションを確認します。ツールのデフォルト設定とも比較してください。
LinuxのACLマニュアルでは、新しいオブジェクトがディレクトリのデフォルトACLを継承すると説明されています。ただし、復元されたオブジェクトが通常の作成処理と同じ経路で作成されるとは限りません。
ディレクトリの作成後に保存済みのアクセスACLを書き込む復元処理では、親から最初に提供されたACLが置き換えられる場合があります。ツールが意図的に古いACLを復元しているのか、それとも新しい親に継承を管理させるべきなのかを確認してください。
バックアップ形式にACLメタデータが保存されているか確認する
バックアップ内の1つのオブジェクトまたはアーカイブ一覧を調べ、ACLおよびxattrの記録があるか確認します。所有権とモードビットが含まれているアーカイブだからといって、完全なアクセス制御メタデータも含まれているとは限りません。
GNU tarでは、POSIX ACLエントリを保存および展開するために、ACL復元オプションが必要です。
継承メタデータがそもそも保存されていなかった場合は、復元された子要素1つから推測するのではなく、意図した親ポリシーに基づいて再構築してください。ロールバックに備え、修復前のACLエクスポートを保存しておきます。
再帰的な変更を適用する前に、1つのテスト用フォルダーを修復する
現在のACLをエクスポートし、1つのテスト用フォルダーで継承を再有効化するかデフォルトACLを再作成します。必要な明示的エントリを保持したうえで、SMB経由とローカルアプリケーション経由の両方で子ファイルを作成してください。
ZimaSpaceの記事「ファイルをNASに移動した後にアクセス許可が壊れる理由」では、より広範な転送時の問題を扱っています。この記事では、復元後に継承が失われる問題に焦点を当てています。
既存のアクセスが正しく維持され、新しい子要素が意図したルールを継承し、再接続、再起動、小規模な再復元を行っても結果が維持されれば、問題は解決しています。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
