Big Sur + SMB based Time Machine

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) [com.apple.TimeMachine:General] Starting manual backup2020-11-12 20:00:43.566026-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Attempting to mount 'smb://dan@MCP._smb._tcp.local./TARDIS'2020-11-12 20:00:48.015281-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] 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) [com.apple.TimeMachine:General] 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) [com.apple.TimeMachine:General] 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) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS' is still valid2020-11-12 20:00:48.165262-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/MCP._smb._tcp.local./10C38CAC-5552-4854-A5FB-DB4D083970B1/TARDIS' is still valid2020-11-12 20:00:48.171698-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Creating an encrypted sparsebundle using Case-sensitive APFS filesystem2020-11-12 20:00:48.356751-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] 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 denied2020-11-12 20:00:50.719711-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/System/Volumes/Data' is still valid2020-11-12 20:00:50.720493-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] 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/192.168.178.100/94D6582A-7961-4FAA-B632-36DB66B8BBB7/TimePi/03DC30BC-45A6-56F7-8CA9-198EBFE83EC8.sparsebundle', results: {}, error: 13 Permission deniederror	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 bashfruit:nfs_aces = noinherit permissions = yes

I got it from here:
https://stackoverflow.com/questions/58496277/samba-4-10-server-config-using-module-vfs-fruit-changes-file-creation-mask-fo

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 [global]  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 acl_xattr

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.

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

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 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.