3

I am about to modify the file ownerships in my Time Machine disk, which uses ACLs.

Since it is my (only) backup disk, I thought I'd solicit comments on the script before I run it. The objective is to fix file ownerships so that /Vol/TM/Back/2012-xx-yy/Users/bob is owned by user bob, to make it possible for Bob to browse his TM history.

#!/bin/csh
# Replace Foobar, Bob, and Brand.
set PREFIX="/Volumes/Foobar-Time-Machine/Backups.backupdb/Bob’s MacBook"
set SUFFIX="/Brand/Users/"
set USER="bob"

foreach dir ($PREFIX/*)
    chmod -R -a "group:everyone deny chown" "$PREFIX$dir$SUFFIX$USER"
    chown -R $USER "$PREFIX$dir$SUFFIX$USER"
    chmod -R =a# 1 "group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown" "$PREFIX$dir$SUFFIX$USER"
end

Do you spot a disaster waiting to happen? The first chmod is meant to remove minimal ACL and the second is meant to restore it. Can the script be made safer? Needless to say, the script would be run as sudo.

Calaf
  • 4,359
  • 2
    Why don't you just make a backup of it first? Perhaps to a disk image? – Abhi Beckert Mar 10 '12 at 20:02
  • Because success right now does not mean that there is no trouble brewing down the road. Incidentally, I have the impression that the mighty Apple engineers shiver as much as I do from the notion of running chmod/chown to fix the permissions, although they have the added complication of worrying that someone will use this convenience to access other users sharing the same machine. – Calaf Mar 20 '12 at 05:42
  • 1
    I would not do this. You risk breaking your backup completely. – Thorbjørn Ravn Andersen Sep 30 '12 at 19:03

2 Answers2

1

Yes, it's scary, and yes I'd be worried. Why doesn't bob already own his own backups? If it's because of a UID or UUID mis-match, what's preventing recreating this problem (perhaps in reverse) in the future? If you can risk damaging the live machine I'd rather change Bob's UID and UUID on the live machine than on the backups, on the theory that there are probably other UUID mis-matches lurking on other disks.

In any case, scary as it is, if I were to try to fix I'd use the Finder if it were just a few folders that could be fixed with "Apply to enclosed items...". If that was impractical, next thing I'd try would be to find files owned by whoever currently owns Bob's stuff and change only those files. Going off of file path seems kind of risky to me.

Old Pro
  • 6,132
  • 3
  • 29
  • 71
1

I almost ran this script after i replaced my system drive with an SSD and my new user uid was different to the old one (wonder what happened if you ever did run it?).

In the end i found http://pondini.org/TM/B6.html (again) and the "tmutil associatedisk" tips seems to have worked for me (on Mac OS 10.7.5) - fingers crossed!

jonnybradley
  • 111
  • Actually - scratch that - associatedisk did "join" my new disc onto the old backups but didn't resolve the uid issue :( – jonnybradley Nov 13 '12 at 12:17
  • In the end i changed my new user's uid to match the old one mostly following this: http://www.inteller.net/notes/change-user-id-on-snow-leopard - seemed less risky than losing my whole backup... – jonnybradley Nov 14 '12 at 20:04
  • 1
    Better to just edit the answer than elaborate on things in the comments. The system will show all edit history if people wish to see it - but it's best to just edit the answer so that it's correct as it stands without need for comments. – bmike Nov 30 '12 at 23:42