从 Time Machine 恢复权限 - Finder 副本与“cp”副本

Ben*_*nor 7 finder permissions time-machine osx-lion macos

注意:这个问题开始蔓延,所以我重写了它。

我有一个文件夹,我正在尝试从 Time Machine 备份中恢复该文件夹。使用cp -R工作正常,但无法使用 Time Machine UI 或 Finder 恢复某些文件夹。

其他用户报告了类似的错误,cp -R并建议了解决方法(例如从 Time Machine 恢复 - 权限错误)。但我想明白:

  1. cp -R当 Finder 和 Time Machine UI 不起作用时,为什么会起作用。
  2. 我是否可以通过在备份前更改文件权限来防止错误。

Finder似乎确实有一些权限可以使用,而有些则没有。我已将错误范围缩小到用户ben(即我)和组的文件夹wheel

这是一个简化的复制品。到目前为止,我有四个包含所有者/组组合的文件夹:

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
Run Code Online (Sandbox Code Playgroud)

每个都包含一个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
Run Code Online (Sandbox Code Playgroud)

在备份中,它们看起来像这样:

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
Run Code Online (Sandbox Code Playgroud)

其中,ben-staff可以使用 Finder 恢复而不会出错。root-wheelroot-admin询问我的密码,然后恢复没有错误。但ben-wheel不提示我输入密码并给出错误:

The operation can’t be completed because you don’t have permission to access “file”.
Run Code Online (Sandbox Code Playgroud)

有趣的是,我可以file通过将它直接拖动到我的本地驱动器(而不是拖动其父文件夹)来从此文件夹中恢复,但是当我这样做时,它的权限更改为ben/ staff

以下是恢复后三个正常工作的文件夹的权限,其中的文件ben-wheel已更改为ben/ staff

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
Run Code Online (Sandbox Code Playgroud)

谁能解释这种行为?为什么 Finder 和 Time Machine UI 会破坏ben/wheel权限?为什么cp -R工作(即使没有sudo)?

小智 9

除了常规的 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 备份手动恢复您的文件(即,如果您使用迁移助手),那么您的所有文件都将保留那些讨厌的 Time Machine ACL 附加到它们。

删除 Time Machine ACL 非常容易。您有三个选择:

1)挥动斧头并完全从文件/文件夹中删除ACL(没有错,但不是一个非常谨慎的策略)

2) 从文件/文件夹的 ACL 中删除第一个条目(更谨慎但不是完美的解决方案)

3) 从文件/文件夹的 ACL 中删除特定限制(如果您想保留非 Time Machine 强加的 ACL,这可能是您的最佳选择)

对于所有三个选项,您都需要在 /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。如果您运行上述命令两次,那么您将同时删除 Time Machine ACL 以及您可能不想丢失的 ACL。

此外,上述解决方案也不适用于与其他文件混合的 Time Machine 文件。如果这些其他(非 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”)

上面的命令是幂等的,这意味着您可以一遍又一遍地运行它而不会产生不良影响。事实上,任何人都可以随时运行它。如果您的主目录中没有 Time Machine 锁定的文件/文件夹,则不会发生任何事情。

好的。我希望这对某些人有帮助。昨天我在 Time Machine 权限方面遇到了同样的问题,所以我想我会分享我的发现。


Dan*_*eck 6

这里的问题是 Finder 对从 Time Machine 恢复的文件实施了特殊处理以保留其所有权限,这对于当前用户帐户拥有的文件失败,但不是他所属的组。


通常,在使用 复制文件时cp,不会保留其属性。这可以使用-p选项进行更改。

-p 使 cp 保留副本中每个源文件的以下属性:修改时间、访问时间、文件标志、文件模式、用户 ID 和组 ID,在权限允许的范围内。访问控制列表 (ACL) 和扩展属性 (EA),包括资源分支,也将被保留。

在这两种情况下,你要么复制全部或者没有或者这些元数据。cp足够聪明,只有在处理完所有包含的文件后才能恢复它们([来源,见附近If -p is in effect, set all the attributes)。

如果您没有 root 权限,则不会保留所有权。这样做的原因是只有 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) 也不usernamegroupname.

如果您不复制文件夹,而是复制文件,则其行为略有不同:虽然保留文件所有权,但如果您不是组成员,则组成员身份将被丢弃。这就是您在仅复制单个文件时所看到的。


这个问题的明显解决方案:

  • 防止导致恢复失败的文件所有权(即由您和您不是成员的组拥有- 大多数情况下,这无论如何都没有用)
  • 让自己至少暂时成为该特定群体的成员。不幸的是,我无法dscl从命令行以一种无需注销或重新启动即可生效的方式执行此操作。另一个副作用是,wheel根据您的系统配置,您可能会遇到权限问题。


小智 6

实际上,您应该使用 tmutil 从 Time Machine 备份中恢复文件。这样您就不必删除扩展属性等。

Mac OS X 手册页

tmutil restore [-v] src ... dst

将快照内的项目 src 恢复到位置 dst。dst 参数模仿 cp 工具的目标路径语义。您可以提供多个源路径进行还原。最后一个路径参数必须是目的地。

使用恢复动词时,tmutil 的行为在很大程度上类似于 Finder。自定义 Time Machine 元数据(扩展安全性和其他)将从恢复的数据中删除,其他元数据将被保留。

执行恢复并不严格要求 root 权限,但 tmutil 没有权限预检来确定您恢复 src 或其后代的能力。因此,根据您要恢复的内容,您可能需要 root 权限来执行恢复,您应该提前了解这一点。这与您在使用其他复制工具(例如 cp 或同上)时会遇到的行为相同。当使用 tmutil 作为 root 进行恢复时,恢复的项目的所有权将与备份中项目的状态相匹配。

所以基本上你可以像cp命令一样使用它,而不必担心内部休息。

在大多数情况下,当您不知道您是否是文件的所有者或是否对目标目录具有写入权限时,您希望使用 sudo 进行恢复。