From nobody Sun Sep 08 11:48:13 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 4X1pBd5zwrz5TbkW for ; Sun, 08 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1pBd5Q7Lz4vkm; Sun, 8 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725796105; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w0RG6a77cV8hK2EcolEvlpHIBD/EWZ+92pBAhN8DIJQ=; b=yCEd7P2C2oGYIY5zNktZhw/xWwHp6ObV3O/Vyq7wALzAYy/C6D1IZTg3JC/+eGpyyxNUQ2 cvoTZZ0t4BCJLhI92TWjyWAJy/5aWDac8Ctf0rb51My/5Onm4ypBZKvm17FJ7Y30xpEj4M NFuL5hmd6OpS2rWYRIplC30jkO78UodeovugC3R6N+76wkAjePM+upg8Z+G/oZMUCk0xY1 IA6RO9Es4C1Wsr6+vvywDADAo4Cv75ixP5R5GY9xmxC1FxTxf0NFnyEmn+DP7mIJLxp/IM ESZcYLqFqMc1yjfPcGzu6/F6m2JQ7qSfh6XS9Oqq5V7BVxQ7EAmtv2ekvXo8lA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725796105; a=rsa-sha256; cv=none; b=Pt0dQuKAyhXN/HySTdsne+YTcQ1Rrxhd7HmZo2MLnAZ74CmhoS8KJ8eSC5hyihCWh5k3fV 0HAl1R5oxxZY6X+H2qZ0d57ngq2vEY/rqMl0ohjptvkxwdqwi7QnITa6nXIZdffTlSys4v /JtkE0466FVv8u338kyf2mWRRlP+CQ26KCwTZIwKgLyUXl5dd8NmnOvwbo4XtfzffyPNau zAJl7NZ30SzL1S8LsZBAvlUqhkmTuPYvCTG1gNbrRChvMyWI0kbWOhsm5nVSWK9rmH9kS4 4OoTe/pGGJcqdOf9EM1THgBk6kpMPYhDer4G2mg7lgPvN5Mw5/ZNy5TV61ncsQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725796105; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w0RG6a77cV8hK2EcolEvlpHIBD/EWZ+92pBAhN8DIJQ=; b=WNGXK9t2u45GYdhIrepM/8OpdbgEb6EDUAkKrE7nIbY2n8wLCQhSZU8b27eBEwQNe4AUcH zQbdoybek+K16JVnq3+z+Uhb6jU5Ba3jxNj4AtmogyCU1ocnu0vUR2Rnw2h4GJDTFrIrkQ O2ZqsMmOJtPT+KEIDICeYcA26z6mdRm6920AcLAmukpNKfmfvGZSlZwhX6raSclywhsfQU r3JSm2frMNE6sqOBPNpW3e4cNAgJNr9N3hZOgVHlEx3RxkzId6sjFyIK7RX3OQEIjsnNY5 D31HZWJa+aZDPAujQOOiM6r+HGtJgaheFKLXw8cpc9VLX2MCKTqnN1AYGh8ZjA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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 did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X1pBd4qJfzNpM; Sun, 8 Sep 2024 11:48:25 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 5F08D655D; Sun, 08 Sep 2024 12:48:24 +0100 (BST) From: David Chisnall Message-Id: <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289" 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 \(3776.700.51\)) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sun, 8 Sep 2024 12:48:13 +0100 In-Reply-To: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> Cc: freebsd-hackers@freebsd.org To: Craig Leres References: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. =20 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. =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. David > 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=99v= e 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 --Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=_67B347E7-DD34-4809-9D31-66797B260289--