TimeMachineから復元する権限-Finderコピーと「cp」コピー
注：この質問は広まり始めていたので、書き直しました。
TimeMachineバックアップから復元しようとしているフォルダがあります。 cp -Rの使用は正常に機能しますが、特定のフォルダーはTime MachineUIまたはFinderのいずれでも復元できません。
他のユーザーからも同様のエラーが報告されており、cp -Rの回避策が提案されています（例： Time Machineからの復元-パーミッションエラー ）。しかし、私は理解したかった：
- FinderとTimeMachineUIが機能しないのに
cp -Rが機能する理由。 - バックアップの前にファイルのアクセス許可を変更することでエラーを防ぐことができるかどうか。
Finderが機能するパーミッションと、機能しないパーミッションがあるようです。エラーをユーザーben（それは私です）とグループwheelのフォルダーに絞り込みました。
これが簡略化された複製です。これまでに見た所有者/グループの組み合わせを含む4つのフォルダーがあります。
ben ~/Desktop/test $ ls -lea
total 16
drwxr-xr-x 7 ben staff 238 27 Nov 14:31 .
drwx------+ 17 ben staff 578 27 Nov 14:29 ..
0: group:everyone deny delete
-rw-r--r--@ 1 ben staff 6148 27 Nov 14:31 .DS_Store
drwxr-xr-x 3 ben staff 102 27 Nov 14:30 ben-staff
drwxr-xr-x 3 ben wheel 102 27 Nov 14:30 ben-wheel
drwxr-xr-x 3 root admin 102 27 Nov 14:31 root-admin
drwxr-xr-x 3 root wheel 102 27 Nov 14:31 root-wheel
それぞれに、同じ所有者/グループを持つfileという単一のファイルが含まれています。
ben ~/Desktop/test $ cd ben-staff
ben ~/Desktop/test/ben-staff $ ls -lea
total 0
drwxr-xr-x 3 ben staff 102 27 Nov 14:30 .
drwxr-xr-x 7 ben staff 238 27 Nov 14:31 ..
-rw-r--r-- 1 ben staff 0 27 Nov 14:30 file
バックアップでは、次のようになります。
ben /Volumes/Deimos/Backups.backupdb/Ben’s MacBook Air/Latest/Macintosh HD/Users/ben/Desktop/test $ ls -leA
total 16
-rw-r--r--@ 1 ben staff 6148 27 Nov 14:34 .DS_Store
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben staff 102 27 Nov 14:51 ben-staff
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben wheel 102 27 Nov 14:51 ben-wheel
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root admin 102 27 Nov 14:52 root-admin
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root wheel 102 27 Nov 14:52 root-wheel
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
これらのうち、ben-staffはFinderでエラーなしで復元できます。 root-wheelとroot-adminはパスワードを要求し、エラーなしで復元します。しかし、ben-wheelはパスワードの入力を求めず、エラーを出します。
The operation can’t be completed because you don’t have permission to access “file”.
興味深いことに、私はcanfileを（親フォルダーをドラッグする代わりに）ローカルドライブに直接ドラッグすることで、このフォルダーから復元できます。しかし、そうすると、そのアクセス許可はben/staffに変更されます。
正しく機能した3つのフォルダーと、ben/staffに変更されたben-wheelからのファイルの復元後のアクセス許可は次のとおりです。
ben ~/Desktop/test-restore $ ls -leA
total 16
-rw-r--r--@ 1 ben staff 6148 27 Nov 14:46 .DS_Store
drwxr-xr-x 3 ben staff 102 27 Nov 14:30 ben-staff
-rw-r--r-- 1 ben staff 0 27 Nov 14:30 file
drwxr-xr-x 3 root admin 102 27 Nov 14:31 root-admin
drwxr-xr-x 3 root wheel 102 27 Nov 14:31 root-wheel
誰かがこの行動を説明できますか？ FinderとTimeMachineUIがben/wheel権限で壊れるのはなぜですか？そして、なぜcp -Rが機能するのですか（Sudoがなくても）？
ここでの問題は、FinderがTime Machineから復元されたファイルの特別な処理を実装して、すべてのアクセス許可を保持することです。これは、現在のユーザーのアカウントが所有するファイルでは失敗しましたが、彼がメンバーであるグループでは失敗しませんでした。
通常、cpを使用してファイルをコピーする場合、それらの属性は保持されません。これは、-pオプションを使用して変更できます。
-pcpに、コピー内の各ソースファイルの次の属性を保持させます：変更時間、アクセス時間、ファイルフラグ、ファイルモード、ユーザーID、権限で許可されているグループID。リソースフォークを含むアクセス制御リスト（ACL）と拡張属性（EA）も保持されます。
どちらの場合も、allまたはnoneまたはこれらのメタデータをコピーします。 cpは、含まれているすべてのファイルが処理された後にのみそれらを復元するのに十分賢いです（[ source 、If -p is in effect, set all the attributesの近くを参照）。
ルート権限がない場合、所有権は保持されません。これは、rootだけが、彼ではなくユーザーと、彼がメンバーではないグループが所有するファイルを作成できるためです。
Time Machineバックアップを表示可能にするが、Finderで不変にするために、それらはアクセス制御リストによって保護され、すべてのユーザーにすべての変更権限を拒否します。
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
バックアップから復元するときは、他の属性（他のACL、拡張属性、ファイルの日付、およびアクセス許可）を保持する必要があるため、これらのフォルダーの特別な処理がFinderで必要になります。特定のACLエントリを削除する必要がありますが、それ以外はすべて保持します。
さらに、Appleは、バックアップからファイルとディレクトリをコピーするときに、Finderがすべての所有権情報を保持することを望んでいるようです。これにはグループメンバーシップが含まれます。
アカウントが問題のディレクトリの所有者でない場合、Finderは管理者パスワードを要求し、そのコピーを昇格された特権ヘルパープログラムLocumに渡します。これは、バックアップセット内のファイルの所有者である場合は発生しません。
ここで、次のいずれかのケースが発生します。
- あなたはファイルの所有者ではありません：Finderはパスワードを要求し、Locumはバックアップと同じようにすべての権限を復元します。
- あなたは所有者であり、ファイルのグループのメンバーです。Finderはファイルをコピーしてグループを復元します。
- あなたは所有者ですが、ファイルのグループのメンバーではありません：Finderはファイルをコピーし、そのグループの復元に失敗します。
これは、ファイルをchown username:groupnameしようとしているようなもので、失敗するとエラーを出力します。これは、root（Sudo）でもusernameでもない場合に発生します。およびgroupnameのメンバー。
フォルダをコピーしていない場合は動作が少し異なりますが、ファイル：ファイルの所有権は保持されますが、グループのメンバーでない場合はグループのメンバーシップは破棄されます。これは、1つのファイルのみをコピーしたときに見たものです。
この問題の明らかな解決策：
- 復元が失敗する原因となるファイルの所有権を防止します（つまり、あなたとあなたがメンバーではないグループが所有している-ほとんどの場合、これはとにかく役に立ちません）
- 少なくとも一時的に、その特定のグループのメンバーになります。残念ながら、コマンドラインから
dsclを使用して、ログアウトまたは再起動せずに効果を発揮する方法でこれを行うことはできませんでした。もう1つの副作用は、wheelを使用すると、システム構成によっては権限の問題が発生する可能性があることです。
通常のUNIXファイルのアクセス許可（ユーザー/グループ/それぞれが独自の読み取り/書き込み/実行のアクセス許可を持っている）の他に、Mac OS Xはアクセス制御リスト（ACL）も使用して、より詳細なファイル/フォルダーのアクセス許可を設定できます。
Time Machineは、すべてのファイルに次のACLを追加（追加）します。
グループ：全員がadd_file、delete、add_subdirectory、delete_child、writeattr、writeextattr、chownを拒否します
（上記のACLはフォルダー固有ですが、次のような通常のファイルにマップされます：add_file = write、add_subdirectory = append、delete_child = <none>）
これは、Time Machineバックアップ内のすべてのファイル/フォルダーがすべてのユーザー（rootユーザーも含む）に対してロックされていることを意味します。
Time Machineバックアップからファイルを手動で復元する場合（つまり、not Migration Assistantを使用する場合）、すべてのファイルはそれらの厄介なTime MachineACLをファイルに添付したままにします。
Time MachineACLを削除するのは非常に簡単です。 3つのオプションがあります。
1）斧を振って、ファイル/フォルダーからACLを完全に削除します（これには何の問題もありませんが、あまり慎重な戦略ではありません）
2）ファイル/フォルダーのACLから最初のエントリを削除します（より慎重ですが、完全な解決策ではありません）
3）ファイル/フォルダーのACLから特定の制限を削除します（Time Machineによって課されていないACLを保持したい場合は、おそらく最善の策です）
3つのオプションすべてについて、/ Applications/Utilitiesにあるターミナルが必要です。
オプション1：斧を振る方法は次のとおりです。
デスクトップの「マイリカバリファイル」というフォルダに個人用ファイルしかないことがわかっていて、それらのファイルに特別なACLがない、または必要ないことがわかっている場合は、ターミナルウィンドウに次のように入力できます。
chmod -R -N〜/Desktop/My\Recovered\Files
（ファイル/フォルダーを指定するターミナルの方法がわからない場合は、目的のファイル/フォルダーをターミナルウィンドウにドラッグアンドドロップするだけで、ターミナルが正しいファイル/フォルダー名を入力します）
オプション2：最初のACLエントリを削除する方法は次のとおりです
上記と同じ例。デスクトップに「マイリカバリファイル」というフォルダがあります。ただし、この場合、保存したいカスタムACLを持つファイルがいくつかあります。ターミナルウィンドウに次のように入力します。
chmod -R -a＃0〜/Desktop/My\Recovered\Files
上記の解決策を「危険」にしているのは、べき等ではないということです。べき等演算は、一度適用した後、結果を変更せずに何度も適用できる演算です。数値に1を掛けるようなものです。それを続けることはできますが、結果は常に同じです。
なぜそれが重要なのですか？さて、Time Machineが独自のACLエントリを付加する前に、すでにACLが設定されているファイルがあるとします。上記のコマンドを2回実行すると、Time MachineACLとおそらく失いたくないACLの両方が削除されます。
さらに、上記のソリューションは、他のファイルと混在しているTimeMachineファイルには理想的ではありません。これらの他の（Time Machine以外の）ファイルのいずれかにACLがある場合、上記のコマンドはそれらのACLを削除します。
オプション3：ACLから特定の制限を削除する方法は次のとおりです
削除するACLの番号エントリを指定できるほかに、削除する特定の制限を指定することもできます。だからあなたはこれを行うことができます：
chmod -R -a "group：everyone deny add_file、delete、add_subdirectory、delete_child、writeattr、writeextattr、chown"〜
（「〜」は「マイホームディレクトリ」を意味します。つまり、ユーザー名がbobの場合、「〜」=「/ Users/bob」）
上記のコマンドはべき等です。つまり、悪影響を与えることなく何度も実行できます。実際、誰でもいつでも実行できます。ホームディレクトリにTimeMachineによってロックされているファイル/フォルダがない場合、何も起こりません。
OK。これが一部の人々に役立つことを願っています。昨日TimeMachineのアクセス許可についても同じ問題があったので、見つけたものを共有したいと思いました。
実際には、tmutilを使用してTimeMachineバックアップからファイルを復元する必要があります。このようにして、拡張属性などを削除する必要はありません。
tmutil restore [-v] src ... dstスナップショット内にあるアイテムsrcを場所dstに復元します。 dst引数は、cpツールの宛先パスセマンティクスを模倣します。復元する複数のソースパスを指定できます。最後のパス引数は宛先である必要があります。
復元動詞を使用する場合、tmutilは主にFinderのように動作します。カスタムTimeMachineメタデータ（拡張セキュリティなど）は復元されたデータから削除され、その他のメタデータは保持されます。
復元を実行するためにroot権限は厳密には必要ありませんが、tmutilは、srcまたはその子孫を復元する機能を決定するためのプリフライト権限を持っていません。したがって、復元する内容によっては、復元を実行するためにroot権限が必要になる場合があり、これを事前に知っておく必要があります。これは、cpやdittoなどの他のコピーツールで発生する動作と同じです。 rootとしてtmutilを使用して復元する場合、復元されたアイテムの所有権は、バックアップ内のアイテムの状態と一致します。
したがって、基本的には、内部の残りを気にすることなく、cpコマンドのように使用できます。
ほとんどの場合、ファイルの所有者であるか、ターゲットディレクトリへの書き込み権限があるかがわからない場合は、Sudoを使用して復元する必要があります。