Duplicacy on an M1 mac?

Has anyone else gotten Duplicacy GUI to work consistently on an M1 mac running macOS 12.0.1?

I’m backing up an SMB mounted share to a Wasabi account and after a couple of days I start getting lots of " wants access to keychain" dialog boxes, followed by the whole system locking up and needing a hard reboot. When I stop Duplicacy running the problems go away.

I moved to Duplicacy from Arq backup for the same reason: endless dialog boxes and system lockup. Uninstall Arq and the problems go away. Both apps had full disk access permissions.

I think something in macOS and system security changed between 11.x and 12.0.x that affects apps like Duplicacy that need disk access, share access and scheduling of background processes. From what I’ve heard x86 macs are not affected.

Any advice much appreciated,


Something is specific to your configuration.

It so happens that I run both – duplicacy web under launchd (as described here) and Arq7 7.10 on my M1 mbp with macOS 21C5039b and SIP enabled, and don’t see any of the issues you describe.

What’s in the logs? (you can collect full set of logs with sudo sysdiagnose and then use log utility to parse the logarchive or dump logs from live system). What does csrutil status say?

How far did you go in your triage with Arq support? (So we don’t waste time trying what they have already tried)

Yes – that was in the back of my mind.

It so happens that I run both – duplicacy web under launchd (as described here) and Arq7 7.10 on my M1 mbp with macOS 21C5039b and SIP enabled, and don’t see any of the issues you describe.

That’s good to know.

Perusing the logs there are many entries for Duplicacy, e.g.

2021-11-15 16:00:02.963756+1100 0x1ac4a6 Default 0x0 34323 0 duplicacy_osx_x64_2.7.2: (Security) [com.apple.securityd:SecError] Trust evaluate failure: [leaf TemporalValidity]

And csrutil says:

csrutil status
System Integrity Protection status: enabled.

I’ll restart Duplicacy and wait until the dialogs and lock-ups restart then use the log utility to search for relevant entries. Are there specific log entry types or keywords I should look for?

After I uninstalled Arq I found Duplicacy and preferred the web GUI so stopped any further debugging or analysis of my Arq setup.

Interesting! This indicates the (signing?) certificate chain fails validity check due to either no-valid-before or not-valid-after checks. Maybe you have stale certificate stuck somewhere?

Can you try validating the certificate chain via codesign -vv <path-to-bundle>?

Please excuse my ignorance (I use a Mac but mostly develop for Linux or command line use), but where is the bundle for Duplicacy?


Okay, tried this:

codesign -vv /Applications/Duplicacy\ Web\ Edition.app/Contents/MacOS/duplicacy_web_osx_x64
/Applications/Duplicacy Web Edition.app/Contents/MacOS/duplicacy_web_osx_x64: valid on disk
/Applications/Duplicacy Web Edition.app/Contents/MacOS/duplicacy_web_osx_x64: satisfies its Designated Requirement


Great. So the signature is valid. Please also check for ~/.duplicacy_web/bin/duplicacy_cli binary (I think it is only notarized?)

Lets check the certificate chain. I’m not sure if there is an easier way – but this what worked for me:

% mkdir -p /tmp/certs
% cd /tmp/certs

% codesign -d --verbose=4 --extract-certificates /Applications/Duplicacy\ Web\ Edition.app
# this will produce a bunch of codesing<number> files:

% ls
codesign0  codesign1  codesign2

# convert extracted certificates to text format
% find . -maxdepth 1 -name "codesign*" -exec openssl x509 -inform DER -in "{}" -text \; > allcerts.txt

# look at the file 
% open allcerts.txt

There will be all those certificates back to back. Look for “Not Before” and “Not After” statements, and make sure they are OK for today (They should be). Check if any of those certificates are invalid/blacklisted in the Keychain Access utility.

Do you have (or at any time had – nobody cleans up after themselves these days) any third party security software installed by a chance?

Okay, checking the before/after dates:

grep 'Not [BA]' allcerts.txt
            Not Before: Feb 12 16:08:48 2020 GMT
            Not After : Feb 12 16:08:48 2025 GMT
            Not Before: Feb  1 22:12:15 2012 GMT
            Not After : Feb  1 22:12:15 2027 GMT
            Not Before: Apr 25 21:40:36 2006 GMT
            Not After : Feb  9 21:40:36 2035 GMT

Now looking up how to check for invalid/blacklisted certs.

This is a clean installation of 12.0.1 with no third party security software installed.


Back again after a lockup and required hard restart (power button). I’ll start searching the logs for anything related to Duplicacy.


Not sure if this is relevant:

