Re: FreeBSD+samba as a time machine server for OSX/Sonoma?
- In reply to: David Chisnall : "Re: FreeBSD+samba as a time machine server for OSX/Sonoma?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 08 Sep 2024 12:29:04 UTC
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
> On 8 Sep 2024, at 14:10, David Chisnall <theraven@FreeBSD.org> wrote:
>
> 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
>
>> On 8 Sep 2024, at 12:48, David Chisnall <theraven@FreeBSD.org> wrote:
>>
>> 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
>>
>>> On 7 Sep 2024, at 08:28, David Chisnall <theraven@FreeBSD.org> wrote:
>>>
>>> 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
>>>
>>>> On 6 Sep 2024, at 22:48, Craig Leres <leres@freebsd.org> wrote:
>>>>
>>>> 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
>>>>
>>
>