Full Disk Access on macOS

Support
#1

I came across a post by an unhappy (former) user: Do not use Duplicacy on macOS

He posted something similar here but he asked me to delete his account. After I did that all his posts as well as the entire thread were gone.

The main criticism seems to be that private directories can’t be backed up even if you whitelist the web GUI in the Full Disk Access list because it is the CLI that does the actual backup. However, this is not the case in my tests on my mac running 10.15.5. I have no problem backing up directories like ~/Libraries/Mail or using the -vss option after adding the web GUI to the list. And they would all fail otherwise.

There is no official doc from Apple on Full Disk Access, but the closest one I can find seems to confirm that Full Disk Access is inheritable by child processes: The Rules for Full Disk Access | Apple Developer Forums

Specifically:

…whitelisting a certain .app will enable its main executable and any child processes…

Does any macOS user still have problems accessing those private directories after enabling the web GUI with Full Disk Access?

Another criticism was that he didn’t know where the CLI is downloaded from and felt unsafe. The CLI is actually downloaded from the github release page using github’s API, so it is as safe as manually downloading and running the binaries from the same page.

#2
  1. No, there are no issues with whitelisting Duplicacy Web for me either. There are issues with attempts to whitelist the duplicacy CLI to use it explicitly: macOS does not seem to like to whitelist naked binaries but it works fine for bundles. The workaround is therefore to make a bundle by wrapping duplicacy to automator script. I don’t know whether this is a bug or not – but I would report it to Apple. Regardless, this is not the issue that that post discussed.

What likely happened the user did not relaunch duplicacy_web after adding it to the full disk access white list.

  1. Didn’t know where the CLI is downloaded from and felt unsafe. So the user trusted closed source executable to run any code on his/her machine as long as that code is not https download? Does not sound reasonable to me.

While the writeup is terribly sensationalist and mostly factually incorrect he/she does make one valid point: Duplicacy must notify the user and explicitly ask to be added to Full Disk Access on macOS when it encounters that protected folders were added to the backup set (or simply always). For example of the UX have a look at how Daisy Disk handles it.

2 Likes
Mac LIST_FAILURE from sandboxing
#3

I ran into this issue as well, and then found this (old) post. Running 2.7.2 on a new MBA M1. I tried first giving the duplicacy executable full-disk access, but for some reason that did not work. What does work is to give cron full disk access (although that feels a bit extreme to me).

Also came across that “Do not use …” article. More frustration than fact if you ask me …

Update: perhaps FDA is not possible on Intel executables, which need to run through Rosetta 2?

Errors with full backup on M1 MacBook Air
#4

Naked executables can’t be added to FDA it seems.

I use platypus to wrap it to app bundle and then add that bundle to FDA.

This is a script I put together to install duplicacy on my Macs.