I have updated to MacOS 10.14 Mojave and appear to be running into an issue with URBackup. When the backups run I get an immediate failure while the index process is running. Looking at the URBackup log file it appears to be a folder access issue. 0-1537924949-Backing up "Eric" without snapshot. 2-1537924949-Error while getting files in folder "/Users/Eric/Library/Application Support/AddressBook". User may not have permissions to access this folder. Errno is 1 2-1537924949-Constructing of filelist of "Eric_MBP" failed: error - index error 2-1537924958-Backup had an early error. Deleting partial backup.
Once this error occurs the backup process fails.
I’ve looked at the permissions on the directory in question and they are drwx------ indicating that the owner had full access but nobody else. It seems odd that the urbackup client, which is running under root, would have issues accessing this directory. Any suggestions on how to resolve this issue? I’ve tried changing the permissions on the folder to allow all users access but no change, the backup still fails.
Also, why would URBackup stop trying to backup when it gets an access denied message, shouldn’t it just continue on?
The client is version 2.2.6 and the server is version 2.2.11.
An update to this issue. I excluded the entire /User/Eric/Library/ directory from being backed up and got a bit further. Now the error occurs with the macos Photo Library folder. This appears to be a global issue with the MacOS client and the latest version of MacOS
I didn’t see your reply until after I posted my last update. That bug describes exactly what I’m seeing. It sounds like the MacOS URBackup client will need to be rebuilt with the MacOS 10.14 SDK. Great fun.
Your app will proably need Full Disk Access (FDA) in order to work properly. Unfortunately there seems no API to request or even check for FDA.
OP then tries to manually allow FDA for his app, which fails. Is only able to add his app to FDA (via GUI) after recompiling via an XCode beta version, after which backups still fail.
So you might want to try giving the background daemon FDA rights via GUI if you want to help.
Applications which require Full Disk Access in macOS 10.14 Mojave must instruct their users to navigate into System Preferences > Security & Privacy > Full Disk Access and add the application to the whitelist. This procedure is complicated and will frustrate new users of such an app.
I mis-understood what the poster was describing on the Apple site. I thought he only had success after rebuilding his app. I can say that adding the urbackup client to the FDA list in MacOS resolved the issue, backups are running again. Thank you for all your help!
Well, this issue is partially fixed. While adding the URBackup client to the allow list in Full Disk Access does work, I have to re-do it after every reboot of the Mac. I’m not sure if this is a Mac OS issue or a URBackup client issue.
Yep, that full disk access fix is just temporary, right now I created a group for Mohave machines and exclude the folders that UrBackup doesn’t have permissions to. This is critical, because some of these folders should be backed up.
For the record, I had significant issues when I upgraded to Mojave from High Sierra:
Although my machine would run smoothly for days at a time, every so often the tccd process would spin out of control and eat all my CPU time. After much searching, I seemed to wrestle it back under control by uninstalling the Urbackup macOS client.
As part of my troubleshooting, I had updated the client to the latest beta version (2.3.1) and added Urbackup Client and urbackupclientgui to my list of Full Disk Access apps - but it still seemed to cause problems. Only uninstalling completely seemed to (so far) resolve it.
No - I just completely uninstalled it, in order to prove to myself that the client app was definitely the cause of my high tccd CPU load - and once I had uninstalled it, I didn’t get a single case of tccd going out of control.
Since the 10.14.1 update, I’ve tried reinstalling the client app (only v2.2.6 at present); for the first day or so, all looked well - but today I’ve had the tccd process spin out of control again.
I’ll double-verify the issue by uninstalling the client app again and monitoring, and then I’ll try the v2.3.1 client app in a few days if all seems quiet again.
I’ve just tried running dtruss on the tccd process. The most-commonly returned line is:
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid user access in action #5 at DIF offset 0
Process ID 159 is authd at the moment.
FWIW, the Urbackup client is currently installed - but idle. Yet tccd is currently running at ~50% CPU usage. (In the past, before uninstalling it, I’ve seen it bloom up to >1000% CPU usage.)
So…
I’ve now unloaded the urbackupclientbackend - and all those entries from dtruss have stopped, and tccd is running with 0.0% CPU usage.
In System Preferences > Security & Privacy > Privacy > Full Disk Access, I currently have urbackupclientgui and Urbackup Client.app listed - but I haven’t explicitly tried adding urbackupclientbackend yet.
Initial impressions look favourable for this - tccd is still at 0.0% CPU usage. I’ll see how it fairs, and will report back if the problem returns.
Yep - even with urbackupclientbackend in the FDA list, I’m still getting warnings about folders which it can’t access. I’m adding them to my exclusion list as they come up.
Where is this file?
Edit: Answered my own question, it’s in the package contents: Right-click package, show package contents, MacOS, resources, sbin (I believe it was).
For the record, it’s generally been stable since - but tccd still seems to spin out of control every so often. I also get occasional UI hangs - which I suspect is due to tccd. I’m wondering if the Full Disk Access feature is just not yet completely stable (currently running macOS 10.14.1).
I haven’t yet updated to the latest client beta - still running 2.2.6.
This is now affecting some of my clients too, thanks Apple!
I realise it’s not the fault of the urbackup client but is there an definite fix in the works?
There is no fixing this. Apple has made it so you can only give applications FDA rights by manually doing it via UI (probably on purpose). The only thing an app can do is give detailed instructions with pictures.