MacOS client 2021

Server is at 2.4.13. So that could possibly be an issue.
Is there any known issues with mac client 2.4.11 and server 2.4.13?

I’ll try with 2.4.x and see if there’s any improvement.

On the 2.4.x, I get an error on the Mac client when selecting the status of “There was an error. Currently nothing can be backed up.” And the Raspberry Pi server cannot detect the client.

On the 2.5.x beta, the Raspberry Pi server detects the Mac client, and the Mac client starts to index the files, but I cannot get the client to retain a back up path when I set it, and when I try to set the path at the server, it states there’s no back up path.

(I performed a full uninstall of the client before trying each version.)

Update on this: with client version 2.4.11 and server version 2.4.13 I’m able to successfully complete the installation, configuration, and backups without any GUI interaction. This is looking good for deployment through an MDM solution such as Jamf. Will be testing this throughout the next few days and can share details or struggles as they arise.

! Thanks Martin !

Thought I would share that I have been successful at deploying UrBackup to remote mac users with Jamf. It was fairly straight forward. I’m using mac client version 2.4.11 and server version 2.4.13.

I created a new group on the server with the settings I desired. (wildcards are not acceptable when defining a backup directory)
I uploaded the client .pkg in Jamf Admin.
I built a .mobileconfig to allow UrBackup Full Disk Access using PPPC and uploaded it as a profile into Jamf and pushed.
I wrote a super simple script in Jamf with the following:

#!/bin/bash

# modifies settings for urbackup to point to the server and aquire settings from the server

# we'll need 2 parameters: the name of the client that was generated on the server and the internet auth key
# $4 = clientname
# $5 = internet_authkey

/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl set-settings -k internet_mode_enabled -v true 
/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl set-settings -k internet_server -v <url>
/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl set-settings -k internet_server_port -v 55415
/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl set-settings -k computername -v "${4}"
/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl set-settings -k internet_authkey -v "$5"

I modified the parameter labels of var4 and var5 to ‘Client Name’ and ‘Internet Authkey’ in the script options to make it easier to remember.

I built out a policy to include the .pkg installer and the script, Vars 4 and 5 need to be defined.

My deployment process is to Add a New Client on the server. I then add that client to the group I created for mac laptops. Failure to do so causes the laptop to try to find a C:\ drive and causes headaches. I copy over the name and authkey into the Jamf policy into Vars 4 and 5. I then scope the policy to 1 laptop at a time.

I can push to more than 1 laptop at a time by just cloning the policy, making the changes necessary and pushing to the next on the list. It’s a little annoying on the initial deployment, but only really needs to be done once.

The only real ‘issue’ and it’s not an issue just an annoyance is that there’s a popup for UrBackup Client wanting a password input so it can be used as a login item. If you cancel, it will add it anyway so the input can safely be ignored.

I built out a second policy with a simple script:

#!/bin/bash 
/Applications/UrBackup\ Client.app/Contents/MacOS/bin/urbackupclientctl start -i

I can push this if I want to manually start a client to backup.

So far so good on the handful of remote users I’ve been testing with. We’re planning to expand the storage pool for the Server in the next couple weeks and deploy to about 100 remote mac users.

Thanks for the feedback @cstuberg - that’s most useful. I hope your deployment goes well!

Please remember that this project is not yet suitable for backing up/restoring complex filesystem objects, such as the system itself. User data should be generally fine with it though - a little more information here: Symlinks Not Working on macOS

Hi @Talkabout

Thanks for your patience on this. I suspect this issue might need to be handed over to Those Who Are Cleverer Than Myself soon, but here’s something to move it along a bit:

Here’s a debug installer of the current 2.4.x branch for you; uninstall your previous version, then install this instead. This version hasn’t been signed, so you might need to jump through some hoops to get the OS to run the installer.

https://drive.google.com/file/d/1Z57m4ENEnyy-E1r_B5BSMKLPConw0pAk/view?usp=sharing

Once the installation has completed, then stop the running backend process with

sudo launchctl unload /Library/LaunchDaemons/org.urbackup.client.plist 

Then launch the backend into the debugger:

sudo lldb /Applications/UrBackup\ Client.app/Contents/MacOS/sbin/urbackupclientbackend

It will load up, then use run to launch it.
Then change some settings as you would normally. Hopefully you’ll then see the crash happen in the debugger - so use thread backtrace to get the debug info, and post it here.

Thanks!

Thanks @Moisie, I will try your suggestions in the next days and will report about the result.

Hi @Moisie,

I have run the installer twice, but after approving it from security side (in settings) the last step fails and the installer tells me that something goes wrong. Any way to overcome that?

Thanks!

Hi @Talkabout

My apologies - I’ve reproduced the error here (it doesn’t fail on my macOS 10.12 build system, but does fail on a 10.14 system…), so will fix it ASAP!

Hi @Talkabout

Thanks for your patience. Hopefully here’s a debug build that won’t crash on installation for you:

