1

Background and question

I read of someone using a Mountain Lion Recovery System to attempt repair permissions of an installation of Lion.

I understand that for repair of permissions of Lion, it may be preferable to use OS X 10.7.5 or Recovery OS 10.7.5.

A question remains:

  • for repair of permissions of an installation of Lion, is it safe to use Disk Utility in a Mountain Lion Recovery OS?

Notes

diskutil(8) OS X Manual Page

… The data that guides the permissions verification is written during the installation process. …

– but it's not clear whether that data is read from the selected volume when Disk Utility is run from a Recovery OS.

For verbs verifyPermissions and repairPermissions a plist is optional, but there's no interface to this in Disk Utility.

repair_packages(8) OS X Manual Page

Thanks to commentary, I see that an OS X run of Disk Utility to repair permissions involves both diskutil and repair_packages. Here's a line from output of fs_usage:

03:06:31  access            r/libexec/repair_packages    0.000019   diskmanageme

For another run, a little later, 

macbookpro08-centrim:~ gjp22$ sudo fs_usage | grep "usr/sbin/diskutil"
03:09:24  open              usr/sbin/diskutil                                                                0.000021   repair_packa
^C
macbookpro08-centrim:~ gjp22$

– at the same time, 

macbookpro08-centrim:~ gjp22$ sudo execsnoop | grep 'diskutil\|repair_packages'
    0   7963   7143 repair_packages
^C
macbookpro08-centrim:~ gjp22$

OS X: About OS X Recovery

This Apple article mentions Disk Utility but not permissions of files.

About Disk Utility's Repair Disk Permissions feature

Improve this question

3 Answers 3

Reset to default
3

The diskutil repairpermissions /Volumes/whatever reads the BOM and receipts from /Volumes/whatever and not /. You can validate this with fs_usage and installing OS X on an external volume and running the check while snooping the IO.

It's always preferable to have the OS doing the repairing match the OS on the volume being repaired, but I've never been bitten with a problem by mixing things where a newer OS repairs an older OS. I've gone the other way in a pinch and not had it blow up, but I did make plans to run a proper repair when time was available soon thereafter.

Also - this is a very rare tool and like antiboitics, often gets prescribed erroneously. Repairing permissions only twiddles with Apple software and rarely is a problem due to incorrect permissions on a log file or an Application bundle.

Improve this answer
2
  • I trust your validation in the OS X environment, but I can't validate in that way with Recovery OS; it's necessary to quit Terminal before opening Disk Utility. With or without validation, it's +1 from me.
    – Graham Perrin
    Commented Dec 24, 2012 at 3:17
  • 1
    sudo opensnoop -n diskutil before and during a run of diskutil repairPermissions / shows opening of things that are not from Apple-originated installer packages, which made me wonder whether part of Apple's article HT1452 is misleading. I changed ownership of some of those things, re-ran repairs … it seems that whilst those things are opened, during repairs, they are not repaired. So I trust Apple's article and accept this answer – thanks.
    – Graham Perrin
    Commented Dec 29, 2012 at 18:07
2

It should be safe, but it won't be optimal. The repair process reads the installer receipts from the volume being repaired, so it'll be using the right version receipts. HOWEVER, it'll be using the Mountain Lion (wrong version) rules for which package IDs to use the receipts for, as well as a few overrides and additions that aren't receipt-based. Net result: it'll be mostly correct, but not perfect.

You'll get best results running the permissions repair while booted from the system you're going to repair. There's no problem repairing the live system. In fact, the only time I'd recommend running permissions repair booted from something else is if they permissions are so badly messed up that it can't even boot.

(I had to deal with a system like that once. What I did was run a repair from an installer DVD -- this was a while ago -- to get the permissions fixed well enough to boot; then I ran it again from the live system to fine-tune anything that didn't get done right by the DVD-based repair.)

Improve this answer
3
  • Nice. Please, can you elaborate on origins of the (wrong) rules, overrides and additions? If not within the Lion startup volume, then are there paths to files elsewhere? Or are some things hardcoded in diskutil?
    – Graham Perrin
    Commented Dec 23, 2012 at 18:30
  • I would disagree with it not being optimal (but not necessarily downvote this either) since the repair permissions simply looks at the Apple receipts on the volume to be repaired and enforces them on the filesystem. You could have a corrupted OS on the Recovery HD - but this is a fairly basic exercise and in practice - I've not seen this cause problems - just that it will surface problems with a filesystem or failing storage.
    – bmike ♦
    Commented Dec 23, 2012 at 19:53
  • 2
    @bmike: IIRC when I did the repair-from-other-volume/version and then repair-from-same-volume, the second repair did change a few things vs. the first. BTW, I don't know exactly what's read from the volume being repaired vs. from the volume doing the repair, but you can get some idea what's going to happen with /usr/libexec/repair_packages --list-standard-pkgs --volume /Volumes/whatever (see the man page).
    – Gordon Davisson
    Commented Dec 23, 2012 at 20:11
0

I did a repair disk permission on a previous osx and it ruined my system. It worked fine before then not afterward when it would lock up or act flaky. I no longer use this command.

Improve this answer
1
  • Details will add value to this answer. Which version of the operating system was used to perform the repairs? Which version of the OS was (supposedly) repaired? And so on …
    – Graham Perrin
    Commented Feb 28, 2015 at 9:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .