From nobody Sun Sep 08 12:29:04 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X1q5h4l2Dz5TjXF for ; Sun, 08 Sep 2024 12:29:12 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1q5h23n9z53lX; Sun, 8 Sep 2024 12:29:12 +0000 (UTC) (envelope-from dimitry@andric.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (longrow.wg.andric.com [10.69.1.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 194194B57; Sun, 08 Sep 2024 14:29:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andric.com; s=201904; t=1725798545; bh=t/fCk8iw6MWS9A5LjMIZ+NK8ru8WOYVtyj+eF2gRVeA=; h=From:Message-Id:Subject:Date:In-Reply-To:Cc:To:References:From; b=Uwhs6E9dudO5gmgP8BOANOFXF33uzXOTEe9/K3lzNuhVPAlzV6NKieWwFB4g/3o0e KQw2kpl110c/wPuZMYYNPG7pDxcdhVghwsVGkQ/77TDnN9nymNz142+v+JVqlt5QEY q5B/fnpTDYFUBejPUR3jiu77Z59mG9ABfrz7PUoZt51H0VmKHHQChmM8bfFpifRMZU K8/NPZDnzAJEO5bgbrwGsBMSYmzITpC19pDXrv2q/FYsesW6tLE8IYnq4EHGQ8LF/m Nko+ph7BSkie12bPHPojryy/ElI4kz2oUS+F/Tiv36aFwtqd6hMSWSsE03w0KipT4j jG7M0wyPel4Yw== From: Dimitry Andric Message-Id: <63540459-7D2E-4B70-962D-957550D294A3@andric.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.2\)) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 14:29:04 +0200 In-Reply-To: <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> Cc: Craig Leres , FreeBSD Hackers To: David Chisnall References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> X-Mailer: Apple Mail (2.3731.700.6.1.2) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12859, ipnet:87.251.32.0/19, country:NL] X-Rspamd-Queue-Id: 4X1q5h23n9z53lX --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=3D269883 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 wrote: >=20 > I have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360= to track this. >=20 > 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. >=20 > 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=E2=80=99s a problem with = Samba and very large directories? There were 47,486 bands in the old = disk image. >=20 > David >=20 >> On 8 Sep 2024, at 12:48, David Chisnall wrote: >>=20 >> A little bit more debugging, and a working hypothesis: >>=20 >> 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. =20 >>=20 >> If I mount the same share, I can reproduce this: >>=20 >> $ mkdir tmp >> $ touch tmp/foo >> $ mv tmp fmp >> mv: rename tmp to fmp: Operation not supported >>=20 >> So it appears that something in the FreeBSD port of Samba has broken = the ability to rename directories. =20 >>=20 >> 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. >>=20 >> David >>=20 >>> On 7 Sep 2024, at 08:28, David Chisnall = wrote: >>>=20 >>> I believe this was broken by a macOS update around February. I=E2=80=99= ve been trying to debug for a while. I=E2=80=99ve 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.=20 >>>=20 >>> It stopped working for me with no changes on the server and I can = reproduce the failures on two different Macs. >>>=20 >>> Things I have tried: >>>=20 >>> - 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=E2=80=99s= 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. >>>=20 >>> Samba doesn=E2=80=99t report any errors (I don=E2=80=99t know if = there=E2=80=99s a way to force Samba to report permission-denied = things). >>>=20 >>> 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.=20 >>>=20 >>> With the increased debugging, I see this in the macOS Comsole: >>>=20 >>> 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 =3D 0x80 >>> default 14:12:26.542682+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543657+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543697+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>> default 14:12:26.543730+0100 kernel smbfs_vnop_access: = TheRooT action =3D 0x80 denied >>> default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 = not authorized to access TheRooT : action =3D 0x80 >>>=20 >>> 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=E2=80=99t support for ACLs? >>>=20 >>> David >>>=20 >>>> On 6 Sep 2024, at 22:48, Craig Leres wrote: >>>>=20 >>>> =EF=BB=BFLast 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. >>>>=20 >>>> I'm using the same port build options with 4.16 and 4.19: >>>>=20 >>>> FAM >>>> PYTHON3 >>>> QUOTAS >>>> SYSLOG >>>> UTMP >>>> GSSAPI_BUILTIN >>>> AVAHI >>>> FRUIT >>>>=20 >>>> 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. >>>>=20 >>>> Appended is the config that works with 4.16 (but not 4.19) >>>>=20 >>>> Craig >>>>=20 >>>> [global] >>>> workgroup =3D XYZ >>>> security =3D user >>>> netbios name =3D red >>>> server string =3D red.example.net >>>> hostname lookups =3D no >>>> server role =3D standalone server >>>>=20 >>>> interfaces =3D ixl0 lo0 >>>> bind interfaces only =3D yes >>>>=20 >>>> load printers =3D no >>>> show add printer wizard =3D no >>>> time server =3D yes >>>> use mmap =3D yes >>>>=20 >>>> dos charset =3D 850 >>>> unix charset =3D UTF-8 >>>> mangled names =3D no >>>>=20 >>>> #log level =3D 3 >>>> #log file =3D /tmp/samba.log >>>> vfs objects =3D catia fruit streams_xattr zfsacl >>>>=20 >>>> fruit:model =3D MacSamba >>>> fruit:resource =3D file >>>> fruit:metadata =3D netatalk >>>> fruit:nfs_aces =3D yes >>>> fruit:copyfile =3D no >>>> fruit:aapl =3D yes >>>> fruit:zero_file_id =3D yes >>>>=20 >>>> inherit permissions =3D yes >>>>=20 >>>>=20 >>>> [Time Machine] >>>> path =3D /backups/mini >>>> read only =3D no >>>> guest ok =3D no >>>> writeable =3D yes >>>> browseable =3D yes >>>> fruit:resource =3D file >>>> fruit:time machine =3D yes >>>> valid users =3D backup-mini >>>> max disk size 512G >>>>=20 >>>> hosts allow =3D 10.0.0.19 >>>>=20 >>=20 >=20 --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=3D269883 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=3D281360 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=E2=80=99s 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=E2=80=99ve been trying to debug for a while. = I=E2=80=99ve 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=E2=80=99s 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=E2=80=99t report any errors (I don=E2=80=99t = know if there=E2=80=99s 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 =3D 0x80 default 14:12:26.542682+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543622+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543657+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543690+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543697+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.543725+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 0x80 default 14:12:26.543730+0100 kernel smbfs_vnop_access: TheRooT = action =3D 0x80 denied default 14:12:26.544085+0100 kernel smbfs_vnop_access: 501 not = authorized to access TheRooT : action =3D 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=E2=80=99t support for = ACLs?

David

On 6 Sep 2024, at 22:48, Craig = Leres <leres@freebsd.org> = wrote:

=EF=BB=BFLast 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 =3D XYZ
=    security =3D user
=    netbios name =3D red
=    server string =3D red.example.net
=    hostname lookups =3D no
=    server role =3D standalone = server

   interfaces =3D = ixl0 lo0
   bind interfaces only =3D = yes

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

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

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

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

   inherit = permissions =3D = yes


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

=    hosts allow =3D = 10.0.0.19




= --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE--