The surprise of last week came in an Apple support note which was very kindly provided here by Neale Young. It isn’t even a recent note, being dated 26 September 2016, shortly after the release of macOS Sierra. But because there’s no coherent guide to all these twists and turns in macOS, it has presumably been overlooked by most of us using Sierra.

I have already detailed this new technique of repairing permissions on your Home folder, and provided a little app to make this easier.

Anyone who used OS X Yosemite and earlier will think that they are very familiar with repairing permissions, but this is quite different from what used to be a panacea which fixed all sorts of weird problems.

Repairing system permissions

Up to Yosemite, we used to repair system permissions, because the tens of thousands of system files, in /System/Library and some of /Library, were prone to damage by errant apps. In earlier versions of Mac OS X, this was so common that Disk Utility had a special control to perform it, and it was a stock line in my responses to Mac users with many types of problem: “Have you tried repairing permissions using Disk Utility?”

When we repaired permissions then, Disk Utility would look through all the .bom files (‘bill of materials’) in the folder /Library/Receipts, which contain details of software installed using Apple’s installer. Those list the files installed by each package; Disk Utility would then check that the files on your startup volume had the correct permissions as prescribed in the .bom file. Some utilities, like OnyX, still try to do this.

There are two snags to performing that sort of traditional repair of system permissions now.

First, if you take a look in /Library/Receipts, you’ll notice that .bom files have all but disappeared. My last one was written on 25 June 2015, for a long-outdated version of iMovie. The file InstallHistory.plist is still used, and faithfully records software installations, but .bom files are long out of fashion. Without any record of the correct permissions for everything installed by macOS Sierra and its updates, repairing system permissions now is an utter waste of time.

Second, even if Disk Utility did detect incorrect permissions in some system files, it could not change any that are protected by System Integrity Protection (SIP), unless you restarted in Recovery mode. Although it was rumoured in the early days of El Capitan that restarting in that mode would either automatically repair permissions, or at least let the user do so, that had never been the case. Repairing system permissions was a feature removed with El Capitan and SIP.

In El Capitan and Sierra, then, the system files cannot require their permissions being repaired, and there would be no way of knowing what those permissions should be anyway.

Repairing other permissions

There are two other large classes of folders and files whose permissions are important: those of third-party apps and other software, and those in the user’s Home folder.

In the past, third-party software often sprayed its components all over your startup volume. The App Store has gradually brought discipline, and even Apple’s macOS Server and Xcode SDK are now remarkably disciplined about what they store outside the app bundle. Ultimately, if an app isn’t working right because the permissions of some of its components have got munged, you need to re-install that app.

That leaves just your Home folder unaccounted for. There, the default permissions should make you, the user, the owner of each file with read and write permissions. Some documents might need more liberal write access to others, and sometimes users may wish to lock themselves out of being able to write to a file.

The simple method of setting this should be through Finder’s Get Info dialog, where the Apply to enclosed items… should be able to propagate that throughout the whole of your Home folder.

If we are to believe Apple’s support note, that is not sufficient. You also need to invoke a sub-command of the diskutil command which Apple has added for this purpose, but failed to document: diskutil resetUserPermissions. Apple does not explain why this is necessary, nor what that command does.

Even then, that may return an error, whose code, -69841, is not recognised as having any meaning by OSStatus.com. The command recommended to fix that clears the user immutable (i.e. locked) flag throughout the whole of the Home folder, unlocking its entire contents, ready for diskutil resetUserPermissions to have another go at doing what the Finder couldn’t.

Of course, if you have deliberately set the user immutable (lock) flag on files to protect them, that protection will be removed. That is a side effect which Apple doesn’t mention. We don’t know what other side effects there might be, because Apple does not provide any documentation or further information.

It may be, though, that we have needed to pay more attention to permissions in our Home folders for a long time.

Trashing Preference files

One ongoing problem which still troubles users is that of preference settings files (.plist files in ~/Preferences and ~/Library/Preferences) which stop working. At its simplest, this may stop any changes in those settings persisting as they should. At its most complex, it can upset all sorts of activities in strange ways.

What if our assumption that the Property List files involved have become corrupted is wrong. What if – in the great majority of cases – all that has happened is that its permissions have become munged, making the file read only for the user, for instance? That is one of the symptoms which Apple’s new technique of repairing permissions on the Home folder can address. It’s a sledgehammer solution to do this for the whole Home folder when a single settings file may be to blame.

So the next time that you are tempted to trash a settings file to fix a problem, try Get Info on it instead, and correct its permissions. It could save you the trouble of recreating those settings, or of trudging through resetting permissions on the whole of your Home folder.

I am sure that we will learn more about this in coming weeks.

Postscript

Thanks to Mats, whose comment below adds more detail.

Although /Library/Receipts seems to have been abandoned a couple of years ago, Apple’s Installer continues to place .bom files in /var/db/receipts, and system installation .boms in /System/Library/Receipts. So it is still possible to iterate through all the boms just as used to be done, although those of course only cover items installed as Installer packages.

Apple has introduced a preference file server, cfprefsd, which run in one instance process for each user (even when a user is not logged in), and one for root. These only serve preference settings to those apps which use its API though: apps which read and write their preferences files in the traditional way (the default for normal Swift apps still, for example) are not handled by cfpredsd.

Furthermore, cfprefsd only manages preference files for running apps and processes. Once an app has been quit, it does not prevent you from doing whatever you wish to that app’s preferences file.

I will add more as it arises…

(18 June 2017.)