Shadow copy -vss fails on macOS Big Sur

Support
#1

We gave ‘Duplicacy’ a try on our Big Sur Beta 9 installation. The -vss option fails

‘’’
❯ sudo duplicacy backup -dry-run -stats -vss
Repository set to /Users/mb
Storage set to one://Duplicacy
Last backup at revision 79 found
Error while using ‘tmutil listlocalsnapshots’ to find snapshot name. Will fallback to ‘com.apple.TimeMachine.SNAPSHOT_DATE’
Error while mounting snapshot: exit status 66
‘’’

The snapshot is generated:

‘’’
❯ tmutil listlocalsnapshots .
Snapshots for disk .:
com.apple.TimeMachine.2020-10-07-093056.local
com.apple.TimeMachine.2020-10-07-105306.local
com.apple.TimeMachine.2020-10-07-122020.local
com_haystacksoftware_arqagent_CF0A04FC-192D-44C6-A286-7D3BAE105A78_2
‘’’

Duplicacy version was 2.7.1 (7DA58C) for the test…

#2

This should be fixed by Change snapshot source path from / to /System/Volumes/Data · gilbertchen/duplicacy@7c36311 · GitHub which will be included in the next CLI release.

Thanks to @saspus for the advice on how to fix it.

#3

On our system the changes fixed the problems if we run ‘duplicacy’ from our user login… We have SIP enabled and have given ‘duplicacy’ full disk access.

If we generate a LaunchAgent (executing with our user permissions) we get the following error when we try to execute ‘duplicacy’:

Sun Oct 11 19:02:40 AST 2020: Duplicacy operation started…
Repository set to /Users/mb
Storage set to one://Duplicacy
Sun Oct 11 19:05:00 AST 2020: Duplicacy operation started…
Repository set to /Users/mb
Storage set to one://Duplicacy
Last backup at revision 79 found
Error while mounting snapshot: exit status 77
Sun Oct 11 19:05:11 AST 2020: Duplicacy operation finished.

It looks like there are some tighter restrictions about mounting snapshots in Big Sur… As ‘Carbon Copy Cloner’ and ‘Arq’ are happily generating snapshots (I think by native methods, not using ‘tmutil’!) even when executing there daemons there should be a way to do it…

#4

Are you talking about Duplicacy-web or command line Duplicacy? You cannot grant full disk access to a non-bundle app (you can add it to the list but it has no effect)

If you are running lauch agent — why is it with user permissions? Perhaps try launch daemon instead.

#5

We are using a cli version we generated after gilbertchen made the correction. We are a ‘user’ login as duplicacy has to get the options under ~/.duplicacy…

#6

Just some additional information. We did not find a way to prevent “exit status 77” when we execute duplicacy out of launchd. We tried to authorize launchd for full disk access and also placed the launchd file into /Library/LaunchDaemons - both no cure for the problem.

Terminal execution is working because we authorized iTerm for full disk access and executed duplicacy out of there, as saps noted granting full disk access to a binary excitable has no effect.

For us this is currently a show stopper as we backup active virtual machines…

So I am open for any ideas…

#7

To limit the scope of the discussion somewhat – I assume you are trying to run backup for the current user only, (i.e. access to other users data is not required – because that is another can of worms), and hence you are running your agent under user credentials and the launchd plist is located under ~/Library/LaunchAgents, correct?

If this is the case, and SIP is enabled, duplicacy will be unable to do anything sensitive, including mounting time machine local snapshot, for the same reason you mentioned – that it is not a bundle and hence cannot be granted the privileges. You can’t add launchd to exclusions either because that would defeat the whole point of it – everything is launched by launchd :slight_smile:

@gchen planned to address this and make a bundle to wrap duplciacy CLI engine and thus make the full disk permission grantable – see this comment Burning macOS issues

To confirm that this is indeed the issue you can boot to Recovery Partition, run terminal there and disable SIP by running csrutil disable. Then boot and see if Duplicacy works. This will confirm that there are no other issues. (to re-enable SIP back – run csrutil enable in the recovery terminal)

#8

Hi saspus, I did not test the disabled SIP - I do not want to disable on my Big Sur test system as it is the only one… But I was picking up Your idea with an app-wrapper. I was using an app called ‘Platypus.app’ for a while and it takes literally 2 minutes to create the wrapper with this app. Working fine out of launchd!!!

2 Likes
#9

Interesting. Neve heard of platypus; I’ve created wrapper in Automator — since it’s already there. But then on most of my Macs SIP is disabled so that is not an issue.

Glad it worked for you.

1 Like
#10

Any thoughts on when this fix will be released now that Big Sur is available to all? Against my better judgment I’m likely going to install today and I know I’ll probably hit this issue.

#11

I’ll make a new CLI release over the weekend (or maybe Monday the latest).

2 Likes
#12

This is the way. I have been using Platypus to create a wrapper app and it also works fine with launch agents with SIP enabled.

I actually have it launch duplicacy-util which in turn launches duplicacy. If you haven’t checked out duplicacy-util I highly recommend it.