FreeBSD+samba as a time machine server for OSX/Sonoma?

[Craig Leres]

Last year you guys helped me get this to work with samba416. I recently
tried to upgrade to samba419 and so far I'm unsuccessful. The error is
"The backup disk image could not be created" and I'm running 14.1.

I'm using the same port build options with 4.16 and 4.19:

FAM
PYTHON3
QUOTAS
SYSLOG
UTMP
GSSAPI_BUILTIN
AVAHI
FRUIT

Having learned my lesson when I upgraded from 4.13 to 4.16, I removed
the old backups from the zfs volume on the server before starting. I've
also learned the rule that you need to delete and reattach the share on
the mac side when you change the samba config.

Appended is the config that works with 4.16 (but not 4.19)

Craig

[global]
workgroup = XYZ
security = user
netbios name = red
server string = red.example.net
hostname lookups = no
server role = standalone server

interfaces = ixl0 lo0
bind interfaces only = yes

load printers = no
show add printer wizard = no
time server = yes
use mmap = yes

dos charset = 850
unix charset = UTF-8
mangled names = no

#log level = 3
#log file = /tmp/samba.log
vfs objects = catia fruit streams_xattr zfsacl

fruit:model = MacSamba
fruit:resource = file
fruit:metadata = netatalk
fruit:nfs_aces = yes
fruit:copyfile = no
fruit:aapl = yes
fruit:zero_file_id = yes

inherit permissions = yes


[Time Machine]
path = /backups/mini
read only = no
guest ok = no
writeable = yes
browseable = yes
fruit:resource = file
fruit:time machine = yes
valid users = backup-mini
max disk size 512G

hosts allow = 10.0.0.19


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

I believe this was broken by a macOS update around February. I’ve been trying to debug for a while. I’ve opened an Apple issue (FB14500950, for any Apple folks) but it shows up as few people reporting it. I posted on Mastodon and several people reported that Time Machine is broken and recommended Carbon Copy Cloner as an alternative. I would like to see it fixed, but it probably needs some more debugging by Apple folks.

It stopped working for me with no changes on the server and I can reproduce the failures on two different Macs.

Things I have tried:

- Upgrading Samba from 4.16 to 4.19
- Upgrading FreeBSD from 13.x to 14.1
- Setting the SMB timeout sysctls to larger values on macOS.
- Turning up the SMB debug sysctls on macOS to see if there’s more info
- Turning up the Samba logging level.
- Verifying the backups
- Watching smbinfo the server.
- Updating macOS to the latest version
- Connecting to the server with Finder and checking I can access files on the shares and that they have the right permissions.

Samba doesn’t report any errors (I don’t know if there’s a way to force Samba to report permission-denied things).

It appears that the Mac acquires a load of read-only locks and so does a lot of reads, but for some reason it appears to fail the first write. Even with a verify, it looks like it completes the verification bit but then fails to write to the plist file.

With the increased debugging, I see this in the macOS Comsole:

default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDescriptor:error:]: File system is smbfs
default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80

So it looks as if it is a permission issue. Maybe the mcOS SMB client has started using some bit of the protocol that Samba on FreeBSD doesn’t support for ACLs?

David

Last year you guys helped me get this to work with samba416. I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is "The backup disk image could not be created" and I'm running 14.1.
FAM
PYTHON3
QUOTAS
SYSLOG
UTMP
GSSAPI_BUILTIN
AVAHI
FRUIT
Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on the server before starting. I've also learned the rule that you need to delete and reattach the share on the mac side when you change the samba config.
Appended is the config that works with 4.16 (but not 4.19)
Craig
[global]
workgroup = XYZ
security = user
netbios name = red
server string = red.example.net
hostname lookups = no
server role = standalone server
interfaces = ixl0 lo0
bind interfaces only = yes
load printers = no
show add printer wizard = no
time server = yes
use mmap = yes
dos charset = 850
unix charset = UTF-8
mangled names = no
#log level = 3
#log file = /tmp/samba.log
vfs objects = catia fruit streams_xattr zfsacl
fruit:model = MacSamba
fruit:resource = file
fruit:metadata = netatalk
fruit:nfs_aces = yes
fruit:copyfile = no
fruit:aapl = yes
fruit:zero_file_id = yes
inherit permissions = yes
[Time Machine]
path = /backups/mini
read only = no
guest ok = no
writeable = yes
browseable = yes
fruit:resource = file
fruit:time machine = yes
valid users = backup-mini
max disk size 512G
hosts allow = 10.0.0.19

[Mark Delany]

Post by David Chisnall
I believe this was broken by a macOS update around February.

I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is
"The backup disk image could not be created" and I'm running 14.1.

I'm going to ask a silly question here. But why are people running samba instead of
netatalk if they are only using the timemachine backup capability?

I often had difficulting with Samba and timemachine and then I stumbled across an article
on how to use netatalk - sorry, link is lost now, but I can provide configs - and I've
never looked back. Timemachine backups and restores work flawlessly and have done so
across a number of previous macOS versions.

I have nothing against Samba, but it's kinda the swiss-army knife of network file systems
with plenty of complexity, whereas netatalk seems much more specific and simpler. What am
I missing?


Mark.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

Post by Mark Delany
I'm going to ask a silly question here. But why are people running samba instead of
netatalk if they are only using the timemachine backup capability?

Does AFP still work with newer versions of macOS? I thought they removed support for it with APFS.

David



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Delany]

Post by David Chisnall

Post by Mark Delany
I'm going to ask a silly question here. But why are people running samba instead of
netatalk if they are only using the timemachine backup capability?

Does AFP still work with newer versions of macOS?

I'm doing timemachine backups from Sonoma 14.6.1 to afp.

It would be a pity if they did remove that support.

FWIW. My rc.conf

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
avahi_daemon_enable="YES"
netatalk_enable="YES" # conf=/usr/local/etc/afp.conf
dbus_enable="YES"
and afp.conf

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[Global]
afp listen = 10.1.0.4 fd2d:e363:95de:fe:10:1:0:4
hostname = HomeServer
guest account = nobody

[dog]
path = /backups/timemachine/dog
time machine = yes
vol size limit = 1000000
valid users = dogafp

[cat]
path = /backups/timemachine/cat
time machine = yes
vol size limit = 1000000
valid users = catafp
With dogafp and catafp set in /etc/passwd


Mark.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stefan Esser]

Post by David Chisnall

Post by Mark Delany
I'm going to ask a silly question here. But why are people running samba instead of
netatalk if they are only using the timemachine backup capability?

Does AFP still work with newer versions of macOS? I thought they removed support for it with APFS.

I have both Samba and NetATalk installed and running on my home-server.

Timemachine baclkups are working well using samba-3.16, but fail with
samba-3.19 (corrupting the backup!).

I have used netatalk for timemachine backups, do not remember why I
went back to using samba. Maybe I should try using netatalk again,
since then I could update samba to 3.19 for other file systems.

BTW: vscode on the MacBook does not work well on directories
exported using netatalk. Every "file safe" operation warns that the
target file had been modified and asks for confirmation to overwrite
it.

I have not tried to diagnose this issue, since it works well when
using samba to access these directories.

Best regards, STefan


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mark Delany]

Post by Stefan Esser

Post by David Chisnall
Does AFP still work with newer versions of macOS? I thought they removed support for it with APFS.

I have both Samba and NetATalk installed and running on my home-server.
BTW: vscode on the MacBook does not work well on directories
exported using netatalk. Every "file safe" operation warns that the
target file had been modified and asks for confirmation to overwrite
it.

Indeed. Just so it's clear, I was only addressing the question on the subject line. That
of providing just a TM service.

