Normal view

There are new articles available, click to refresh the page.
Yesterday — 27 October 2025Main stream

Should you repair permissions?

By: hoakley
27 October 2025 at 15:30

For much of the last 25 years, macOS has had ill-defined and pervasive problems that have often been attributed to incorrect permissions in various parts of the file system. As a result, one of the common panaceas has been to repair those permissions, using procedures that have changed over those years.

Repair disk permissions

Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, these problems generally resulted from files within the system acquiring incorrect permissions. To address this, Disk Utility had a feature to check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in those older versions.

Repairing permissions is no longer the panacea that it once was, but is part of checking general disk health.

Although primarily intended to deliver better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files that were protected by SIP.

Reset user permissions

When macOS 10.12 Sierra was released, a different problem appeared, in which permissions were apparently set incorrectly not in system files generally, but in the user’s Home folder, specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that the cfprefsd service took on management of those preference files, and just one year after repairing disk permissions ceased.

At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:

  • 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 appear warning that the startup disk has no more space available for app memory;
  • Safari or SafariDAVClient use large amounts of resources (memory);
  • the Mac runs very slowly;
  • iTunes cannot sync a device;
  • there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.

Most if not all of those could have been attributable to problems resulting from bugs in cfprefsd.

Repair Home permissions

Five years ago, Apple changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, when Big Sur was in beta in June 2020, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.

Running repairHomePermissions from Terminal in Recovery launches a GUI app to repair permissions on a selected Home folder on the Data volume. However, I strongly recommend that you don’t try using this, as you’ll end up with the user being locked out of every folder in their Home folder. I have tried it three times in virtual machines, and each time I have had to discard that VM because of the problems it caused.

Delete a corrupt preference file

Regardless of those, there are still occasions when preference files can cause problems. These typically occur when a corrupt or damaged preference file causes an app or other code to crash, usually when it’s being launched. Although these are now far less common, and the SSV ensures that system files can’t become corrupted as they did in the days before SIP, it’s useful to know how to deal with them.

On most occasions, a preference file can be deleted in the normal way, either in Finder or Terminal, and it won’t return until that app is run again, as it won’t currently be managed by cfprefsd. The alternative is to use defaults:
defaults delete com.mycompany.appname
deletes all the key-value pairs within the preference file for com.mycompany.appname, leaving just the empty property list. This has the advantage that it can be used when cfprefsd is managing that file’s contents, so should always be reliable. Provided the app handles preferences correctly using UserDefaults, it should be able to repopulate the empty property list the next time that app is launched.

One significant caution is when working with files inside ~/Library/Containers,~/Library/Group Containers,~/Library/Daemon Containers and similar managed folders. Because these form sandboxes, macOS manages them differently and tampering with their contents is likely to have unintended effects, so is best avoided, although the defaults command should still be safe.

Summary

  • Repairing disk permissions on system files ceased with SIP in El Capitan.
  • Repairing permissions on Home folder preference files is no longer recommended by Apple, since Big Sur.
  • Safe and robust deletion of contents of a preference file can be performed using defaults delete.
  • Don’t tamper with files inside ~/Library/Containers, ~/Library/Group Containers and similar folders.
  • Never be tempted to run repairHomePermissions in Recovery mode.

❌
❌