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 backup
2020-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 valid
2020-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 valid
2020-11-12 20:00:48.171698-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Creating an encrypted sparsebundle using Case-sensitive APFS filesystem
2020-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 denied
2020-11-12 20:00:50.719711-0800  localhost backupd[228]: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/System/Volumes/Data' is still valid
2020-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 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:
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.

I have the following in smb.conf under share definitions. My share is ext 4 and this works for me
[Tmachine]
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.