I recently needed to reinstall OS X on my laptop. Once I reinstalled, I my primary username (“max”) didn’t have the same UID that it had had on the prior install. This didn’t cause any problems until I wanted to browse my Time Machine backups while not as root.
Much to my chagrin, I wasn’t able to change ownership of the old backups of
/Users/max with a simple
chown -R. What was going on here?
Two things. Volumes configured for Time Machine use two mechanisms to keep users (including you too, root) from mucking around too much and making the backups un-useful.
(It’s actually fairly difficult to corrupt a Time Machine backup, due to its novel and clever use of hardlinks, described at some length in this excellent article by John Siracusa, which I actually mentioned in an earlier post. One of the great things about Time Machine is that the files are actually files, not wrapped in some gargantuan monolithic binary clump comprehensible only to a particular flavor of backup software.)
If you need to do major mucking, like I did, this is what you have to deal with:
- Filesystem ACLs, manipulated with
fsaclctl. (Yeah, it’s a damn mouthful. Think “filesystem ACL control” and you’ll be somewhat OK.
- UFS+ extended filesystem attributes, manipulated with
You might not need to do major mucking. You might want to do parts of this if, for example, you discover that Time Machine just backed up a bunch of Linux ISOs you really don’t want to waste your storage space backing up.
Naturally, you’ll need to be root or using sudo in order to actually change these.
First, you need to disable ACLs on the filesystem being managed by Time Machine. It’s easy. This doesn’t destroy any ACL metadata stored, it just stops (temporarily, if you wish) from being used or enforced.
fsaclctl -p /Volumes/backup_vol -d
where “backup_vol” is whatever the name of your Time Machine volume is.
Next, if you had the same situation as I did where you need to change ownership of a whole branch of your filesystem, you’ll want to use
chflags, but probably selectively. Here’s what I did:
find /Volumes/backup_vol/Backups.backupdb/machinename/"Macintosh HD"/Users/max -flags +uchg -print0 | xargs -0 chflags -R nouchg
where machinename is the short hostname of the backed-up machine in question. “Macintosh HD” is the default main volume name, which may or may not be the case for you; don’t forget to enclose the name in quotes if it’s got spaces in it.
For those less Unix-inclined of you, that finds every file in my backed up /Users/max branch that has the “uchg” flag set (no user changes permitted) and unsets the flag. For my purposes, I don’t believe I need to reset the “uchg” flag back, so I didn’t store the changed filenames in order to do so.
Finally I changed the whole branch to belong to me again:
chown -Rh max /Volumes/backup_vol/Backups.backupdb/machinename/"Macintosh HD"/Users/max
There were a couple of symlinks that the above choked on, but they weren’t important enough to me to track down exactly why the ownership of the symlinks wasn’t changing. This may not, obviously, be the case every time. I could have programmatically found them, deleted them, and re-linked them, but it wasn’t worth the effort.
Don’t forget to turn the filesystem ACLs back on:
fsaclctl -p /Volumes/backup_vol -e
Popularity: 50% [?]