Each major release of macOS comes with its distinctive problems. In Mojave and Catalina, privacy protection is one area which we’ve had to learn from scratch. Just when you thought that you’d got the hang of it in 10.14, along comes 10.15 and adds a load more, much of which doesn’t work in the same way that 10.14 did. If you think you’ve hit a problem resulting from privacy protection in Catalina, here are some tips which should help you fix it (when possible), or at least confirm its cause.

1. Take a screenshot of any error alert or message, note the clock time, and how to reproduce the problem

We always think that we can clearly remember exactly what happened, but just a couple of minutes later it’s obvious that we don’t. If you see any alert or dialog resulting from the problem, take a quick screenshot there and then before you dismiss it. Look at the system clock (if you have it displayed in the menubar), and make a note of the time, estimating also when the action causing the problem took place, to the nearest second.

The screenshot will give you any error number or system reference, and the clock time will provide you with a good starting point when you come to locate entries in the log.

While it’s still fresh in your mind, write a short series of instructions to reproduce the error, and step through them to see if you can get it to happen a second time. If you can, then at least it’s reproducible on that system.

2. Check the obvious first: Permissions, user errors

The commonest causes of things failing are still commonest in Catalina. If you launch into a major investigation into what TCC has been up to, and the error was actually the result of incorrect permissions, you’re going to waste a lot of time getting nowhere. If your app is trying to write a file somewhere, ensure that location is specified correctly, and that it has appropriate permissions to do so. This is particularly true for Catalina, with its new Data and System volumes, which can make some well-used paths inaccessible.

If the error was generated by your own code, in an app of yours, script, or at the command line, check and re-check that section of code to ensure that you didn’t make a mistake.

3. Try using another location

Catalina’s new protected locations include ~/Desktop, ~/Documents, ~/Downloads, removable volumes, network volumes, iCloud and other (third-party) cloud storage. If file operations in one of those are affected, create another folder in your Home folder, perhaps named OtherDocs or similar, and try using that instead. If that works fine but one of the newly protected locations doesn’t, then that’s more than a strong hint that the problem is arising from this new set of protections.

Protection doesn’t appear to be applied consistently across all those locations, though: you may find that accessing Home folder contents is fine, but removable volumes fail every time. Not only do we not get to write the rules, we don’t get to know them either.

4. Check the Privacy lists: add to Full Disk Access

One quick fix to file access issues in Mojave, which still works in many situations in Catalina, is to add the app or command tool to the Full Disk Access list in the Privacy tab of the Security & Privacy pane. This may not work around per-file access for Catalina’s additional protected locations, but is a quick test which can bring instant relief.

Remember that giving a process Full Disk Access won’t normally take effect until that app is next opened, so quit the app first, add it to the Full Disk Access list, then open the app again.

When you’ve given an app or tool Full Disk Access in Catalina, it should automatically be added to the Files and Folders list too. If it isn’t, then there’s something wrong in that copy of macOS, and it’s probably worth resetting TCC’s privacy database, at least for that app/tool. This is described below.

If the app or tool is built by someone else, you might want to stop short at this point. You’ve now done pretty well everything a regular user can be expected to try, and this may be a good time to contact the vendor’s support service and pass the problem over to them. If you’re still curious, or if you are that support service, you’ll need to stay with me a while longer.

5. Check the log using Taccy or Ulbow

If you’re strongly suspicious that the problem lies in the privacy system TCC, now’s the time to take to the log. The easiest way to check privacy entries is in Taccy’s purpose-built log browser, which only shows entries from subsystems concerned with privacy. The latest version, 1.7, is specifically tailored to find even the most obscure privacy problem.

Open Taccy, and use the Open Log Browser command in the Window menu. Referring to the note you made of the time that the problem occurred (or using that from a deliberate repetition of the problem), enter times which will include the cause and effect of the problem and get the log excerpt.

Shown in red here is a series of messages from TCC concerning kTCCServiceSystemPolicyRemovableVolumes for the log command, culminating in a decision from com.apple.TCC:
Refusing TCCAccessRequest for service kTCCServiceSystemPolicyRemovableVolumes from client com.apple.security in background session
Following that, in grey denoting that these are messages from the kernel, are the key outcomes:
sandboxd rejected approval request from log for kTCCServiceSystemPolicyRemovableVolumes (/Volumes/External1/Documents/0newDownloads/Untitled.logarchive): denied
Sandbox: log(56308) System Policy: deny(1) file-write-create /Volumes/External1/Documents/0newDownloads/Untitled.logarchive

