Hello,
some of the problems, that are mentioned here, went away, when I changed the file
permissions of the /Library/Application Support/Urbackup Client/var/urbackup.
I allowed the wheel group full access to this directory and all files within this directory.
I did this with the finder program.
I also did this multiple times, because some files were created later on in this directory.
After changing file permissions, I also was able to use the gui to add a backup path.
I also had problems adding a client on the same LAN.
This was due to multiple network cards and multiple network IP Adresses.
The multicast or the multicast answer was sent to the wrong network addresse.
When I disabled the second network card, the communication between client and server for the initial setup went through.
I also disabled SLAAC for IPv6 on the server and only used fixed IPv6 addresses.
For what it’s worth, I’m using it on macOS Sequoia 15.1 (Intel) at present to backup my home folder. My Urbackup Client was already installed on macOS Sonoma before I upgraded to Sequoia, so I’m currently unaware if there are any installation-specific issues.
Thanks for the confirmation. Although I’m on a M1, I have more hope now to get it setup.
I’m working remote via VPN and I am not sure if this is causing extra issues. (The Mac im working on is connected via VPN to the home network where Urbackup is installed). V2.4.x seems to behave different to V2.5.x, where 2.4 would connect but fail the backup due to authentication issues and 2.5 doesn’t connect at all.
I’m running Urbackup Client 2.4.12, and I’m happily connecting to the server on either the local network, or via the Internet-exposed server connection.
It would be worth you setting up whilst you’re connected to the same network as the server, to minimise complications.
I think I will experiment a bit more when I am back in the local network (physically). After trying 2.5.x I witnessed only strange behaviour. Also when I went back to 2.4.12.
Hello @vanillyneko
Yes - the client is running fine for me on an M4 MacBook Pro, currently running macOS 15.3.2. My client installation was migrated from older macOS versions running on Intel, but I’m unaware of any particular issues with installing it afresh on a modern machine - please let us know if you come across any problems.
Hi everyone, just reporting in as I recently installed the urbackup BETA branch for my M1 Max based MacBook (Tahoe 26.2). I’ve been using it for my Windows and Linux-based machines for a couple of years now and urbackup has already saved my bacon multiple times before, so very glad to see this software also works on Mac!
The client works well for file backups! I just had an issue with the “CloudStorage” folder in “Library”; specifically, in Onedrive there is a hidden Folder called .Trash which I as a user do not seem to have access to. I was not able to just ignore the Folder completely.
I’m already ignoring all hidden files and folders for the Mac (.*;*/.*/*) and I tried adding the full path and */.Trash/*, but urbackup still tried to read that folder. Any idea how I could include onedrive put completely ignore this specific folder (otherwise it will read and create the folder, but just ignore the files.
P.S.: If there is anything specific I should test on the Mac, please let me know. I am also willing to test any kind of image backup or time machine snapshotting function.
Thanks for reporting this - glad to hear it. I’m still running the 2.4 client on my M4 MacBook Pro under macOS Tahoe 26.2, and it’s running fine for me.
I personally have the entire CloudStorage folder ignored on my system, so I haven’t come across this issue - but I would have thought that adding the path */.Trash to the exclusions should make it entirely ignore that folder, and not just the contents.
I don’t believe there’s any support for image backups or Time Machine-style snapshots as yet - file backups only I’m afraid.
Thx for the tip. I tried it again and indeed, it might be working as intended, but now it hangs with another (not yet downloaded file). It might be, that is it is not able to handle the “online” files like on Windows, where it skips over them with a warning:
Error while listing files in folder “/Users/clang88/Library/CloudStorage/OneDrive-Personal/App/Zotero/storage/DMFT5AXY”. User may not have permissions to access this folder. Errno is 11
So for now, the only option is to fully ignore Onedrive or perhaps download everything/exclude the files that are online only.
As for the snapshots/image backups: I meant I would be available for testing such features, if they are being developed. Unfortunately my coding skills in C/C++ are nowhere near a level where I could contribute in any other sensible way to this project ;(
I can play around with my MacOS VM and test this. I’ve checked some ways to create snapshots using the same scripting logic you shared. It (apple snapshot cli tooling) seems to be a bit of mess, and I’m not quite sure yet, what the best approach for creating snapshots via terminal is.
I’ve found three built-in command-line tools that seem to fit the description:
diskutil
tmutil
fs_snapshot_create
diskutil does not seem to have the function to create snapshots anymore in Macos Tahoe 26.2 fs_snapshot_createunfortunately is missing from my VM… Not sure why (probably some Apple shenaningans; but if regular users don’t have that, that would be bad) → It is available on my host MacOS; so if I should test that let me know (the manpage is quite good) tmutil seems to be the most promising way forward (TimeMachine utility) to create snapshots, at least with that I got a script working that created snapshots on my MV that I could then also browse in the UI.
(Sorry for the screenshot, VM clipboard is not working atm)
Unfortunately I couldn’t mount them in the terminal yet… But I’m unsure if mount_apfs -s is even the right command, would need to do some more digging:
Virtual-Machine:\~ root# mount_apfs -s com.apple.TimeMachine.2026-01-01-225040.local / /private/tmp/snappy
mount_apfs: volume could not be mounted: Resource busy
What exactly would we need to get working for this to be useful for urbackup? Also, are the SNAP_ID, SNAP_MOUNTPOINT, SNAP_NAME, SNAP_ORIG_PATH crucial for any downstream dependencies? For now I am passing them, but really the only thing that is used and supported by tmutil is the Volume Path (i.e. right now I am passing “/”)
Edit: I just added a Secondary VHD as “Secondary Volume” and snapshotting that works fine as well with tmutil:
tmutil localsnapshot "/Volumes/Secondary HD" NOTE: local snapshots are considered purgeable and may be removed at any time by deleted (8).
Created local snapshot with date: 2026-01-02-133813
Nice, I think I figured it out: To mount APFS snapshots of the main Drive (by default called “Data” under “Macintosh HD”), you have to mount the snapshot of /System/Volumes/Data :
% cd /private/tmp/Snapshot
% ls
Applications System cores opt usr
Library Users home private
MobileSoftwareUpdate Volumes mnt sw
Seems promising enough! Let me know if I should write up the necessary bash scripts and contribute them for testing.
One note though: It seems like all drives are being snapshot everytime I run tmutil localsnapshot ${MOUNT_POINT} or tmutil snapshot ${MOUNT_POINT}…
Not quite sure what the logic here is. I assumed that if I passed the mount point it would only snapshot the Volume I passed, but it Snapshot both the Data Volume as well as the “Secondary HD” Volume…
And one more edit (sorry, documenting it here in the forums; let me know if this is undesired): This seems to be by design… Fromt he tmutil manpage
localsnapshot
Create new local Time Machine snapshots of all APFS volumes
included in the Time Machine backup.
listlocalsnapshots mount_point
List local Time Machine snapshots of the specified volume.
listlocalsnapshotdates [mount_point]
List the creation dates of all local Time Machine snapshots.
Specify mount_point to list snapshot creation dates from a
specific volume.
Listed dates are formatted YYYY-MM-DD-HHMMSS.
deletelocalsnapshots {mount_point | date}
If a date is specified, delete all local Time Machine snapshots
on all mounted disks for the specified date (formatted YYYY-MM-
DD-HHMMSS). If a disk is specified, delete all local Time
Machine snapshots on the specified disk
thinlocalsnapshots mount_point [purge_amount] [urgency]
Thin local Time Machine snapshots for the specified volume.
When purge_amount and urgency are specified, tmutil will attempt
(with urgency level 1-4) to reclaim purge_amount in bytes by
thinning snapshots.
If urgency is not specified, the default urgency will be used.
So in essence, just calling tmutil snapshot or tmutil localsnapshot snapshots everything snapshotable and if we want to make it per Volume, we would need to delete the snapshot with the same name made on all the other Volumes… Now I guess one more open question is how does this act if I actually have Time Machine configured.
Edit: When having “Time Machine” setup, the Volumes it snapshots are the ones included in the Time Machine setup. So if I user were to exclude “Secondary HD” that one no longer gets snapshot with tmutil…
That makes tmutil suboptimal after all… Either the users of urbackup “uncofingure” Time Machine or live with the limitation that only non-excluded Volumes will be snapshot-compatible.
Do you have a suggestion or preferred way forward? I can try and test by building from source on the VM with the tmutil approach.
I think tmutil should be fine for file backups, as they usually complete in a few minutes, so it is unlikely the snapshot is deleted. Probably the snapshot will also not be deleted while it is mounted (can’t confirm) but after some consideration tmutil seems to be the way of least resistance.
Thanks for looking into the snapshot APIs - I was unaware of the snapUtil project until this.
Speaking from my own perspective (as a minor contributor to the project) rather than as the project owner: I’m sadly not hopeful this is going to be a fruitful avenue to chase, much though I wish that it were.
I suspect Apple are extremely unlikely to grant the necessary entitlement for Urbackup to create (and remove) snapshots - it took a long time before they even granted the entitlement to long-established commercial utilities - and I feel the tmutil snapshot approach is too caveat-encumbered to be of use without creating a high tech support load.
I agree that this does all some a bit too janky for a stable backup solution like urbackup. It’s a shame Apple is so stuck up about their ecosystem. I am quite happy with how the file backups work, so not too big of a loss for me.
Still, if the project decides to add a “at your own risk” feature based on tmutil or manages to use the snapshot API afterall I’d be happy to test and help with the implementation to the best of my ability.
