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):
/var/db/receipts /Library/Receipts
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.
I do run permissions every once in a while. It’s just like taking vitamins. I probably don’t need them but for just in case … It’s good for the peace of mind.
Some folks report that Repair Preferences only repairs OS X files and not user files. Is this correct?
I think you mean repair permissions. There are apps that can repair preference files, or rather quarantine damaged preferences, such as Preferential Treatment (the affected apps will create new prefs as soon as you launch them); these apps check system and user prefs in separate operations.
Apps like Disk Utility do, in fact, repair primarily, if not exclusively, system file permissions. This is because, as Topher wrote, because third party apps don’t always create the receipt files necessary to record what the preferences should be. This is particularly true for drag and drop installs.
There are ways to repair permissions on third-party apps and files, but these are somewhat arbitrary unless you know what you’re doing. For example, you can use the Get Info window to check and adjust read and write permission for a folder and then, under the gear pull-down menu, select “Apply to enclosed items….” This can be useful if, for some reason, files you commonly use become inaccessible for some reason. Rather than adjusting permissions on one file at a time, if these are your files and you’re sure you should be able to use them, then fix the permissions of the enclosing folder – if they are off – and apply the changes to the files in the folder. This procedure should not be used on system level folders, including the Applications and Utilities folders. Apple installed apps will almost always have permissions that differ from third party apps in the same folder; these should not be homogenized. In fact the procedure probably won’t work anyway; Apple installed apps will generally have root permissions which cannot be changed by a regular admin user. Which is a good thing, actually. Some things users just shouldn’t mess with.
Sometimes an entire user folder can become corrupted – it’s happened to me twice that I recall; there is a way to fix this, too, but it’s too involved for me to cover here. Topher reported the procedure back when he was working on MacFixIt. You may be able to turn up his article on CNet if you need to. Or ask him to repeat it here. Since he just raised the permissions issue, it would seem appropriate for him to expand on the subject. 😉
As for how important repairing permissions can be, on occasion in my experience repairing permissions can fix printing and Internet connection problems. Not always, of course, but it’s still the first thing I try before digging in any deeper. Despite what Topher implied, some files are sensitive to ownership issues. Permissions are a core feature of OS X and the unix shell on which it is built. To dismiss them out of hand is irresponsible, in my opinion. Also, every time there is an OS X update or upgrade we see reports of the procedure going wrong. I think it’s a fair guess that they went wrong at least in part because routine system maintenance, including permissions repair, was ignored. This is rather like topping off your car’s oil without removing the dirty oil first – or putting new wine in old bottles, to borrow an old but venerable metaphor. This happens more often with incremental updates; one way around that is to use the combo updater for the system in question because it replaces more files than an incremental update and can sometimes clear away the dross in the process – and saving you hours of troubleshooting at the same time. This way you may never know exactly what was wrong, but if it’s fixed, you don’t really need to, do you? All you know is that the solution you tried did the trick. Sometimes we have to be satisfied with that.
does it make a difference which app is used to repair permissions, quality of repair?
Third party apps that repair permissions are merely accessing the built-in system function to do so. So it should not make a difference if you use, say, DiskWarrior, TechTool Pro, Cocktail, Onyx or Maintenance to repair permissions.
Excellent post, thank you
Yes, that’s correct. There is a different procedure for “Resetting” user permissions that involves the use of the Recovery HD and the resetpassword utility accessed through the Terminal app. Perhaps Topher will post another article covering this in the future.
Does this matter?:
Warning: SUID file “System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent” has been modified and will not be repaired.
I’ve had this message every single time I’ve run a permission repair, i.e. forever. I believe I once read that it didn’t matter.