You can get identical results in the latest version of Ulbow. Before applying its TCC predicate, update that in its Preferences with the additional term
OR processID = 0
so that kernel messages are included, just as they are now in Taccy.

Set the Predicate to your improved version of TCC, and the Period to provide a short window around the moment at which the problem occurred. I have selected the most important lines in the log excerpt below.

In theory, you should now be able to ensure success by taking an action which will allow kTCCServiceSystemPolicyRemovableVolumes, such as adding the log tool to the Full Disk Access list, but in practice things seem more complicated.

6. Check the app or tool’s entitlements and Usage strings (Taccy)

With Taccy still open, drag and drop the app or tool onto its icon, so that you can inspect its entitlements, if any, any Usage strings to support access to protected resources, and get its signature and notarization checked.

Usage strings are considered preferable but optional for Catalina’s new protected folders and locations, but for protected devices they’re important. Taccy’s Help book takes you through all the details.

7. Try the command line

If you know how to do the same thing in Terminal, it’s worth trying it there to see if the result is any different. In my case, I was using an AppleScript cheat to run the log collect command as root, and discovered that when I did that directly using sudo, there were no problems with privacy protection. You can then use Taccy or Ulbow to browse the log for a successful outcome, which may give you clues as to how you can work around your problem.

8. Look for a quarantine flag and com.apple.macl xattr

If you can access the file(s) in certain locations, do so, then take a look at the extended attributes (xattrs) attached to it, using a utility like xattred.

Quarantine flags are now routinely written to files opened by sandboxed apps, so don’t be surprised to see one. They don’t appear to be associated with privacy problems, but are worth watching.

The xattr which is associated with Catalina’s protected folders is com.apple.macl, which is usually (but not always) protected by SIP, so you can’t remove it from the document or folder, which is a real pain. This xattr contains one or more UUIDs which are associated (somewhere) with (non-sandboxed) apps. Its purpose appears to be to maintain document access when files are moved between protected and unprotected folders: it seems to act as a whitelist which ensures that, no matter where that document goes, approved apps will continue to be able to access it.

It is also a hallmark of the per-file privacy protection system at work. Abandon hope all you who enter here.

9. (Developers) Build a version with everything enabled

If you’re getting nowhere fast and your app/tool is still getting turned down by TCC, try adding every possible Usage string (hint: TCC doesn’t check content or grammar, so just a token couple of words will do) and enable resource access to Apple Events and anything else appropriate in the Xcode Signing & Capabilities page. Coupled with enabling Full Disk Access, that is as far as you can go to pander to the whims of TCC.

10. Shots in the dark

Some advocate disabling SIP when confronted by these problems. Unless you really understand what you’re doing, this is almost always extremely unwise, and may have untoward side effects. For example, you’ll be able to intentionally remove com.apple.macl xattrs from files, but doing so may cause worse confusion. And if turning SIP off does work around your problem, does that mean you’ll leave it turned off?

The tccutil command can be used to reset the privacy database. Unless you fancy going back to ‘factory settings’, you should make this as specific as possible, and in the current release of Catalina, bundle-specific resets are now (at last) supported. To reset all privacy settings for a single app bundle signature, use the command
tccutil reset All com.mydomain.product
where com.mydomain.product is the bundle signature of that app. You can also refine that further to individual lists, such as AddressBook or Accessibility rather than All. Unfortunately, there doesn’t appear to be any fine control over per-file protection of folders: that seems to be accomplished by the com.apple.macl xattrs, which you can’t fiddle with because of SIP.

If the problem is occurring in an app made by someone else, then you should check its product support information, and contact its support service. Everything that you have been through above will then prove extremely helpful, first in demonstrating that this isn’t just user error, and in giving the app’s developers a head start in knowing how to reproduce the problem, and what to look for.

Finally, take comfort that even Preview can trip up on Catalina’s privacy protection, so you’re not alone.

References

Apple WWDC 2019 Session 701, Advances in macOS Security
Taccy Product Page
Ulbow and Consolation Product Page
xattred Product Page