Big Sur + SMB based Time Machine

Has anyone tested SMB based time machine backups in any of the various revisions of Big Sur?

Direct change from Catalina to BS result in permissions issues generated by time machine. If you force the folders to inherit permissions, time machine will complain about missing features.

Either way, time machine is completely non-functional. I've reported feedback and seen that others have the same issue, but no one I know has worked around it yet.

Samba 4.11.6 from ubuntu 20.04

standard options in smb.conf like fruit:aapl = yes and fruit:timemachine = yes, as well as the proper vfs etc. It is configured properly, worked great in Catalina and all previous revisions.
Post not yet marked as solved Up vote post of scotk Down vote post of scotk


I have the same issue

I am using FreeBSD 12.2, and Samba 4.13.1 on ZFS. I get the following logs:
Code Block
2020-11-12 20:00:42.825043-0800 localhost backupd[228]: (TimeMachine) [] Starting manual backup
2020-11-12 20:00:43.566026-0800 localhost backupd[228]: (TimeMachine) [] Attempting to mount 'smb://dan@MCP._smb._tcp.local./TARDIS'
2020-11-12 20:00:48.015281-0800 localhost backupd[228]: (TimeMachine) [] Mounted 'smb://dan@MCP._smb._tcp.local./TARDIS' at '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS'
2020-11-12 20:00:48.019341-0800 localhost backupd[228]: (TimeMachine) [] Initial network volume parameters for 'TARDIS' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 60, QoS: 0x0, attributes: 0x1C}
2020-11-12 20:00:48.107521-0800 localhost backupd[228]: (TimeMachine) [] Configured network volume parameters for 'TARDIS' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 30, QoS: 0x20, attributes: 0x1C}
2020-11-12 20:00:48.114865-0800 localhost backupd[228]: (TimeMachine) [] Mountpoint '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS' is still valid
2020-11-12 20:00:48.165262-0800 localhost backupd[228]: (TimeMachine) [] Mountpoint '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS' is still valid
2020-11-12 20:00:48.171698-0800 localhost backupd[228]: (TimeMachine) [] Creating an encrypted sparsebundle using Case-sensitive APFS filesystem
2020-11-12 20:00:48.356751-0800 localhost backupd[228]: (TimeMachine) [] Failed to create '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS/F03E9C12-E5FB-5132-A445-66BCEB0A6541.sparsebundle', results: {
}, error: 13 Permission denied
2020-11-12 20:00:50.719711-0800 localhost backupd[228]: (TimeMachine) [] Mountpoint '/System/Volumes/Data' is still valid
2020-11-12 20:00:50.720493-0800 localhost backupd[228]: (TimeMachine) [] Backup failed (20: BACKUP_FAILED_DISK_IMAGE_NOT_CREATED)

On the Samba share the following is created:
Code Block
drw------- 2 dan dan 2B Nov 12 20:00 F03E9C12-E5FB-5132-A445-66BCEB0A6541.sparsebundle/

This setup worked on Catalina

Same thing here. Had a setup with a Raspberry Pi 4, running Ubuntu 20.10, Samba Version 4.12.5-Ubuntu. Had no problem at all with Catalina, ran smoothly. After upgrading to Big Sur I get

Code Block
error 16:01:47.230967+0100 backupd Failed to create '/Volumes/.timemachine/', results: {
}, error: 13 Permission denied
error 16:01:48.419816+0100 backupd Backup failed (20: BACKUP_FAILED_DISK_IMAGE_NOT_CREATED)

A sparse bundle is created on the samba share

Code Block
drw-------+ 1 share share 0 Nov 13 15:01 03DC30BC-45A6-56F7-8CA9-198EBFE83EC8.sparsebundle

Not sure what's wrong in the setup or where to fix stuff. No difference if I use the ip directly (as stated above) or with avahi etc.

! got it to work, though I am not sure my solution will work for those not using zfs

I had my vsf objects in the correct order

I replaced vfs objects = catia fruit streams_xattr zfsacl

with vfs objects = zfsacl catia fruit streams_xattr

I had the same problem, also Ubuntu 20.04 and Samba 4.11.6
My backup machine is on btrfs and not on zfs, but ScruffyDans solution put me on the right track I think (still testing).

I modified my smb.conf to include as global options:
Code Block bash
fruit:nfs_aces = no
inherit permissions = yes

I got it from here:

Changing these settings allowed my MacBook Pro with Big Sur to connect to a network share, create a new .sparsebundle and it is now backing up to it. I can also confirm that the container created in the .sparsebundle is an APFS container!

Before changing these settings it would just throw the error as described in the OP.

I'm not sure why this seems to solve the problem....anyone?

Same thing here on a ZFS pool. I can select the SMB-Time-Machine-share and input the login data. A sparsebundle is created but then the back up fails. I am not using the vfs object "zfsacl". When I do, the login process doesn't even work anymore.
I had the same problem. In my case I'm not using zfs so I added acl_xattr to my smb.conf and it works.
Code Block
vfs objects = acl_xattr catia fruit streams_xattr

I don't have much knowledge about acl and so on, but I guess some acl information is necessary for Big Sur's timemachine to work. Anyway thank you so much for your information, ScruffyDan. 
Just FYI: Using
Code Block

in the global as well as share specific setting has worked for me on my Linux server with a ZFS file system. Thanks, dcato!

Thank you all! Great discussion and apple needs to read this. They definitely changed something.

For 20.04 with zfs, and stock samba, the proper answer appears to be:

vfs objects = aclxattr catia fruit streamsxattr
fruit:nfs_aces = no
inherit permissions = yes

My concern about the above though, inherit permissions, does this mean apple can no longer control the permissions in the directory? I worry this will be an issue, the change something, it doesn't match, so apple just thinks the file system is corrupt and time machine goes haywire.

Also, I put it in zfsacl but that did not work for me. I am sharing a folder from a zfs mounted file system, not a zfs mount itself. There might be something with the configuration of that vfs item required to make it work.
I have the following in smb.conf under share definitions. My share is ext 4 and this works for me
comment = time machine share
path = /mnt/share/backups/TimeMachine
valid users = glen
read only = no
vfs objects = catia fruit streams_xattr
fruit:time machine = yes
Code Block
Adding  'acl_xattr' to 'vfs objects' worked for me. I got same issue that the sparse bundle was created but then immediately failed. This seems to fix the permission issue somehow. Working now.

(On ZFS share by the way, Ubuntu 20.04)
For anyone still having problems where Finder freezes/hangs on copies and/or 0 byte files are created I tracked this down to a Samba bug (Bug 14420). Try setting the following in your smb.conf. I've had no issues since.
Code Block
fruit:zero_file_id = yes

Can somebody having it working post complete example configuration file?
I am having OMV 5 on Raspberry Pi 4, using EXT4 filesystem and trying to enable Time Machine from Big Sur.
I have tried suggestions used so far, yet it creates spase bundle, then deletes it and then I get error.
Thank you!
I had the same problem. If you are using Sophos on Big Sur, it prevents Time machine backup on NAS. Sophos still has issues on Big Sur. Try uninstall Sophos and reboot.
I have Sophos 9.10.1 which is preview of Big Sur compatible release.
Yet, I disabled on access scan and added exception for omv5.
Should I really remove Sophos?
I used Sophos 10.0.1a1, Ubuntu 20.04 and Samba 4.11.6 with ext4 drive, and I had error 112. I tried to disable scan etc first, but no luck. So I had to uninstall it. Safe boot may work.