Repair Permissions: A false panacea?

There has been a growing debate on various forums and Mac Web sites over the worth of Disk Utility's "Repair Permissions" function as a troubleshooting procedure.

In particular, some prominent users have claimed that repairing permissions is akin to incantation, and doing so before or after applying a Mac OS X update (as we've recommended a number of times on MacFixIt) is pointless.

First, an explanation of what Repair Permissions actually does, straight from Apple:

"Many things you install in Mac OS X are installed from package files (whose filename extension is ".pkg"). Each time something is installed from a package file, a "Bill of Materials" file (whose filename extension is ".bom") is stored in the package's receipt file, which is kept in /Library/Receipts/ . If you look in the Receipts folder, for example, you should see all kinds of files that end with .pkg, including some that were created when Mac OS X was installed (for example, BaseSystem.pkg).

"Each of those '.bom' files contains a list of the files installed by that package, and the proper permissions for each file.

"When you use Disk Utility to verify or repair disk permissions, it reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature."

In other words, in Disk Utility scans .bom files (for application's that provide them), then modifies permissions mentioned in that .bom file to their original state. As such, in order for an application to be "repaired" by Disk Utility, it must -- as far as we know -- use the standard Apple Installer application and generate a .pkg file with a .bom file in the /Library/Receipts/ directory.

Repairing permissions may actually do more than that, but for now let's explore some misconceptions about the function itself.

Repair Permissions can affect third-party applications Many purportedly reputable Mac OS X Web sites and individuals have claimed that the repair permissions function does not perform any actions on non-Apple applications. This is false. The Repair Permissions function also works for some applications that use the Apple-originated installer package.

Applications that are excluded from the Repair Permissions function include those that were installed using a non-Apple installer application, those copied by drag-and-drop where no receipt file is created, or those that do not place a .pkg file in the /Library/Receipts directory.

This does not mean, however, that if you modify the permissions on any application by using the "Get Info" menu, then repair permissions, the permissions on said application will necessarily be changed back to their original state.

Let's look at an application that does place a .pkg file in the /Library/Receipts directory -- the Parallels Workstation Virtualization software.

We set permissions for this application to "No Access" under the "Ownership and Permissions" section of the Get Info window, and set the owner as current logged in administrator. We then locked the file. The Parallels application icon switched a generic folder icon, and the application could not be launched -- providing no error message, but simply not launching.

We then used Apple's Disk Utility to repair permissions. Although Disk Utility did not specifically report any repairs, and there was no recognition of any changes in the Finder (the Parallels icon was still a generic folder, with the locked symbol and the circular red "No Access" indicator), the application now launched correctly.

This series of operations -- changing the file from "Read and Write" access to "No Access" back and forth, then repairing permissions again -- was repeated several times with similar results. An application that was unable to launch because of incorrect permissions before running Disk Utility could subsequently be launched.

The same process repeated on Font Agent Pro yielded very different results -- changing the file to "Locked" status with "No Access" resulted in a non-launching application, and repairing permissions did not re-allow the application to launch. We had to manually set the owner back to the default "System" owner setting in order for it to properly launch.

Obviously, though it was difficult to get accurate feedback from the Finder, the Repair Permissions function properly changed Parallels' status back to accessibility for the current user.

This tells us two things: The Finder does not always immediately reflect permissions changes, and the Repair Permissions function may take action that is not reported in the log window.

For further corroboration, see this post from a Micromat technical support representative, posted to the MacFixIt Forums:

"[...] There are third-party programs that leave a receipt file in /Library/Receipts. Some time ago, I installed Microsoft Office and then repaired permissions. Hundreds of permissions for Office files were repaired."

What other problems can repairing permissions fix? Apple Knowledge Base article #303032 mentions a problem where when the user tries to connect to an iDisk or WebDAV server, the message "Error Code -50" is displayed and the attempt fails. Or if you're using iDisk Syncing, a "last sync failed" message always appears in the iDisk sync status.

Apple says:

"This happens when permissions are incorrect for the webdav_fs.kext bundle. To fix that, follow these steps: [...] (Repair Permissions). You should now be able to connect to an iDisk or another WebDAV server.

Another Apple Knowledge Base article #107396, reports on an issue where users cannot print, use Classic, start file sharing, burn discs, or update software if the /tmp directory is missing.

The solution? Repair permissions.

Apple says:

"If /tmp is missing, it's easy to make a new one by following these steps: [...] Recreate the missing /tmp link by using the Disk Utility application to repair permissions on your Mac OS X startup volume."

Wait a minute -- doesn't repairing permissions only check .bom files and make changes based on their contents? Apparently not -- it can also re-create the /tmp directory, and presumably correct other routine issues with directory structure.

Does Apple recommend running Repair Permissions after an update? Yes. In a Knowledge Base article describing Disk Utility 10.5, Apple explicitly states:

"Repairing permissions may also be recommended after updating the system or installing new software."

Apple also says:

"User permissions associated with files, folders, or applications can become damaged and prevent a file or application from opening. Permissions problems can also cause your computer to run slowly."

As aforementioned, some have claimed that there is no reason to run a Repair Permissions process after a Mac OS X update because the process will simply set the file permissions to those it finds in /Library/Receipts/, and the updater already wrote those permissions values.

However, the values in /Library/Receipts will not all be overwritten by the update -- only those for components affected by the update. Permissions problems for other components may still exist.

What causes permissions issues? According to Apple, there are a variety of causes for permissions issues, including (but not limited to): power interruptions, errant install processes, and files created in Mac OS 9.

It seems that incremental Mac OS X updates can fall into the errant install processes category, if pre-existing permissions issues are extant or the installer process goes awry as a result of interruption, drive corruption, or a myriad of other issues.

The bottom line is that repairing permissions is an Apple-recommended, quick process (usually taking less than a minute) that can resolve some significant issues -- whether or not they are directly caused by a Mac OS X update installation.

Feedback? Late-breakers@macfixit.com.

Resources