Repair Permissions success stories

As we've stated on numerous occasions: although the "Repair Permissions" procedure offered by Disk Utility is not the panacea some purport it to be, it is a valid troubleshooting routine in a variety of situations, evidenced by a multitude of real-world examples.

The biggest misconception among those who claim this procedure is useless is that performing a Repair Permissions routine only serves a single purpose -- resetting the permissions values for a select group of Apple-distributed software components based on application receipts located in the /Library/Receipts directory. In fact, as we've previously noted, there are other operations that Disk Utility performs --- like re-creating the /tmp directory -- that can resolve troubleshooting issues.

Just for fun, let's take a look at a repair permissions log recently generated on an ostensibly well-working MacBook Pro running Mac OS X 10.4.7.

• Group differs on ./private/etc/authorization, should be 80, group is 0
• Owner and group corrected on ./private/etc/authorization
• Permissions corrected on ./private/etc/authorization

• Permissions differ on ./private/var/log/secure.log, should be -rw------- , they are -rw-r-----
• Owner and group corrected on ./private/var/log/secure.log
• Permissions corrected on ./private/var/log/secure.log

What this log tells us is that the file ./private/etc/authorization (which is a critical file that support various login functions in Mac OS X) had the wrong group user id setting. The group was set to the superuser (root, uid=0), when it should have been set to admin (administrator, uid=80). While this incorrect setting didn't manifest as a troubleshooting issue in daily usage, it could cause problems with administrator access to modification of some authorization routines -- an issue averted by the Repair Permissions procedure.

The log also tells us that it modified permissions on the ./private/var/log/secure.log -- another important file that contains a record of recent authentication history. This is useful if, for instance, you are trying to find out if anyone was attempting (successfully or unsuccessfuly) to login to your system. All Disk Utility accomplished by repairing permissions here was turning off read access for the group -- in this case the administrator -- when it comes to ./private/var/log/secure.log -- an inconsequential change. This is one example where Apple's software is involved in a bit of a tug of war -- running routine Mac OS X maintenance scripts will turn read capabilities on for the administrator group with regard to this file, and repairing permissions will turn it back off.

The point here is that many, many factors can affect file permissions. This includes application installers, maintenance processes spawned by Mac OS X itself, and more.

Now let's move into a more vague area when it comes to repairing permissions: User success stories.

One problem is that users often conflate the repair permissions process with a solution in cases where other workarounds were also applied -- e.g. restarting, clearing caches, etc. It seems that if the repair permissions process is used at any point, some users are quick to assume that it was the rescuing element.

What we generally look for in repair permissions success stories are cases where various troubleshooting methods (including the simple but venerable restart) are attempted without success, then a repair permissions procedure is applied with success. So, without further ado, some examples.

MacFixIt reader Richard Cruse writes:

"I recently upgraded to Mac OS X 10.4.7 and did not discover any problems until now. I am a photographer and use Spotlight to find image files from time to time. I went to use my trusty Spotlight, typed into the window- Nothing. No spinning wheel, no results starting to appear- nothing!

"I tried a number of things including: restarting, logging in under different name and re-applying the 10.4.7 combo updater- still nothing! I went to the Apple Forums and discovered I was not alone. One person suggest going into the Spotlight preference pane and under Privacy adding>then removing both my hard drives. That was supposed to force it to re-index both drives. No Luck! It would not even let me add the drives to the list! Ugh! There were a number of other suggestions, which did not work- until the last one I came across. It seemed too simple! Repair Permissions! Everyone had told me to stop running repair permissions, so I did! Okay, I'll give it a try! Guess what? It fixed it! After running the Repair Permissions, there were a slew of over 20 system level permissions that were repaired! A quick restart, and Voila! All is well!"

A user post from MacWest.org:

"Recently a Mac friend phoned me almost in tears. She had tried for a few days to get her Epson printer to print again, but no go. Now she needed the printout immediately.

"After hearing what she had tried I asked if she had run Disk Utility. She hadn't, so I had her run it repairing permissions. While we talked about other Mac things, Disk Utility completed and I suggested she try printing. She did saying it was doing something, but not printing; then she excitedly said "it's printing!" I end my case; never say useless or does nothing for a known repair procedure."

Do you have a repair permissions success story? A situation where various troubleshooting procedures were applied unsuccessfully, and repairing permissions saved the day? If so, please let us know.

Previous Repair Permissions coverage:

• Another follow-up to the Repair Permissions debate
• Unravelling the Repair Disk Permissions controversy

Resources