As Stefan points out, Samba is likely to be a better choice if additional file system
services are required.

One presumes that if TM doesn't work with current Samba it should be possible to run both
Samba and netatalk together, but I have not tried this.


Mark.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

Post by Stefan Esser
I have used netatalk for timemachine backups, do not remember why I
went back to using samba. Maybe I should try using netatalk again,
since then I could update samba to 3.19 for other file systems.

This doc says that AFP was not supported for Time Machine after High Sierra / APFS:

https://support.apple.com/en-us/100765

If it’s not correct, I should probably go back to netatalk.

David

[Andrea Venturoli]

Post by Stefan Esser
Timemachine baclkups are working well using samba-3.16, but fail with
samba-3.19 (corrupting the backup!).

You mean 4.16 and 4.19, right?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andrea Venturoli]

Post by Mark Delany
I'm going to ask a silly question here. But why are people running samba instead of
netatalk if they are only using the timemachine backup capability?

A couple of possibilities:
_ they already have Samba and don't feel like installing something extra
when the former is supposed to work;
_ if I understand correctly AFPS is deprecated by Apple, which suggests
SMB instead.

bye
av.

P.S.
I don't use Samba directly for TM, although I have a customer taking TM
backups to a NAS, which almost surely runs Samba.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

A little bit more debugging, and a working hypothesis:

I have tried creating a new Time Machine share (empty directory) and pointing the Mac at it. On the first backup, it creates a `.com.apple.timemachine.supported-{uuid}` file and a `{uuid}-{date}.sparsebundle` directory. It appears to create a valid sparse bundle, but other posts suggest that it then renames this to `{computername}.backupbundle`. There is a Samba setting: `fruit:posix_rename` that is supposed to control this. It appears to fail at the point where it should do this rename.

If I mount the same share, I can reproduce this:

$ mkdir tmp
$ touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: Operation not supported

So it appears that something in the FreeBSD port of Samba has broken the ability to rename directories.

This appears to be recent breakage. Reverying to net/samba416 fixes this bit, at least, and I can now back up to a pristine share.

David

Post by David Chisnall
I believe this was broken by a macOS update around February. I’ve been trying to debug for a while. I’ve opened an Apple issue (FB14500950, for any Apple folks) but it shows up as few people reporting it. I posted on Mastodon and several people reported that Time Machine is broken and recommended Carbon Copy Cloner as an alternative. I would like to see it fixed, but it probably needs some more debugging by Apple folks.
It stopped working for me with no changes on the server and I can reproduce the failures on two different Macs.
- Upgrading Samba from 4.16 to 4.19
- Upgrading FreeBSD from 13.x to 14.1
- Setting the SMB timeout sysctls to larger values on macOS.
- Turning up the SMB debug sysctls on macOS to see if there’s more info
- Turning up the Samba logging level.
- Verifying the backups
- Watching smbinfo the server.
- Updating macOS to the latest version
- Connecting to the server with Finder and checking I can access files on the shares and that they have the right permissions.
Samba doesn’t report any errors (I don’t know if there’s a way to force Samba to report permission-denied things).
It appears that the Mac acquires a load of read-only locks and so does a lot of reads, but for some reason it appears to fail the first write. Even with a verify, it looks like it completes the verification bit but then fails to write to the plist file.
default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDescriptor:error:]: File system is smbfs
default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
So it looks as if it is a permission issue. Maybe the mcOS SMB client has started using some bit of the protocol that Samba on FreeBSD doesn’t support for ACLs?
David

