We used to do it often, and it could fix the most intransigent of problems at times: repairing permissions. Amazingly, Apple is recommending it as a solution again, only this time it’s not the permissions in macOS, but those of your Home folder. With details buried away in one of Apple’s lesser-known support notes, this also relies on an undocumented Terminal command.

Since Apple introduced its System Integrity Protection (SIP) in El Capitan, all macOS system files – including now all the bundled apps too – are protected from intentional and inadvertent tampering. The only ways that they can get changed involve special Apple-signed installers, or Recovery mode. No app, no matter how badly behaved, can change permissions or anything else in those protected files. So that makes traditional repair of permissions superfluous, and it could only have been performed in Recovery mode in any case.

There are still plenty of unprotected folders and files, including many of those in /Library, third-party apps in /Applications, and of course everything in your Home folder, particularly in ~/Library. Apple has recognised that changing their permissions can result in a wide range of problems, few of which clearly point to it being a permissions problem.

How does this happen?

The question that Apple’s support note does not consider is how the permissions in, say, ~/Library might get changed. The note refers to the user changing those permissions, but in my experience few users are ever likely to do that deliberately, and it is most unlikely to be accidental.

What the support note does not say is that software might change those permissions for you. Indeed, one not infrequently-reported cause seems to be enabling and using Near Lock, the relatively new feature which allows you to unlock your Mac using your iPhone over Bluetooth. I therefore wonder whether a bug in Near Lock might be a common cause of altered permissions in Home folders.

What problems result?

Apple provides a long list of problems which could result from incorrect permissions in your Home folder. These include:

• 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.

Note that Apple does not list repeated prompts to unlock the keychain; your login keychain is stored in ~/Library/Keychains, though, and would be affected if local permissions were to be changed.

That’s a long list, and it almost all makes sense too. However, there are also other causes of most of those problems which do not involve permissions: some preference settings files do appear to become corrupted, rather than just have incorrect permissions, and trashing them is a long-established way of fixing that. If its permissions have somehow become incorrect, then trashing that .plist file will enable a fresh one to be created, this time with the correct permissions.

Repairing permissions, new version

You should be able to select your Home folder in the Finder, and use the Get Info command in the File menu (or Command-I) to open the Get Info dialog, in which you can fix this. Right at the bottom, ensure the Sharing & Permissions section is open. In there, your name should appear in the top of the three entries, and the privilege set should be Read & Write.

To change permissions and propagate the change throughout your Home folder, click on the padlock tool and authenticate. Set that top item, you as a user, to Read & Write, then click on the cog tool and use the Apply to enclosed items… command in that popup menu to propagate the permissions throughout your Home folder.

That should be all that you need to do, but Apple then recommends that you use an undocumented command to complete the repair. This must be performed in Terminal, where you enter:
diskutil resetUserPermissions / `id -u`

This apparently resets user permissions on the root volume (/) to the current user ID. It does not appear in man diskutil, nor when you just type diskutil, but its help info is given if you type
diskutil resetUserPermissions
You are then told
Usage: diskutil resetUserPermissions MountPoint|DiskIdentifier|DeviceNode UID
Reset the permissions of a user home directory.
Ownership of the affected disk is required.

But that is not yet all. Apple’s support note then states that the command may fail with an error -69841, in which case you should type the following into Terminal
chflags -R nouchg ~
then try the diskutil command again.

This begs several questions. First, what does diskutil resetUserPermissions do that propagating the correct permissions does not? Why is none of this incorporated into a tool like Disk Utility? Which widely-used apps and features, including Near Lock, change permissions and cause the problem in the first place?

I’d love to hear from those who have tried this, and learn whether it did fix your problems.

(I am very grateful to Neale Young for drawing my attention to this issue, and Apple’s puzzling support note, in his comment on this blog.)