When you run into a slowdown or two on your Mac, or perhaps another problem, then one of the troubleshooting steps that is commonly and sometimes blindly recommended is to run a “Permissions Fix” routine in Disk Utility. This routine is fairly straightforward; however, depending on your system’s setup you may be curious about repeated errors and warnings, or otherwise wonder about what happens when you run a permissions fix routine.
What are file permissions?
The filesystem on your Mac is a hierarchical tree with nodes, each node being a file, or a folder that contains other such nodes within it. Filesystem permissions restrictions simply set rules on a per-user basis for what user accounts and groups can do with a particular node, that is, read, write, or be denied access to that node.
Being filesystem entries, these permissions are not part of the files themselves, and instead are part of the formatting of the hard drive on which the files are stored. In essence, they are part of the index of the drive, and will not necessarily carry over to another file system if copied to it. In addition, some filesystems like FAT32 (commonly used for USB thumb drives) do not support permissions, so when a file is copied to drives of this format, all permissions are stripped and the file becomes fully accessible by everyone.
There are two types of permissions that OS X uses: POSIX permissions, and Access Control List permissions. The former is an older and simpler approach, and is still primarily used in most situations. The latter is far more complex and offers many nuanced differences, but for most people the difference between these two will not be important and you will mostly encounter standard POSIX permissions on files in OS X.
How do I view permissions?
Each of these will have either Read, Write, or Read and Write as possible access rules.
Why do permissions need “Fixing”?
Your Mac can technically run just fine with all files fully accessible to everyone; however, in doing so any program can access any file, including things like your contacts, so your Mac will be insecure. On the other hand, too many restrictions can prevent system services and programs from accessing the files they need, leading to hangs, crashes, inability to save and retrieve settings, and other unstable behavior.
As a result, you will want file permissions to be in the configuration set up by their developers (e.g., Apple), and to do this OS X supports a permissions fixing routine that will check critical file permissions against a central permissions database, and then update the files represented by this database so their permissions match.
How do I run a permissions fix?
Running a permissions fix can be done using Disk Utility, and commands in the Terminal. For Disk Utility, open the program and then select your boot volume, followed by clicking the Verify Permissions button (or the permissions fix button) in the First Aid tab. For the Terminal, you can run the permissions verification and fix with the following two commands:
diskutil verifyPermissions / diskutil repairPermissions /
Where is the Permissions database?
The fix routines access a central permissions database, is comprised of receipt and “bill of materials” files in the following folders on your Mac (the first is hidden):
When you install an application, update, or other software that uses Apple’s installer, the system will generate a small receipt file that represents the installed files, and includes details such as their sizes and permissions settings that the developer intends. This is true for the components of OS X, as well as for some third-party software.
Do I need to run a permissions fix?
While running a permissions fix on your Mac will not hurt a thing, more often than not it is simply not necessary. Even if you have permissions warnings, in the vast majority of cases these are for simple and benign differences between the file permissions on your hard drive and those in the database. For example, a file might be owned by a user called “admin” when the system thinks it should be owned by “root.” This will flag a warning, but in effect it has no change on how the file is accessed and used.
For example, the following is one such error:
Group differs on “Library/Printers/InstalledPrinters.plist”; should be 80; group is 0.
This means that the group is expected to be the administrators (80), but instead is the “wheel” (0) group, which is a special administrative group that has “sudo” access in the Terminal. In effect, this difference means absolutely nothing. Both groups are administrative and give proper access of this file for the way the system works.
There are many such differences that can occur as you use your system and update it, so if you see errors when running a permissions verification you will not necessarily help things by repairing the problem; however, it will not hurt to do so. As a result, if you are concerned about permissions having been changed, then by all means run the permissions fix routine.
What about repeated warnings?
Another detail that can be concerning is if you see regular warnings and changes to permissions when you run verification and repair routines. The may have you thinking the permissions of your Mac’s drive are completely messed up; however, in most instances this is simply not the case. Often files on the drive become altered by updates without a receipt file update to reflect the change, or even during bootup, or by various background system processes as they run and perform their tasks.
In these cases you might see the same files regularly showing the same warnings during verification and repair routines.
So what do I do about permissions?
Overall, with regard to permissions fixes in OS X, the best practices boil down to these two steps:
- Run a permissions fix routine if you suspect a change could be the cause for a problem at hand.
- Do not worry about any persistent warnings.
Perform these two steps after you make any significant change to the system (updating it, restoring from backup, etc.), and if any problem you are experiencing persists beyond these two steps, then it is very likely not from a permissions-related issue, and will require further investigation to figure out.