Last year you guys helped me get this to work with samba416. I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is "The backup disk image could not be created" and I'm running 14.1.
FAM
PYTHON3
QUOTAS
SYSLOG
UTMP
GSSAPI_BUILTIN
AVAHI
FRUIT
Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on the server before starting. I've also learned the rule that you need to delete and reattach the share on the mac side when you change the samba config.
Appended is the config that works with 4.16 (but not 4.19)
Craig
[global]
workgroup = XYZ
security = user
netbios name = red
server string = red.example.net
hostname lookups = no
server role = standalone server
interfaces = ixl0 lo0
bind interfaces only = yes
load printers = no
show add printer wizard = no
time server = yes
use mmap = yes
dos charset = 850
unix charset = UTF-8
mangled names = no
#log level = 3
#log file = /tmp/samba.log
vfs objects = catia fruit streams_xattr zfsacl
fruit:model = MacSamba
fruit:resource = file
fruit:metadata = netatalk
fruit:nfs_aces = yes
fruit:copyfile = no
fruit:aapl = yes
fruit:zero_file_id = yes
inherit permissions = yes
[Time Machine]
path = /backups/mini
read only = no
guest ok = no
writeable = yes
browseable = yes
fruit:resource = file
fruit:time machine = yes
valid users = backup-mini
max disk size 512G
hosts allow = 10.0.0.19

[Craig Leres]

Post by David Chisnall
$ mkdir tmp
$ touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: Operation not supported
So it appears that something in the FreeBSD port of Samba has broken the
ability to rename directories.

Nice catch.

I installed 4.16 on a spare system and setup a test share. I'm able to
reproduce your "Operation not supported" test. But I also see that (from
the mac) I get the same error if I try to remove tmp/foo! I'll add some
info to your PR.

Post by David Chisnall
I'm going to ask a silly question here. But why are people running

samba instead of

Post by David Chisnall
netatalk if they are only using the timemachine backup capability?

In my case when I upgraded to big sur (2021) it looked like netatalk3 no
longer worked; my local osx expert thought that apple had phased out afp
support so I switched to samba413.

It wasn't until much later that I figured out when you make changes you
pretty much need to nuke your old backup and start over. And also delete
and recreate the share config on the mac. So maybe if I had just done
those things when I upgraded to big sur I would have continued to use
netatalk3.

But last year I got a brother multi-function printer and it was pretty
easy to create a samba share that the printer can store scans to. That's
been pretty handy so I'm likely to keep samba.

Post by David Chisnall
I have never needed to explicitly set fruit:posix_rename, my Time
Machine backups work completely fine without it (maybe it defaults to on
now?). I have been using Samba 4.19 since the port came out too.

Right, fruit:posix_rename defaults to "yes" (see man vfs_fruit).

Craig


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Chisnall]

I have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281360 to track this.

Reverting to samba416, I can back up in a new share, but I cannot back up to the share that had my existing backups in it. This may be a permissions issue or some problem withe metadata getting out of sync: moving the backupbundle from the old share to the new one does not fix it. Once I have a new complete backup, I will try comparing the metadata and seeing what the differences are.

So far, the main difference appears to be that the new backup creates a disk image bundle with 500 MiB bands whereas the old one was using 8 MiB bands. This change is presumably because APFS, unlike HFS+, supports holes in files, but I wonder if there’s a problem with Samba and very large directories? There were 47,486 bands in the old disk image.

David

Post by David Chisnall
I have tried creating a new Time Machine share (empty directory) and pointing the Mac at it. On the first backup, it creates a `.com.apple.timemachine.supported-{uuid}` file and a `{uuid}-{date}.sparsebundle` directory. It appears to create a valid sparse bundle, but other posts suggest that it then renames this to `{computername}.backupbundle`. There is a Samba setting: `fruit:posix_rename` that is supposed to control this. It appears to fail at the point where it should do this rename.
$ mkdir tmp
$ touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: Operation not supported
So it appears that something in the FreeBSD port of Samba has broken the ability to rename directories.
This appears to be recent breakage. Reverying to net/samba416 fixes this bit, at least, and I can now back up to a pristine share.
David

Post by David Chisnall
I believe this was broken by a macOS update around February. I’ve been trying to debug for a while. I’ve opened an Apple issue (FB14500950, for any Apple folks) but it shows up as few people reporting it. I posted on Mastodon and several people reported that Time Machine is broken and recommended Carbon Copy Cloner as an alternative. I would like to see it fixed, but it probably needs some more debugging by Apple folks.
It stopped working for me with no changes on the server and I can reproduce the failures on two different Macs.
- Upgrading Samba from 4.16 to 4.19
- Upgrading FreeBSD from 13.x to 14.1
- Setting the SMB timeout sysctls to larger values on macOS.
- Turning up the SMB debug sysctls on macOS to see if there’s more info
- Turning up the Samba logging level.
- Verifying the backups
- Watching smbinfo the server.
- Updating macOS to the latest version
- Connecting to the server with Finder and checking I can access files on the shares and that they have the right permissions.
Samba doesn’t report any errors (I don’t know if there’s a way to force Samba to report permission-denied things).
It appears that the Mac acquires a load of read-only locks and so does a lot of reads, but for some reason it appears to fail the first write. Even with a verify, it looks like it completes the verification bit but then fails to write to the plist file.
default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDescriptor:error:]: File system is smbfs
default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
So it looks as if it is a permission issue. Maybe the mcOS SMB client has started using some bit of the protocol that Samba on FreeBSD doesn’t support for ACLs?
David

Last year you guys helped me get this to work with samba416. I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is "The backup disk image could not be created" and I'm running 14.1.
FAM
PYTHON3
QUOTAS
SYSLOG
UTMP
GSSAPI_BUILTIN
AVAHI
FRUIT
Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on the server before starting. I've also learned the rule that you need to delete and reattach the share on the mac side when you change the samba config.
Appended is the config that works with 4.16 (but not 4.19)
Craig
[global]
workgroup = XYZ
security = user
netbios name = red
server string = red.example.net
hostname lookups = no
server role = standalone server
interfaces = ixl0 lo0
bind interfaces only = yes
load printers = no
show add printer wizard = no
time server = yes
use mmap = yes
dos charset = 850
unix charset = UTF-8
mangled names = no
#log level = 3
#log file = /tmp/samba.log
vfs objects = catia fruit streams_xattr zfsacl
fruit:model = MacSamba
fruit:resource = file
fruit:metadata = netatalk
fruit:nfs_aces = yes
fruit:copyfile = no
fruit:aapl = yes
fruit:zero_file_id = yes
inherit permissions = yes
[Time Machine]
path = /backups/mini
read only = no
guest ok = no
writeable = yes
browseable = yes
fruit:resource = file
fruit:time machine = yes
valid users = backup-mini
max disk size 512G
hosts allow = 10.0.0.19

[Dimitry Andric]

I have never needed to explicitly set fruit:posix_rename, my Time Machine backups work completely fine without it (maybe it defaults to on now?). I have been using Samba 4.19 since the port came out too.

The only problem I encountered was with samba416 and fruit:zero_file_id, which severely borked TM shares, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269883 for the gory details.

Since I don't have access to a Sonoma Mac on my network, I have used Windows instead to make a bunch of subdirectories in a Samba share with fruit:time machine enabled, but I can rename them at any level without issue.

-Dimitry

Post by David Chisnall
I have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281360 to track this.
Reverting to samba416, I can back up in a new share, but I cannot back up to the share that had my existing backups in it. This may be a permissions issue or some problem withe metadata getting out of sync: moving the backupbundle from the old share to the new one does not fix it. Once I have a new complete backup, I will try comparing the metadata and seeing what the differences are.
So far, the main difference appears to be that the new backup creates a disk image bundle with 500 MiB bands whereas the old one was using 8 MiB bands. This change is presumably because APFS, unlike HFS+, supports holes in files, but I wonder if there’s a problem with Samba and very large directories? There were 47,486 bands in the old disk image.
David

