Can't chmod or chown a file in TimeMachine backup directory

Question

When trying to restore a certain directory from TimeMachine (TM) I'm getting the error The operation can't be completed because you don't have permission to access problem_group_file.png. Looking closer at the files in the TM directory it seems that a file has consistently been getting, an perhaps continues to get, the wrong group ownership. Perhaps other file permissions are corrupt too preventing the restore operation from completing.

My next step was to try to change the ownership to be the same as its sibling files. This is something I've done before to successfully restore from TM at occasions when similar problems occurred. In this case though no matter what I tried I got the same error, Operation not permitted. Not even sudo touch is permitted in the directory. Perhaps this is by design.

Below is a listing of some files in the TM directory in question, with extended attributes and ACLs displayed. At the bottom is the problem file, called problem_group_file.png.

$ ls -aehlO@
total 26184
drwxr-xr-x@ 134 seron  staff  -  4,4K 12 Mar 09:41 ./
com.apple.metadata:_kTimeMachineNewestSnapshot    50B 
com.apple.metadata:_kTimeMachineOldestSnapshot    50B 
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@   4 seron  staff  -  136B 29 Jul  2013 ../
com.apple.metadata:_kTimeMachineNewestSnapshot    50B 
com.apple.metadata:_kTimeMachineOldestSnapshot    50B 
 0: group:everyone deny

...

-rw-r--r--@ 6 seron  staff  -  4,8K 10 Okt 14:37 good_group_file.png
    com.apple.metadata:_kTimeMachineNewestSnapshot    50B 
    com.apple.metadata:_kTimeMachineOldestSnapshot    50B 
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
-rw-r--r--@ 4 seron  wheel  -  3,2K 10 Okt 13:29 problem_group_file.png
com.apple.metadata:_kTimeMachineNewestSnapshot    50B 
com.apple.metadata:_kTimeMachineOldestSnapshot    50B 
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

I've read[1] that the file may be locked with the uchg extended attribute, but this does not seem to be so in this case.

At the bottom of each file attribute list is the ACL. I haven't used those before and don't understand how they work. Perhaps it is the cause of these problems.

The TM disk was checked without errors in Disk Utility. This problem appears on more than one TM disk which leads me to believe that it's not a TM disk error. The problem is manifested on multiple TM disks and backups. On the source side they all have the same (and correct) attributes and ownership sans ACLs. Disk Utility found attribute errors on the source disk, but only on files belonging to OS X, and not this file. All partitions are hfs+ journaled.

Answer 1

Reading up a bit on ACLs[1] I found that I could change ownership by first removing the file ACL with the following commands:

sudo chmod -a "everyone deny write,delete,append,writeattr,writeextattr,chown" problem_group_file.png
sudo chown :staff problem_group_file.png

After that the directory could be restored from TimeMachine backup without errors. This doesn't however explain why the problem occurred in the first place.

Answer 2

Based on seron's answer I was able to come up with the following solution:

Background

ACLs are rule based and the first rule to match is the rule that defines how a request for chown is handled. There can be more than one rule and the rules are ordered. ls -le problem_group_file.png will list all ACL rules for that file. In TimeMachine every file seems to have an ACL rule like this:

 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

That means as soon as a user who's in the group everyone tries to modify the file in any way, the ACL mechanism will prevent it.

The ACL rules are all modified via chmod's a command. The command can be used with various different modifiers (see below).

Solution

To allow chown for the admin (or for some other specifically named user) the following command can be used:

chmod +a# 0 "admin allow chown" problem_group_file.png

Afterwards (in case of admin) a sudo chown will work. The +a# 0 parameters tell chmod to insert (via +) the rule before (via # 0) the first rule. That means rule 0 will then be rule 1 and the new rule will be rule 0.

After chmod was run, it is safe (and simple) to remove this rule via:

chmod -a# 0 problem_group_file.png

This will remove (via -) the rule at index 0.