From nobody Sat Sep 07 07:28:48 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 4X14Tn2x8Fz5Tq79 for ; Sat, 07 Sep 2024 07:29:01 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4X14Tn2M2tz48d1; Sat, 7 Sep 2024 07:29:01 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725694141; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4JyuolmzGpDZmw4UP0VhQo3M8EOZceOrGCNxjN1jWiY=; b=pYsjx5a3neTciLOLjTlaNpQAswiL5oNq+KZhxkLOUwS0bNBwnfHO3ZdDR7P8NYdVNa2M+M J4Z4fDCmfpsARmeg4ITXA6mCor1gxORh7Xxi5CZuV0hUhc2aChPnSlX7MOd5bMXEF8m4hQ G4iKPIVGoixZRC9B0e9PVfPkF91q9StD+BwEk2RSer6CT90wb34qBNk2acyCeaX9C2TLbS dMdlQAKx85PWl4AWZ4k9w58iClOoqaoc34GofIn5E9OtApB8ILAC9y6T3Po4v/ROo918do HNhSThW63/he5WysZvjQxbkpLs1cIt1d0xL7b4iNSU38cbYyxS+VqrDeMFdD2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725694141; a=rsa-sha256; cv=none; b=aBk0jBIxupWIAOZkHOEbAHCIirzWjFn4nqJ4/GCthaHJ/sZl/sVj0gR3rNC/svP8v34Zn3 P0SDhrnHN4vYT9yW6uocGMPYSoPNKZA4iEq1XxeTC9V9xXTA7K0CRJllazt6ISAuqzKSHw NT6zxwudi1Y4/tRGO8IJQ0kWhycM0wvzGJ5Jb60vZD1Q/h7ScPs1wAXa66Ybc9PBxAU650 IDB1MboIvNkp4iJMU7EgLiw7cDgNLmbwWj7zvBHP6H9RNLYQTqjxxrEIRukwNW4V5es1KT 7ka6b7xVHSG144Dn43/xwHb5DSvp4LBzKtT5Qu3W8rXlzv/pVxhmcEYlemFQ9g== 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=1725694141; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4JyuolmzGpDZmw4UP0VhQo3M8EOZceOrGCNxjN1jWiY=; b=FA9bQHhCeebYAshdrHzMfhZa9ZCSvkaAspSJ3F/yK0fHi/M1+t+2pl4kEZ8dCtJXZCDu6I TWXg7lOhMcaNv/0suNyOHgkifPv0JCxztVbw9SB6B8VYrEIiNye6Rldx+Tn6zvj7qTBwdg nrNyEi67+J0XXuNX93bHsw5Ptjer3snOFZ91VUPnOCascNE1xE+uoZ7TH6IDvXL4XU2q5H P1MEeHzwX1v0yyIpCWVMjPjcvmdBIkCTVwO3vIWa2LZ8ZXFoV6DuIyHDj3VN8m8wBoxFX5 WGYb2TdOznMH0SlOLlR3AgBMcFmG+R+JjpGeJcBNjzfaSvLL5rU0mrQhbvUuYQ== 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 4X14Tn1nx8z11RB; Sat, 7 Sep 2024 07:29:01 +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 19E1D6531; Sat, 07 Sep 2024 08:29:00 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Date: Sat, 7 Sep 2024 08:28:48 +0100 Message-Id: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> References: Cc: freebsd-hackers@freebsd.org In-Reply-To: To: Craig Leres X-Mailer: iPad Mail (21G93) --Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe this was broken by a macOS update around February. I=E2=80=99ve be= en trying to debug for a while. I=E2=80=99ve opened an Apple issue (FB145009= 50, for any Apple folks) but it shows up as few people reporting it. I poste= d on Mastodon and several people reported that Time Machine is broken and re= commended Carbon Copy Cloner as an alternative. I would like to see it fixed= , but it probably needs some more debugging by Apple folks.=20 It stopped working for me with no changes on the server and I can reproduce t= he 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 i= nfo - 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 t= he 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.=20 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_que= ry_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDesc= riptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authoriz= ed 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 authoriz= ed 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 authoriz= ed 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 authoriz= ed 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 authoriz= ed to access TheRooT : action =3D 0x80 So it looks as if it is a permission issue. Maybe the mcOS SMB client has st= arted using some bit of the protocol that Samba on FreeBSD doesn=E2=80=99t s= upport for ACLs? David > 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 re= cently tried to upgrade to samba419 and so far I'm unsuccessful. The error i= s "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 o= ld backups from the zfs volume on the server before starting. I've also lear= ned the rule that you need to delete and reattach the share on the mac side w= hen 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-69D1F0E4-BAAC-437C-A8A8-02482F956880 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I b= elieve this was broken by a macOS update around February. I=E2=80=99ve been t= rying to debug for a while. I=E2=80=99ve opened an Apple issue (FB14500950, f= or any Apple folks) but it shows up as few people reporting it. I posted on M= astodon and several people reported that Time Machine is broken and recommen= ded Carbon Copy Cloner as an alternative. I would like to see it fixed, but i= t 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 t= he Samba logging level.
 - Verifying the backups<= /div>
 - Watching smbinfo the server.
 - Updating macOS to the latest version
&nbs= p;- Connecting to the server with Finder and checking I can access files on t= he 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-denie= d things).

It appears that t= he Mac acquires a load of read-only locks and so does a lot of reads, but fo= r some reason it appears to fail the first write. Even with a verify, it loo= ks like it completes the verification bit but then fails to write to the pli= st file. 

With the inc= reased debugging, I see this in the macOS Comsole:
default 14:12:26.297714+0100 kernel smb= 2fs_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_que= ry_info (single request) failed 45 default 14:12:26.318319+0100 kernel smb2fs_smb_cmpd_query: smb2_smb_que= ry_info (single request) failed 45 default 14:12:26.326850+0100 backupd -[DIStatFS initWithFileDesc= riptor:error:]: File system is smbfs default 14:12:26.542645+0100 kernel smbfs_vnop_access: 501 not authoriz= ed 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 authoriz= ed 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 authoriz= ed 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 authoriz= ed 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 authoriz= ed to access TheRooT : action =3D 0x80
<= br>
So it looks as if it is a permission i= ssue. Maybe the mcOS SMB client has started using some bit of the protocol t= hat Samba on FreeBSD doesn=E2=80=99t support for ACLs?

David

On 6 Sep 2024, at 22:48, Craig Leres &l= t;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" a= nd I'm running 14.1.

I'm using the same por= t build options with 4.16 and 4.19:

 =   FAM
   PYTHON3
&= nbsp;  QUOTAS
   SYSLOG
=    UTMP
   GSSAPI_BUIL= TIN
   AVAHI
  &n= bsp;FRUIT

Having learned my lesson when I u= pgraded from 4.13 to 4.16, I removed the old backups from the zfs volume on t= he server before starting. I've also learned the rule that you need to delet= e 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)

       C= raig

[global]
  =  workgroup =3D XYZ
   security =3D user=
   netbios name =3D red
&n= bsp;  server string =3D red.example.net
 &nb= sp; hostname lookups =3D no
   server r= ole =3D standalone server

  &nbs= p;interfaces =3D ixl0 lo0
   bind interfaces= only =3D yes

   load print= ers =3D no
   show add printer wizard =3D no=
   time server =3D yes
&nb= sp;  use mmap =3D yes

 &nbs= p; dos charset =3D 850
   unix charset =3D= UTF-8
   mangled names =3D no

   #log level =3D 3
&nb= sp;  #log file =3D /tmp/samba.log
  &nb= sp;vfs objects =3D catia fruit streams_xattr zfsacl
<= br>    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
   f= ruit:zero_file_id =3D yes

  &nbs= p;inherit permissions =3D yes


[Time Machine]
   path =3D /backups/mini=
   read only =3D no
 =   guest ok =3D no
   writeable =3D= yes
   browseable =3D yes
&= nbsp;  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<= br>
= --Apple-Mail-69D1F0E4-BAAC-437C-A8A8-02482F956880--