Date: Sun, 8 Sep 2024 12:48:13 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Craig Leres <leres@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Message-ID: <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> In-Reply-To: <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> References: <c7183af3-4a8b-4f12-848f-09f11e8b0e8f@freebsd.org> <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <theraven@FreeBSD.org> 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 <leres@freebsd.org> 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
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">A little bit =
more debugging, and a working hypothesis:<div><br></div><div>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. =
</div><div><br></div><div>If I mount the same share, I can =
reproduce this:</div><div><br></div><div><div>$ mkdir tmp</div><div>$ =
touch tmp/foo</div><div>$ mv tmp fmp</div><div>mv: rename tmp to fmp: =
Operation not supported</div></div><div><br></div><div>So it appears =
that something in the FreeBSD port of Samba has broken the ability to =
rename directories. </div><div><br></div><div>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.</div><div><br></div><div>David<br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On 7 Sep 2024, at 08:28, David Chisnall =
<theraven@FreeBSD.org> wrote:</div><br =
class=3D"Apple-interchange-newline"><div><meta http-equiv=3D"content-type"=
content=3D"text/html; charset=3Dutf-8"><div dir=3D"auto"><div =
dir=3D"ltr"></div><div dir=3D"ltr">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. </div><div =
dir=3D"ltr"><br></div><div dir=3D"ltr">It stopped working for me with no =
changes on the server and I can reproduce the failures on two different =
Macs.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Things I have =
tried:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"> - =
Upgrading Samba from 4.16 to 4.19</div><div dir=3D"ltr"> - =
Upgrading FreeBSD from 13.x to 14.1</div><div dir=3D"ltr"> - =
Setting the SMB timeout sysctls to larger values on macOS.</div><div =
dir=3D"ltr"> - Turning up the SMB debug sysctls on macOS to see if =
there=E2=80=99s more info</div><div dir=3D"ltr"> - Turning up the =
Samba logging level.</div><div dir=3D"ltr"> - Verifying the =
backups</div><div dir=3D"ltr"> - Watching smbinfo the =
server.</div><div dir=3D"ltr"> - Updating macOS to the latest =
version</div><div dir=3D"ltr"> - Connecting to the server with =
Finder and checking I can access files on the shares and that they have =
the right permissions.</div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr">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).</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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. </div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr">With the increased debugging, I see this in the macOS =
Comsole:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><span =
style=3D"white-space: pre-wrap; caret-color: rgb(51, 51, 51); color: =
rgb(51, 51, 51); font-family: "SF Pro Text", "SF Pro =
Icons", "Helvetica Neue", Helvetica, Arial, sans-serif; =
letter-spacing: -0.374px; -webkit-text-size-adjust: 100%; =
background-color: rgb(255, 255, 255);">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</span></div><div =
dir=3D"ltr"><span style=3D"white-space: pre-wrap; caret-color: rgb(51, =
51, 51); color: rgb(51, 51, 51); font-family: "SF Pro Text", =
"SF Pro Icons", "Helvetica Neue", Helvetica, Arial, =
sans-serif; letter-spacing: -0.374px; -webkit-text-size-adjust: 100%; =
background-color: rgb(255, 255, 255);"><br></span></div><div =
dir=3D"ltr"><span style=3D"white-space: pre-wrap; caret-color: rgb(51, =
51, 51); color: rgb(51, 51, 51); font-family: "SF Pro Text", =
"SF Pro Icons", "Helvetica Neue", Helvetica, Arial, =
sans-serif; letter-spacing: -0.374px; -webkit-text-size-adjust: 100%; =
background-color: rgb(255, 255, 255);">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?</span></div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr">David</div><div dir=3D"ltr"><br></div><div =
dir=3D"ltr"><blockquote type=3D"cite">On 6 Sep 2024, at 22:48, Craig =
Leres <leres@freebsd.org> =
wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div =
dir=3D"ltr">=EF=BB=BF<span>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.</span><br><span></span><br><span>I'm using the =
same port build options with 4.16 and =
4.19:</span><br><span></span><br><span> =
FAM</span><br><span> =
PYTHON3</span><br><span> =
QUOTAS</span><br><span> =
SYSLOG</span><br><span> =
UTMP</span><br><span> =
GSSAPI_BUILTIN</span><br><span> =
AVAHI</span><br><span> =
FRUIT</span><br><span></span><br><span>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.</span><br><span></span><br><span>Appended =
is the config that works with 4.16 (but not =
4.19)</span><br><span></span><br><span> =
Craig</span><br><span></span><br><span>[global]</span><br><span> =
workgroup =3D XYZ</span><br><span> =
security =3D user</span><br><span> =
netbios name =3D red</span><br><span> =
server string =3D red.example.net</span><br><span> =
hostname lookups =3D no</span><br><span> =
server role =3D standalone =
server</span><br><span></span><br><span> interfaces =3D =
ixl0 lo0</span><br><span> bind interfaces only =3D =
yes</span><br><span></span><br><span> load printers =3D =
no</span><br><span> show add printer wizard =3D =
no</span><br><span> time server =3D =
yes</span><br><span> use mmap =3D =
yes</span><br><span></span><br><span> dos charset =3D =
850</span><br><span> unix charset =3D =
UTF-8</span><br><span> mangled names =3D =
no</span><br><span></span><br><span> #log level =3D =
3</span><br><span> #log file =3D =
/tmp/samba.log</span><br><span> vfs objects =3D catia =
fruit streams_xattr zfsacl</span><br><span></span><br><span> =
fruit:model =3D MacSamba</span><br><span> =
fruit:resource =3D file</span><br><span> =
fruit:metadata =3D netatalk</span><br><span> =
fruit:nfs_aces =3D yes</span><br><span> =
fruit:copyfile =3D no</span><br><span> =
fruit:aapl =3D yes</span><br><span> =
fruit:zero_file_id =3D =
yes</span><br><span></span><br><span> inherit =
permissions =3D =
yes</span><br><span></span><br><span></span><br><span>[Time =
Machine]</span><br><span> path =3D =
/backups/mini</span><br><span> read only =3D =
no</span><br><span> guest ok =3D no</span><br><span> =
writeable =3D yes</span><br><span> =
browseable =3D yes</span><br><span> =
fruit:resource =3D file</span><br><span> =
fruit:time machine =3D yes</span><br><span> =
valid users =3D backup-mini</span><br><span> =
max disk size 512G</span><br><span></span><br><span> =
hosts allow =3D =
10.0.0.19</span><br><span></span><br></div></blockquote></div></div></bloc=
kquote></div><br></div></body></html>=
--Apple-Mail=_67B347E7-DD34-4809-9D31-66797B260289--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9F9D21A4-5747-4F2A-960E-2CF826C8BEC4>