Post by David Chisnall
I have tried creating a new Time Machine share (empty directory) and pointing the Mac at it. On the first backup, it creates a `.com.apple.timemachine.supported-{uuid}` file and a `{uuid}-{date}.sparsebundle` directory. It appears to create a valid sparse bundle, but other posts suggest that it then renames this to `{computername}.backupbundle`. There is a Samba setting: `fruit:posix_rename` that is supposed to control this. It appears to fail at the point where it should do this rename.
$ mkdir tmp
$ touch tmp/foo
$ mv tmp fmp
mv: rename tmp to fmp: Operation not supported
So it appears that something in the FreeBSD port of Samba has broken the ability to rename directories.
This appears to be recent breakage. Reverying to net/samba416 fixes this bit, at least, and I can now back up to a pristine share.
David

Post by David Chisnall
I believe this was broken by a macOS update around February. I’ve been trying to debug for a while. I’ve opened an Apple issue (FB14500950, for any Apple folks) but it shows up as few people reporting it. I posted on Mastodon and several people reported that Time Machine is broken and recommended Carbon Copy Cloner as an alternative. I would like to see it fixed, but it probably needs some more debugging by Apple folks.
It stopped working for me with no changes on the server and I can reproduce the failures on two different Macs.
- Upgrading Samba from 4.16 to 4.19
- Upgrading FreeBSD from 13.x to 14.1
- Setting the SMB timeout sysctls to larger values on macOS.
- Turning up the SMB debug sysctls on macOS to see if there’s more info
- Turning up the Samba logging level.
- Verifying the backups
- Watching smbinfo the server.
- Updating macOS to the latest version
- Connecting to the server with Finder and checking I can access files on the shares and that they have the right permissions.
Samba doesn’t report any errors (I don’t know if there’s a way to force Samba to report permission-denied things).
It appears that the Mac acquires a load of read-only locks and so does a lot of reads, but for some reason it appears to fail the first write. Even with a verify, it looks like it completes the verification bit but then fails to write to the plist file.
default 14:12:26.297714+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.301301+0100 kernel smb2fs_smb_cmpd_create: smb2fs_smb_ntcreatex failed 13
default 14:12:26.310563+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_query_info (single request) failed 45
default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDescriptor:error:]: File system is smbfs
default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT action = 0x80 denied
default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not authorized to access TheRooT : action = 0x80
So it looks as if it is a permission issue. Maybe the mcOS SMB client has started using some bit of the protocol that Samba on FreeBSD doesn’t support for ACLs?
David

Last year you guys helped me get this to work with samba416. I recently tried to upgrade to samba419 and so far I'm unsuccessful. The error is "The backup disk image could not be created" and I'm running 14.1.
FAM
PYTHON3
QUOTAS
SYSLOG
UTMP
GSSAPI_BUILTIN
AVAHI
FRUIT
Having learned my lesson when I upgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on the server before starting. I've also learned the rule that you need to delete and reattach the share on the mac side when you change the samba config.
Appended is the config that works with 4.16 (but not 4.19)
Craig
[global]
workgroup = XYZ
security = user
netbios name = red
server string = red.example.net
hostname lookups = no
server role = standalone server
interfaces = ixl0 lo0
bind interfaces only = yes
load printers = no
show add printer wizard = no
time server = yes
use mmap = yes
dos charset = 850
unix charset = UTF-8
mangled names = no
#log level = 3
#log file = /tmp/samba.log
vfs objects = catia fruit streams_xattr zfsacl
fruit:model = MacSamba
fruit:resource = file
fruit:metadata = netatalk
fruit:nfs_aces = yes
fruit:copyfile = no
fruit:aapl = yes
fruit:zero_file_id = yes
inherit permissions = yes
[Time Machine]
path = /backups/mini
read only = no
guest ok = no
writeable = yes
browseable = yes
fruit:resource = file
fruit:time machine = yes
valid users = backup-mini
max disk size 512G
hosts allow = 10.0.0.19