2021-11-22 18:40:41.169472+1100 0x10b4     Error       0x3b5a               156    0    tccd: [com.apple.TCC:access] Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for responsible={<TCCDProcess: identifier=com.duplicacy.web, pid=459, auid=501, euid=501, responsible_path=/Applications/Duplicacy Web Edition.app/Contents/MacOS/duplicacy_web_osx_x64, binary_path=/Applications/Duplicacy Web Edition.app/Contents/MacOS/duplicacy_web_osx_x64>}, accessing={<TCCDProcess: identifier=com.apple.open, pid=537, auid=501, euid=501, binary_path=/usr/bin/open>}, requesting={<TCCDProcess: identifier=com.apple.appleeventsd, pid=276, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd>},
2021-11-22 18:40:46.161836+1100 0x911      Default     0x53c6               179    0    runningboardd: (RunningBoard) [com.apple.runningboard:assertion] Invalidating assertion 179-155-232 (target:[daemon<duplicacy-web(501)>:459]) from originator [daemon<com.apple.WindowServer(88)>:155]
2021-11-22 18:40:46.267602+1100 0x910      Default     0x5419               179    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<duplicacy-web(501)>:459] Ignoring jetsam update because this process is not memory-managed
2021-11-22 18:40:46.267603+1100 0x910      Default     0x5419               179    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<duplicacy-web(501)>:459] Ignoring suspend because this process is not lifecycle managed
2021-11-22 18:40:46.267603+1100 0x910      Default     0x5419               179    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<duplicacy-web(501)>:459] Ignoring GPU update because this process is not GPU managed
2021-11-22 18:40:46.267610+1100 0x910      Default     0x5419               179    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [daemon<duplicacy-web(501)>:459] Skipping AppNap state - not lifecycle managed
2021-11-22 18:40:51.098402+1100 0x145b     Default     0x0                  459    2    duplicacy_web_osx_x64: (LaunchServices) [com.apple.launchservices:default] LSExceptions shared instance invalidated for timeout.

When it hangs – does the whole machine hang or just the UI? Is Mac still accessible over SSH?

If you let it sit there for 120 seconds after it hangs – does it throw you back to the login screen? Does it reboot? Or does it sit there indefinitely?

Can you capture sysdiagnose in that state? (Command+Option+Control+Shift+Period). It will be place to /private/var/tmp once done in a few minutes. Unpack it and look at memory state, locks, and spindump.txt to see who is waiting for what.

I don’t think it’s duplicacy (or arq). Usermode process cannot lock up the UI. Somethign else is wrong there. Look for WindowServer or watchdog related messages in the system log (you can use log show --info --debug --predicate 'message contains <keyword>' --last 10m).

With Arq there’s a cascade of dialog boxes asking for keychain access, which quickly become unclickable and untypeable. Then mouse, but not all keyboard and mouse input is frozen. I can still call up spotlight via the keyboard and launch terminal, but not type in it.

With Duplicacy, there’s a much small cascade of dialog boxes, but the same mostly, but not totally locked up keyboard and mouse.

After that only a hard reset with the power button will work to get access to the system. It’s quite happy to sit in that state for hours, still locked up.

I haven’t tried SSH’ing back in as my SSH sessions to external systems in iTerm can’t be typed in. I’ll need to round up a separate monitor and keyboard ona RPi or something to try that.

Thanks for the hints I’ll try that when I next startup Duplicacy and the system freezes again. Does that log message about kTCCServiceAppleEvents requires entitlement com.apple.security.automation shed any light on the situation?

I’m still puzzled over the central mystery: I may well have something wrong on my system, but the only applications (so far) that trigger that problem are Arq and Duplicacy. None of the browsers, programming tools, 3D design tools, office programs, system utilities or VM/container tools seem to trigger it.

I think Arq and Duplicacy are both x86 binaries? Could it be an interaction with some problem on my system and Rosetta? Both Arq and Duplicacy require schedulers, not sure if that’s relevant.

Thanks for your patient analysis–much appreciated,


Did you ever manage to click “Allow Always” to give them access? Not that it should matter really.

Which means it does not realize that it’s hung. that’s a bug on its own :slight_smile:

It’s probably harmless – means that hardened runtime was requested by the app but the entitlements to talk to apple events service were missing. At least if I understand this correctly Apple Developer Documentation. But this will just prevent an app from talking to that service.

Maybe it’s related to what the apps are doing? Maybe they are touching network services in a way that others don’t? What is the backup target? HTTPS target or some SMB/NFS/SFTP to or maybe even VFS stuff?

I thought so too, but while duplicacy is x64, Arq is luckily fat binary:

% file /Applications/Arq.app/Contents/MacOS/Arq
/Applications/Arq.app/Contents/MacOS/Arq: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
/Applications/Arq.app/Contents/MacOS/Arq (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Applications/Arq.app/Contents/MacOS/Arq (for architecture arm64):	Mach-O 64-bit executable arm64

Assuming that it was arm binary that was selected, the issue is probably not related to rosetta.

Duplicacy does not use OS scheduler, and Arq is using it only to launch itself – if that is what you mean.

This is clearly an issue with certificates. Unless there are some other failures preceding it?

Do you think it would be worthwhile to try to disable SIP?

WIth the hope to kill two birds with one shot:

  • See if the issue keep reproducing without SIP (i.e. if the whole hardened security thing has actually anything to do with this)
  • Re-enable it, with a hope that toggling it would clear out any possible shenanigans there?

(to disable sip you would need to boot into recovery (reboot holding Commadn+R), start terminal and exec csrutil disable and reboot. To re-enable – csrutil enable.