https://drive.google.com/file/d/1JsbkUGQQv8CI4w6WdTm08mMHXl16M72R/view?usp=sharing

Follow the instructions here - MacOS client 2021 - #60 by Moisie - and please report back!

Thanks.

Hi @Moisie,
Building a copy with your DataVaults development branch fixes my main problem. However, now I’m getting:

Error while listing files in folder “/Library/Application Support/com.apple.TCC”. User may not have permissions to access this folder. Errno is 1

I’ve tried giving Full Disk Access to every component I can think of, from the app package to every binary inside, but it still doesn’t work.

Hi @ravenclaw900,

Thanks for trying the build - glad it fixed your main issue.

Can you browse into /Library/Application Support/com.apple.TCC in the Finder? I’ve checked on a 10.14 and 10.15 system, and I can’t see any issues with doing so here, and no permissions that I can see which would prevent it from working with the Urbackup client.

I can only get into it if I have a root terminal with Full Disk Access. Permissions:

% ls -l /Library/Application\ Support | grep 'TCC' 
drwx------   3 root          admin           96 May 30 13:49 com.apple.TCC

Thanks @ravenclaw900

Which OS version are you on? From my main machine running macOS Big Sur 11.4, I get this:

MBP:~ user$ ls -l /Library/Application\ Support | grep 'TCC'
drwxr-xr-x@   4 root      wheel     128 30 May 06:58 com.apple.TCC

I’m not aware of having done anything special to open up the permissions - and a reasonably-clean 10.14 VM I use shows the same permissions too. I haven’t got SIP disabled either, FWIW.

I’m using Mojave 10.14, but I’ve been using this same (upgraded) copy of the OS since Mavericks or Yosemite.

Hi @Moisie ,

I found time now to test the package you provided. After installing Developer Command Line Tools and following your steps I can see the following after starting urbackup with debugger:

admin@macbook-pro CoreServices % sudo lldb /Applications/UrBackup\     Client.app/Contents/MacOS/sbin/urbackupclientbackend
Password:
(lldb) target create "/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend"
Current executable set to '/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend' (x86_64).
(lldb) run
Process 54893 launched: '/Applications/UrBackup Client.app/Contents/MacOS/sbin/urbackupclientbackend' (x86_64)
2021-05-31 00:41:12: SQLite: recovered 24 frames from WAL file /Library/Application Support/UrBackup Client/var/urbackup/backup_client.db-wal code: 283
2021-05-31 00:41:12: urbackupserver: Server started up successfully!
2021-05-31 00:41:12: ERROR: Error joining ipv6 multicast group ff12::f894:d:dd00:ef91
Process 54893 stopped
* thread #7, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001004dd002 urbackupclientbackend`ClientConnector::replaceSettings(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 930
urbackupclientbackend`ClientConnector::replaceSettings:
->  0x1004dd002 <+930>: movq   (%rax), %rcx
    0x1004dd005 <+933>: movq   0x28(%rcx), %rcx
    0x1004dd009 <+937>: leaq   -0x1298(%rbp), %rdi
    0x1004dd010 <+944>: movq   %rax, %rsi
Target 0: (urbackupclientbackend) stopped.

Does that help?

Thanks!

Thanks @Talkabout

Here’s another build, this time peppered with logging messages throughout the ClientConnector::replaceSettings function. Please try with this version and do the same thing, and post the outcome here again - this will help narrow down exactly where the failure is happening.

https://drive.google.com/file/d/1K_w1q2liVc7Wcwtjx9EBV5stVA158-ap/view?usp=sharing

Hi @Moisie ,

done what you said, here is the output

2021-06-07 17:09:34: DBG replaceSettings 1
2021-06-07 17:09:34: DBG replaceSettings 2
2021-06-07 17:09:34: DBG replaceSettings 3
Process 73856 stopped
* thread #7, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001004dd29d urbackupclientbackend`ClientConnector::replaceSettings(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 1741
urbackupclientbackend`ClientConnector::replaceSettings:
->  0x1004dd29d <+1741>: movq   (%rax), %rcx
    0x1004dd2a0 <+1744>: movq   0x28(%rcx), %rcx
    0x1004dd2a4 <+1748>: leaq   -0x18a0(%rbp), %rdi
    0x1004dd2ab <+1755>: movq   %rax, %rsi
Target 0: (urbackupclientbackend) stopped.

Thanks!

Bye

Thanks @Talkabout - I think I’m going to have to hand this over to someone who knows what they’re talking about better than I now…

It looks like it’s failing on line 1956 of urbackupclient/ClientService.cpp:

if(!ncname.empty() && ncname!=IndexThread::getFileSrv()->getServerName())

…but I couldn’t tell you why this should be the case on your system alone!

It could be a race which becomes apparent because starting the file server takes long on this client (because getting the computer name on macOS).

Best fix would perhaps be to start the filesrv+index thread before accepting command (like replace settings), i.e. moving down this line:

@Moisie Could you move it down, check if it works then build a package to see if that fixes it?