When you’ve tried all the logical solutions, restarted, had a go in Safe mode, and still can’t solve a problem, you may need to bring the big guns to bear on it. These are radical fixes that carry a risk of going further than you want, but are all you’ve got left. You might have been recommended them by someone who seems to know best, or, as we saw last week, by an AI. This article looks at the state of those big guns in Tahoe 26.1, and which you should consider seriously.

Reset NVRAM and SMC

Although quick and simple to use, resetting the NVRAM and SMC are well known for fixing all sorts of problems. They’re still valuable in Intel Macs, but you can forget them in Apple silicon, as the SMC resets with each startup, and the NVRAM is protected from user access. The only way you could reset an Apple silicon Mac’s NVRAM is by Restoring it in DFU mode, which almost certainly isn’t something you want to do at this stage.

Reset TCC

TCC is the subsystem responsible for implementing privacy protection, and is notorious for its mystifying misbehaviour. Before convincing yourself that doing anything with TCC is going to help a problem, you should really look for a pattern of misbehaviour that points to one of the resources that it controls access to. If possible, tie this to a single app and use
sudo tccutil reset All com.apple.clock
for example to reset just that one app’s privacy settings.

TCC is also a popular recommendation in solutions that lack a firm logical basis, where there’s no attempt to target one app, but go for the lot with
sudo tccutil reset All
The effect of that is to empty every section (apart from Location Services) in Privacy & Security settings. That’s certain to stop many apps from working properly, and you’ll end up adding them back one by one over the following days or weeks. In some cases, even that doesn’t prove sufficient, and deleting TCC’s database seems the only way forward. That and other issues are discussed here.

tccutil doesn’t appear to have changed in any significant way in Tahoe.

Delete LaunchServices’ database

LaunchServices handles many features including opening apps, populating their Open Recent menu commands, and handling much of the integration of apps with their documents. To achieve that, it maintains an extensive database of apps and other executable components.

Access to LaunchServices’ database and control over it is provided in the lsregister command, buried deep in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support, although there’s a public lsappinfo tool that provides different features and is seldom used. Earlier this year I gave an account of its use in Sequoia, but its most popular option to kill the LaunchServices database has been removed from Tahoe “because it was dangerous and no longer useful”, a fair assessment.

Repair permissions

I have recently reexamined the various forms of repairing permissions. If anyone or anything recommends you run
sudo /usr/libexec/repair_packages --verify --standard-pkgs
you shouldn’t listen to another word they say, as that form went out with El Capitan, and isn’t even possible with a modern version of macOS.

The more modern replacement, initiated by the command repairHomePermissions in Recovery mode, may once have had a purpose, but is now grossly disruptive, as it locks the user out of most of the contents of their Home folder by removing them as their owner.

It would take you hours to restore your Mac to a usable state after performing that ‘repair’. If anyone recommends that you try it, ask them when they last used it successfully.

Clean install

Tahoe does provide convenient methods for clean installing macOS, as described here. One of the simplest is to Erase All Content and Settings using the EACAS option in Transfer or Reset, in General settings. That renders all your data inaccessible by securely erasing its encryption key, then you can migrate from your latest backup when setting up your currently installed version of macOS afresh.

If you want to go back to fresh firmware and macOS as well, then the simplest way is to Restore in DFU mode, as explained here. That also gives you the choice of using any compatible IPSW, making it possible to perform a full downgrade to an earlier version of macOS if you wish. Remember that Apple silicon Macs can’t run a version of macOS that was released before that model shipped. If in doubt, consult Mactracker’s database for the original version shipped with that model.

Summary for Apple silicon Macs:

• Resetting SMC and NVRAM is not possible (still available for Intel).
• Resetting TCC is still available.
• Killing the LaunchServices database is no longer available (but still in Sequoia).
• Repairing permissions is grossly disruptive and should be avoided.
• Clean install can be confined to the Data volume, or include firmware and macOS.

Whatever you choose, I wish you success.

Loose words confuse, and one of the words used most loosely in macOS is permissions. This explainer tries to separate them from other access controls.

Permissions

The access permissions of files and folders are set in their attributes in the file system, stay with that item, and are applied universally for all apps and processes that try to access them.

The simplest and most basic of access controls, these can be inspected and changed in the Finder’s Get Info dialog for all accessible files and folders. They control the ability of apps and other code to read from and write to each file and folder. Normally, if you’re the named owner of a file or folder, you expect to have both read and write access, and that ensures the apps you run with user privileges can open, edit and save changed files.

Permissions are relatively crude controls, so Access Control Lists (ACLs) can refine those permissions with more specific restrictions. They were introduced in Mac OS X 10.4 Tiger in 2005, and are now applied as standard to some widely used folders including the Home folder. The presence of ACLs is normally indicated in the Get Info dialog by the words You have custom access.

No matter what security controls and privacy protection might give you access to, they can’t override the fundamental limits imposed by permissions, and can only limit access further.

Security controls

The macOS security system imposes its own controls according to its rules. Most obvious among those are System Integrity Protection (SIP) and sandboxing.

SIP was introduced in 2015 with El Capitan, and primarily puts system folders, files and some components, including certain extended attributes, beyond the reach of even the root user. The only way to get past SIP is to disable it, a serious undertaking as it has more general effects on security.

Sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as set by their entitlements. It’s therefore determined by the app trying to access files, and doesn’t apply to apps that don’t run in the sandbox. As an app’s entitlements are baked into its signature, there’s nothing a user can do to alter them.

Privacy protection

macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Although it has a longer history, this was first implemented in its current form in macOS 10.14 Mojave in 2018, and since then has grown with every new major version of macOS. Privacy protection operates outside of file attributes, using a rule-based system applied to each app, and applies to command tools and other processes as well.

Among the folders this protects are the Desktop, Documents, Downloads, and those on removable storage. While access to individual folders is controlled, if you do encounter problems it’s usually simplest to add that app to the list of those with Full Disk Access, in Privacy & Security settings, in the first instance. That can leave a lot of apps with unnecessary access to private data, so you should periodically check through the list of apps with Full Disk Access to ensure they all still require it. Remember that Full Disk Access can’t override restrictions imposed by permissions or ACLs.

In Tahoe, privacy-protected folders include:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage
• removable volumes
• network volumes
• Time Machine backups.

Unlike permissions and security controls, there’s no command line interface to these controls, which can only be accessed by the user in Privacy & Security settings. As a result, TCC uses an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied. For example, when you run commands in Terminal, the privacy settings used by TCC are those of the Terminal app, while helper apps are normally the responsibility of their parent app.

Privacy protection is built around the user’s consent and intent. When a process tries to save a file to a protected folder that it doesn’t already have access to, you should be prompted to give your consent before TCC allows that. Alternatively, when an app tries that, it should display the File Save dialog, where you can express your intent to save the file to that folder. Without consent or intent, TCC should block that file from being saved there unless that app has been given Full Disk Access in Privacy & Security settings.

Privacy protection is the most complex and opaque of these, and can present the toughest problems to solve.

Key points

• Permissions by attributes
• Security by security system
• Privacy protection by TCC, the app and rules
• Loose words confuse.

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.

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.