Backup files belonged to a different uid and gid

Thanks for the reply. I intentionally did not restore from my backup - I took this as an opportunity to start from scratch again, restructuring my user logins, file system, generally cleaning everything up. So I definitely don't want to restore from the original backup, but I do still want to be able to work with those files in the backup that belonged to the previous user (uid).



In terms of the backup files, I'm aware of how the files and hard links work, and am partially aware of the extended attributes and ACLs that are defined on the files. But I don't understand them well enough to be able to get around them. I see ACL entries that basically deny everyone from touching the files, but I'm surprised that even as root user I cannot modify those ACLs. The best I've managed is to remove the ACLs (chmod -N) and then I can change owner on them. But this also strips the time machine extended attributes from the files, and so I don't think it's a good idea. What I really want to do is leave the files exactly as they were, but just change the owner from uid=502, gid=502, to 501/501.

Message was edited by: univ0298

That's exactly what I'm mid-way through trying - creating a new user, and a new group, setting them to uid/gid 502/502, and then I'll login as that user and try Time Machine and (more importantly for me) Back In Time 2.

Note that as I said right at the beginning - I can launch Finder as root and then Time Machine is able to work with these files. But Time Machine is too basic an interface - specifically it won't tell you about the 10Gb files it backup up one night and then deleted the week after - you have to scroll through every directory of every backup date/time to find those.

In case anyone else ever encounters this, here's some solutions I figured out...

First you need to find out who owns the files in the backup (specifically which uid and gid - not the username and groupname names). You can do this by browsing your backup, finding the directory you don't have access to, and doing 'ls -la'. For example maybe the directory is your old user's Library folder, so with commands like this:

cd "/Volumes/Backup of My Computer/Backups.backupdb/My-iMac/2008-03-17-073717/MyHD/Users/Richard"
ls -la

you might see some entries that look like this one
drwx------+ 33 502 502 1190 Mar 14 2008 Library

(note that I looked in a backup from Mar 17 2008, but you'll need to specifically look at one example in your own backup where you're not able to view the files because of an old uid/gid).

In the above listing example for Library, the first 502 is the uid, and the second one is the gid. Both are 502 in my case.

You can also do
ls -alOe

to see the ACLs:
drwx------+ 33 502 502 - 1190 Mar 14 2008 Library
0: group:everyone deny add file,delete,add_subdirectory,deletechild,writeattr,writeextattr,chown

Note that the ACL entry 0: is the one that is stopping you doing anything (even a chown while the root user or the file owner)

So what to do?

Well there are two choices - one is easy and probably safe but a bit awkward to work with. The other is harder, riskier, but ultimately better because it's easier to work with once completed.

1) Create a user and group on your system with the right uid and gid, then login as that user if you need to run Time Machine, Back-in-Time 2, etc to access the files that your main user cannot access.

or

2) Create a temporary user and group on your system with the right uid and gid. Then use this user to change the owner of all the backup files to your main user. From then on your new user can work with them.

You can create users and groups through system preferences , Accounts, Add. After creating a new user a group you can then set the uid and gid on these to be exactly what you need by control-clicking them in the accounts entry and going to advanced.


Option 1 - Once you have the new uid and gid created, you can log out and log in with this user, then work in Time Machine (or other) to work with those backups (which your new uid/gid should be able to access).

Option 2 - If you want to tackle option 2, PLEASE BE AWARE OF THE RISKS, and I advise that you understand these steps so you can adjust them for yourself - rather than just trying to copy the commands I used. You should make backups, and don't blame me if you do damage please.

First, you need to open Terminal. Then you need to run as the temp user to make the changes of the files so that they are owned by your new installation's users. Then you need to temporarily add an ACL entry to all files so the owner can be changed, then do the owner change, then remove that temporary ACL entry.

Here is the sequence of commands, and some info on what it does:

su temp
(to run as the temp user you created with the uid needed)
id
(to check you are the uid that you need)
cd "/Volumes/Backup of My Computer/Backups.backupdb/My-iMac/"
(change to the top level of the backup structure)
chmod -R +a# 0 "group:everyone allow chown,writeattr,writeextattr" ./*/MyHD/Users/Richard/Library
(this inserts an ACL at position 0 for all backup dates (the *), and all files in the Library directory)
sudo chown -R richard:staff ./*/MyHD/Users/Richard/Library
(this recursively changes the owner to your new user and group - in my example richard:staff. You can do an ls -la to check that the files now belong to richard:staff, or whatever your main user's name and group are)
sudo chmod -R -a "group:everyone allow chown,writeattr,writeextattr" ./*/MyHD/Users/Richard/Library
(removes the ACL entries you temporarily needed in order to do the owner change)

You should now be done! The files are now owned by your new user, and thus that user can work with them in Time Machine, Back-in-Time 2, etc. from this point forwards. You could even remove the temp user and group from the system at this stage.

Note: I encountered memory errors if trying to do recursive chmod on too many files at the same time. To work around this, I had to change the * to something like 2008* which would only change the 2008 files (I'd then have to run the command again with 2009*, then 2010* etc). I also found that if I'd encountered an out of memory error, I needed to run the command to remove the ACLs first, before re-trying (with a narrower wildcard)

Message was edited by: univ0298