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.
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)
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.
[/quote]
That’s good to know.
Perusing the logs there are many entries for Duplicacy, e.g.
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>?
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?
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.
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
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:
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.
