When’s the last time that you repaired permissions on your Mac? Just a few years ago, it had become something of a universal panacea, which Apple recommended as a solution to a long and varied list of problems. That in itself was repairing permissions Mark 2 anyway. If you’ve been using macOS for even longer, you’ll remember having to repair permissions on the system (Mark 1). This article looks at what we used to do, and wonders how we cope without it now.

Repairing Permissions Mark 1

Before the advent of SIP (System Integrity Protection), anything that had root access to the files in the system could change their permissions. The effects could be subtle and puzzling, or bring sudden disaster, depending on what exactly broke as a result. It also appeared sufficiently common a problem that it merited its own command in Disk Utility.

In those days, repairing permissions required going back and checking installation records for the correct permissions for each system folder and file, which wasn’t something the user could do. Disk Utility’s command took its time to fix the problems, and sometimes only a reinstallation sufficed.

One of the less-recognised benefits of SIP was that it effectively prevented this from happening, although improvements in system installers undoubtedly played their part as well. The signed and sealed System volume in Big Sur and Monterey is an even better guarantee that everything on that volume must now be in perfect condition.

Repairing Permissions Mark 2

El Capitan provided a short break from repairing permissions. Once Sierra had been released, Apple quietly posted a support note (long since removed, and not archived) recommending a new procedure, which could fix a long list of problems, including:

• changes to preference settings, particularly those for System Preferences, do not ‘stick’;
• changes made to the Dock do not ‘stick’;
• you are asked to authenticate when trying to move or alter some folders in your Home folder;
• when trying to save, you are told that the file is locked, or that you don’t have permission;
• Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
• alerts warning that the startup disk has no more space available for app memory;
• Safari or SafariDAVClient use large amounts of resources (memory);
• your Mac runs very slowly;
• iTunes cannot sync a device;
• problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.

These largely result from broken permissions and related problems in ~/Library/Preferences.

At the time, I noticed that one of the more popular culprits was Near Lock, a new feature allowing you to unlock your Mac using your iPhone.

Repairing these permissions required the diskutil command tool, and although it has never been mentioned in its man page, typing
diskutil resetUserPermissions
in Terminal still elicits usage information. If you want to read a full account of the original procedure, this article explains all. Repairing permissions in this way became so popular, and effective, that I introduced my own tools to help, and diagrammed it.

Two years ago, Apple changed its support note to recommend reinstallation of macOS rather than use of the diskutil command. As I noted at the time, that seemed rather drastic. I proposed alternatives in another chart.

In March 2020, Apple changed the procedure again, to running a new tool repairHomePermissions in Recovery mode, then reinstalling macOS. By June 2020, Apple had removed its support note, silently erasing all trace of these procedures.

What happened?

In Sierra and High Sierra, many of us experienced pernicious problems with preference files. Some were just as Apple detailed: system preferences which just wouldn’t stick. They also affected app preferences, and I had several users of my apps who reported strange events including apps which crashed when trying to open, and saved preferences that kept reverting.

Since OS X 10.9 (if not before), preferences have been managed by a background service, cfprefsd. That’s why you can’t manually edit or trash preference files any more: cfprefsd can hold them in its caches when the app is no longer running, and may well overwrite any changes you think you may have made. Apps which access their own preference files normally do so via cfprefsd to avoid the problems which result from trying to go it alone.

The problems that Apple originally attributed to damaged permissions on preference files often arose without any mishandling on the part of the user, nor by apps. The only explanation which fits the facts is that those problems were attributable to bugs in cfprefsd which became prominent in Sierra, and lingered for a couple of years.

So the answer to the question in the title is, provided that your Mac is running Mojave or later, and certainly in Big Sur or Monterey, no you shouldn’t need to repair permissions. It’s so good to conform to Betteridge’s Law.