Main navigation

Fixing problems with preference files

Sometimes it is obvious that an app, system setting, or other software, is having problems with its preference file: the most common symptoms are that you make a change to its settings which won’t take, or keep getting forgotten – they don’t ‘stick’ properly.

There are also a lot of problems which are less obviously related to preference files, but which are fixed by getting the preference file(s) right. These can be as diverse as your Wi-Fi not working, apps unexpectedly quitting when you try to open them, and more.

This article takes you through some effective steps which you can use to check and correct preference file problems; they can also apply to some other files which support specific features, and are found in your Home or main Library folders, ~/Library or /Library.

One app or feature is malfunctioning

If just one thing isn’t working, the quickest way to tackle it is to check its preference file. The locations of most commonly-used preference files, and advice on working out where others might be, are listed here for Sierra, and here for El Capitan. They can change unexpectedly: because Apple considers that users shouldn’t have to access them, their names and locations can change at the drop of an update.

Locate the Property List (.plist) file in Finder, remembering that you have to hold down the Option key for Finder’s Go menu to list the Library in your Home folder, and use the Finder’s Get Info command to inspect their permissions and settings. These are considered below.

Multiple apps or features are malfunctioning, or you don’t know what to look at

If you are unsure what the problem is, or it seems to affect several apps or features, then one way of checking your preference files is using PermissionScanner, free from Downloads above. I regret that this does not work in El Capitan, because of limitations imposed by Apple in its Xcode SDK.

For your first scan, set it to look at your Home Preferences, to check that they are writable, then click Scan folder. This will check that all the files in ~/Library/Preferences can be written by you as a user, and should return an empty list.

If it doesn’t, check each of the files which it lists, using the Finder’s Get Info command, as shown below.

Another useful scan to run is on /Library/Preferences, this time checking that all its files are readable. As you can see above, you may get some ‘hits’ from Property Lists maintained by Apple software, but the list should be very short. If you inspect those with Finder’s Get Info, you will see that those few files are locked from all users apart from root. You should not attempt to change that.

The Get Info dialog

When you Get Info on a file which you think you should have better access to, check two sections:

that the file is not locked; if the Locked box is ticked, untick it to ensure that it is writable as well as readable;

that you, as a user, have Read & Write access to files in ~/Library/Preferences, or at least Read access (either as everyone or Administrators) to others.

To change those permissions, you will need to click on the padlock icon at the bottom right and authenticate first, then make the changes and save them.

Container problems

Many apps – including those bundled by Apple with macOS, and those delivered by the App Store – now run in a ‘sandbox’. This defines exactly what they can and cannot do, and limits their access to resources such as preference files. Instead of using ~/Library/Preferences to keep their preference files, they now use files stored in a hierarchy in their container. These have long paths running something like ~/Library/Containers/com.apple.TextEdit/Data/Library/Preferences/com.apple.TextEdit.plist.

There was a time when those container paths usually linked to a preference file in ~/Library/Preferences, but that simple arrangement has now stopped. So many apps now have two preference files: one in ~/Library/Preferences, which seems little-used, the other in their container, with a path starting ~/Library/Containers.

The second beta release of PermissionScanner now has another scan option Home All Prefs. This is specifically aimed at detecting problems with preference files. It scans all Preferences folders found in ~/Library, which includes the old ~/Library/Preferences folder, the many Preferences folders found in containers, and any others which are tucked away.

It filters out aliases to other files, and only reports actual files which have permission problems in those Preferences folders. This greatly reduces the number of ‘hits’, but should cover all the preference files which you should expect to have permission to write to. This scan does take a couple of minutes to complete, but you should find it particularly helpful.

This second beta of PermissionScanner is available in Downloads above.

The sledgehammer

If you believe that you have a permissions problem in your Home folder, but cannot track it down using PermissionScanner, one answer is to use my free RepairHomePermissions (from Downloads), which will repair permissions on all the files in your Home folder, including those in containers. It may also change permissions on a lot of other files, some of which you don’t want to be changed, but that is the remaining solution.

Correcting permissions doesn’t fix the problem

If you’re convinced that this is most likely to be a problem with one or more preference files, and correcting their permissions does not help, you can always resort to the old technique of trashing the preference file and setting the app up again.

Why some apps won’t open when their preferences are broken

Apps have a choice of at least two different ways of handling their preference files. In the traditional method, when the app opens, it tries to read the preference file. If there is a problem with that, it should handle that gracefully, but not all apps do, and some may crash as a result. A few apps cannot handle being unable to write to their preference file properly, and that may make them crash, when you have changed your settings.

Unexpected quits seem more common with apps which use a different way of managing their preference files: they keep the file open, served to them by cfprefsd. You will normally find one instance of cfprefsd for each user, including root, even including users who are not currently logged in.

These are listed in Activity Monitor; select your instance of cfprefsd and click on the Disk tab, then on the Info tool at the top left of Activity Monitor’s window. Finally, click on the Open Files and Ports tab, and you will see a list of preference files which cfprefsd is currently managing for that user. This is particularly valuable, as it tells you the full path to the managed preference file.