Note: this question was starting to sprawl so I rewrote it.
I have a folder that I'm trying to restore from a Time Machine backup. Using cp -R
works fine, but certain folders cannot be restored with either the Time Machine UI or Finder.
Other users have reported similar errors and the cp -R
workaround was suggested (e.g. Restoring from Time Machine – Permissions Error). But I wanted to understand:
- Why
cp -R
works when the Finder and the Time Machine UI do not. - Whether I could prevent the errors by changing file permissions before the backup.
There do indeed seem to be some permissions that Finder works with and some that it does not. I've narrowed the errors down to folders with the user ben
(that's me) and the group wheel
.
Here's a simplified reproduction. I have four folders with the owner/group combinations I've seen so far:
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
Each contains a single file called file
with the same owner/group:
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
In the backup, they look like this:
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
Of these, ben-staff
can be restored with Finder without errors. root-wheel
and root-admin
ask for my password and then restore without errors. But ben-wheel
does not prompt for my password and gives the error:
The operation can’t be completed because you don’t have permission to access “file”.
Interestingly, I can restore the file
from this folder by dragging it directly to my local drive (instead of dragging its parent folder), but when I do so its permissions are changed to ben
/staff
.
Here are the permissions after the restore for the three folders that worked correctly, and the file from ben-wheel
that was changed to 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
Can anyone explain this behaviour? Why do Finder and the Time Machine UI break with the ben
/ wheel
permissions? And why does cp -R
work (even without sudo
)?
Best Answer
The issue here is that Finder implements special handling of files restored from Time Machine to preserve all their permissions, which failed for files owned by the current user's account, but not a group he's a member of.
Usually, when copying files using
cp
, their attributes aren't retained. This can be changed using the-p
option.In both cases, you either copy all or none or these metadata.
cp
is clever enough to restore them only after all contained files have been processed ([source, see nearIf -p is in effect, set all the attributes
).If you don't have root permissions, ownership is not retained. The reason for this is that only root can make files owned by users not him and by groups he's not a member of.
To make Time Machine backups viewable but otherwise immutable in Finder, they are protected by Access Control Lists denying all users all modification permissions.
Since other attributes (other ACLs, extended attributes, file dates and permissions) should be retained when restoring from backup, special handling of these folders is required in Finder. It must remove a specific ACL entry, but retain everything else.
Additionally, Apple apparently wants Finder to retain all ownership information when copying files and directories from backup. This includes the group membership.
If your account is not the owner of the directories in question, Finder requests an administrator password and hands the copying off to its elevated privileges helper program Locum. This does not happen when you are the owner of a file in the backup set.
Now, one of the following cases happens:
It's like it's trying to
chown username:groupname
the file, and prints an error if it fails — which it does if you're neitherroot
(sudo
) norusername
and a member ofgroupname
.It behaves slightly differently if you're not copying folders, but files: While file ownership is retained, group membership is discarded if you're not a member of the group. This is what you saw when only copying a single file.
The obvious solutions to this problem:
dscl
from the command line in a way that had an effect without logout or restart. Another side effect is that withwheel
, you might run into problems with permissions depending on your system configuration.