Awesome!
Summoning @gchen for that
Yea… except in my case the lift was intentionally permanent (I mess with .kexts a lot) and its not that I forgot to revert it back – I forgot that my config is special in any way… I’t my “normal”. It’s like herd immunity – if majority of users keep it enabled malware can’t spread so those like me who have to have it disabled are also protected 
I’m having this same issue but with CLI 2.5.0 on macOS Catalina 10.15.4. I’m able to do backups fine without VSS but when I use it I similarly get an Error 77. I also get the same information in the logs that @pdp8user is seeing.
Is there something I can do I my end to get it working?
Some additional information:
When I first launched the application I received a message saying that the application can’t be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information. I was able to open it after going to the Security control panel and clicking allow after reading that the app was blocked because “it is not from an identified developer”.
When I run the codesign command, I get a “valid on disk” and “satisfies it’s Designated Requirement” message.
I have both the Web Edition and the CLI version on my Mac.
Did you read this topic? This specifically:
I did do that but with the CLI 2.5.0 executable:
I confirmed that SIP is turned on and secure boot is enabled to allow full security.
I was also able to make and list Time Machine snapshots by doing the following:
This is the command I’m running and output I’m seeing:
White:Test2 indoracer$ duplicacy -log backup -vss
2020-04-12 03:21:58.478 INFO STORAGE_SET Storage set to gcd://Backups/Duplicacy
2020-04-12 03:22:06.323 INFO BACKUP_START Last backup at revision 1 found
2020-04-12 03:22:06.912 ERROR VSS_CREATE Error while mounting snapshot: exit status 77
Try it with giving full disk access to the Web Edition:
You may have to do it with both the Web & CLI editions.
I’m certainly running with SIP turned on. Mine was working on the CLI without setting Full Disk Access for it, but that was before the update to 2.5.0 . It will be interesting to see whether I have to add that when the update comes through. The Web edition normally updates itself automatically, so I’ll keep a close eye on things.
Ok, let’s take a step back here.
Do you have the same issue with the standalone command line executable when you run it from the command line manually, outside of duplciacy_web or from duplicacy_web?
You have added “duplicacy” which does not match either of executables.
If you run it from duplicacy_web – you need to add duplicacy_web into the whitelist.
I did make sure the Duplicacy Web Edition has full disk access as well as the CLI version. @saspus asked why there was a discrepancy in the filenames of the executable. I renamed the original executable to duplicacy. I can confirm that adding the vss option to a backup on the Web Edition results in a successful backup:
Options: [-log backup -storage Desktop -vss -stats]
2020-04-12 12:55:39.067 INFO REPOSITORY_SET Repository set to /Users/indoracer/Desktop/Duplicacy/Test2 copy
2020-04-12 12:55:39.067 INFO STORAGE_SET Storage set to /Users/indoracer/Desktop/Duplicacy/Backup
2020-04-12 12:55:39.080 INFO BACKUP_START Last backup at revision 3 found
2020-04-12 12:55:39.374 INFO VSS_DONE Shadow copy created and mounted at /tmp/snp_778725703
2020-04-12 12:55:39.374 INFO BACKUP_INDEXING Indexing /Users/indoracer/Desktop/Duplicacy/Test2 copy
2020-04-12 12:55:39.374 INFO SNAPSHOT_FILTER Parsing filter file /Users/indoracer/.duplicacy-web/repositories/localhost/0/.duplicacy/filters
2020-04-12 12:55:39.374 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2020-04-12 12:55:39.516 INFO UPLOAD_FILE Uploaded t1 copy.txt (3)
2020-04-12 12:55:39.516 INFO UPLOAD_FILE Uploaded t2 copy.txt (12)
2020-04-12 12:55:39.517 INFO BACKUP_END Backup for /Users/indoracer/Desktop/Duplicacy/Test2 copy at revision 4 completed
2020-04-12 12:55:39.517 INFO BACKUP_STATS Files: 5 total, 6K bytes; 2 new, 15 bytes
2020-04-12 12:55:39.517 INFO BACKUP_STATS File chunks: 3 total, 6K bytes; 0 new, 0 bytes, 0 bytes uploaded
2020-04-12 12:55:39.517 INFO BACKUP_STATS Metadata chunks: 3 total, 1K bytes; 3 new, 1K bytes, 716 bytes uploaded
2020-04-12 12:55:39.517 INFO BACKUP_STATS All chunks: 6 total, 7K bytes; 3 new, 1K bytes, 716 bytes uploaded
2020-04-12 12:55:39.517 INFO BACKUP_STATS Total running time: 00:00:01
2020-04-12 12:55:39.674 INFO VSS_DELETE Shadow copy unmounted and deleted at /tmp/snp_778725703
It didn’t however fix this issue with the CLI version I’m seeing.
I’m still having issues with the CLI version although I’m able to make a successful backup with vss enabled with the Web Edition.
I have renamed duplicacy_osx_x64_2.5.0 to duplicacy and moved it to my /usr/local/bin directory. I also moved a freshly downloaded duplicacy_osx_x64_2.5.0 (to make sure the re-naming wasn’t causing an issue) to the /usr/local/bin directory and have made sure to grant both of them Full Disk Access:
When I run the duplicacy_osx_x64_2.5.0 from /usr/local/bin and also from ~/.duplicacy-web/bin I also see an Error 77 message.
Something to note, when I ran the CLI versions for the first time I was presented with a message saying:
“Apple cannot check for malicious software. This software needs to be updated. Contact the developer for more information.”
Compare this to the message I get when I first run Duplicacy Web Edition:
“Duplicacy Web Edition” is an app downloaded form the Internet. Are you sure you want to open it?
I’m not sure if this may the issue. I would also like to say I appreciate the great product support on the forums.
The CLI is signed but not notarized while the web GUI is notarized. Maybe that is why you got the ‘cannot check for malicious software’ warning. I’ll upload a notarized version of the CLI for you to test.
Can you try the notarized version at https://acrosync.com/duplicacy/duplicacy_osx_x64_2.5.0_notarized?
It runs without any warning message which is great, however, I’m still getting an exit status 77 error message:
indoracer@White Test1 % chmod 755 /Users/indoracer/Downloads/duplicacy_osx_x64_2.5.0_notarized
indoracer@White Test1 % /Users/indoracer/Downloads/duplicacy_osx_x64_2.5.0_notarized -log backup -vss
2020-04-12 21:27:07.615 INFO STORAGE_SET Storage set to /Users/indoracer/Desktop/Duplicacy/Backup/
2020-04-12 21:27:07.659 INFO BACKUP_START Last backup at revision 3 found
2020-04-12 21:27:08.094 ERROR VSS_CREATE Error while mounting snapshot: exit status 77
This message shows up in my console:
kernel (Sandbox)
Sandbox: mount_apfs(3920) System Policy: deny(1) fs-snapshot-mount /private/tmp/snp_468036566
Please note I did grant the notarized application full disk access permissions as is suggested in an earlier reply.
Interesting indeed! It works for me, whereas the non-notarized version of 2.5.0 comes up with the “malicious software” warning.
brian@brianmacbook-3 ~/.d/r/l/11> /Users/brian/Software/Duplicacy/duplicacy_osx_x64_2.5.0_notarized backup -vss
Repository set to /Users
Storage set to /Volumes/Duplicacy-4TB/Duplicacy
Last backup at revision 159 found
Shadow copy created and mounted at /tmp/snp_735424385
Indexing /Users
I did not do anything in the way of granting permissions, except to make the downloaded file executable with chmod.
I’m using MacOS 10.15.4
I may have understood the cause of the issue. As mentioned by @saspus disabling SIP may fix the problem on MacOS 10.5.4. As you mentioned in a prior post, It appears that something changed with sandboxing between the 10.15.3 and 10.15.4.
I ran the CLI version with vss on MacOS 10.15.3 on a second machine with success. When I upgraded that machine to 10.15.4 it gave an error when running the same command.
@gchen After disabling SIP (System Integrity Protection) on my first computer running 10.15.4, I was successfully able to run the CLI version with vss. For me, giving full disk permissions to the application didn’t resolve the vss issue.
I’m working through the same thing right now and my understanding (one source) is that simple binary executables (the CLI app) can’t be added to the Full Disk Access list. Terminal.app can be added to enable on demand backups, or you could use Platypus to create a wrapper app to run a script to run duplicacy with the arguments you’ve selected.
My current work around is the Platypus app. The downside is that even when set to background and no icon, it steals focus on launch.
Thanks for sharing. Granting the Terminal.app to full disk access or using Platypus to create a script wrapper app and giving it full disk access are better options than disabling SIP.
I just ran into this same issue, because I was running Duplicacy from a script via launchd (which means that, except for disabling SIP, none of the solutions suggested above would be applicable, I think).
For those who are in a similar situation, I finally managed to make it work using the fdautil shipped with LaunchControl, which was written specifically for granting Full Disk Access to launchd entries. (The instructions for how to use the util are in the Help section of the app, not anywhere online).
And here is today’s Arq’s announcement:
NEW: Filesystem Snapshots for Perfect Backups
Arq 7 uses filesystem “snapshots”, so each backup record is a perfectly consistent copy of your files, even if files are being modified during the backup process. For macOS we worked with Apple to get special access to the APFS API to deliver this.
It is definitely doable…