Today’s episode of macOS in diagrams looks at the procedures known as repairing permissions, which proved a panacea for some ills before all the system files were protected by SIP, and has since made something of a comeback.

The first thing that confuses many users is that repairing permissions before SIP is very different from now. We used to run a tool in Disk Utility, which checked all the system file permissions against those installed in macOS and its updates. With SIP, there’s nothing to correct, as SIP blocks any attempts to change those permissions in the first place.

Modern repair permissions works instead on your Home folder, mostly on the Library folder within that. Let the diagram explain what, why, and how.

There are a couple of issues which merit further consideration.

First, if you check permissions on ~/Library/Containers, you’ll always find many items which the current user can’t read or write. This is because this folder contains the Sandboxes of apps distributed through the App Store. Those apps are restricted to their individual Sandbox, so within each of those containers is a whole nest of links to other folders, including back to ~/Library itself. If you follow those links, as PermissionScanner does, then you will see many files in locations where you shouldn’t have write permissions, for instance. That is perfectly correct, and when repairing permissions any changes shouldn’t propagate out into those containers.

The other issue is also not mentioned by Apple: global preference settings and other key files which are kept in /Library. Incorrect permissions on preferences and other settings files there can also cause problems, such as stuck system keyboard settings which are used when logging in. Apple’s procedure doesn’t cover those, but you can use PermissionScanner to discover problems, then correct them in the Finder or at the command line.

I hope that you find this helpful, and that it makes clear the difference between the old and new repair of permissions.