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.