HOWTO: Time Machine tweaking: fixing ACLs and extended attributes using fsaclctl and chflags

Posted by max on March 03, 2009

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 chflags

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: 49% [?]

Theoretically Related Posts
  • DHCP on VMware Fusion
  • Joel Spolsky Gets It Wrong
  • Where to Buy Office Equipment
  • Annals of Idiotic Bugs
  • Trackbacks

    Use this link to trackback from your own site.


    Leave a response

    1. Ryan Davis Mon, 24 Aug 2009 02:26:14 UTC

      Deleting a bunch of ISOs is easier done from within time machine itself. Find them via the search field or manual navigation, select, and use the contextual menu to delete all copies of them.

      A better example is when you need to muck with the metadata of time machine. One thing TM does is to embed the serial number of the CPU of your machine. If you buy a new machine, restore fully into it, it’d be nice if the next backup started where the previous one left off, but it won’t. You have to use fsaclctl + xattr to tell TM “No no, these are the backups for THIS machine”.

    2. Kramer auto Pingback[...] googling for “acl writeattr” I found an article at: What I learned is that, in the Terminal one can turn off use of acl’s for a given volume, with: [...]

    3. Kramer auto Pingback[...] uitzetten van ACL op de juiste bestanden en/of mappen voldoende is om het probleem op te lossen. HOWTO: Time Machine tweaking: fixing ACLs and extended attributes using fsaclctl and chflags. Situatie in de Time Machine [...]

    4. ThomasT Thu, 18 Feb 2010 06:51:22 UTC

      Unfortunately, this won’t work any more in Snow Leopard (10.6), because the fsaclctl is not present there.

      Besides, all I try to do is to erase the backups of the /System and a particular Users subfolder. While in general deleting of backups can be done via the graphical TM interface, the System and a user’s Desktop folder seem to have special permissions that won’t allow deletion. So I’m trying to remove any possible ACLs on these folders, which fails because the OS doesn’t let me (any attempt to use “chmod -N” or “chmod -a” results in “operation not permitted”.

      Any suggestions?

    5. max Thu, 18 Feb 2010 07:01:27 UTC

      Yes – I don’t know why they removed that from 10.6. I can send you the fsaclctl executable from 10.5 if you want to live dangerously — I have a colleague who successfully used it on 10.6.

    6. ThomasT Thu, 18 Feb 2010 07:09:44 UTC

      A quick update: I could copy the fsaclctl command from a 10.5 system and it runs fine. This allowed me to disable the ACLs as described.

    7. ThomasT Thu, 18 Feb 2010 07:30:49 UTC

      OK, there is still a problem left: It appears I can not delete any symlinks, not even with “sudo rm -f”. ACLs are disabled with fsaclctl. This makes no sense.