Date: Sun, 8 Sep 2024 14:29:04 +0200 From: Dimitry Andric <dimitry@andric.com> To: David Chisnall <theraven@FreeBSD.org> Cc: Craig Leres <leres@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: FreeBSD+samba as a time machine server for OSX/Sonoma? Message-ID: <63540459-7D2E-4B70-962D-957550D294A3@andric.com> In-Reply-To: <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org> References: <c7183af3-4a8b-4f12-848f-09f11e8b0e8f@freebsd.org> <8E0CDC45-6521-4973-A349-9B5824C75863@freebsd.org> <9F9D21A4-5747-4F2A-960E-2CF826C8BEC4@FreeBSD.org> <1CF8CD26-51D8-4599-B398-DC333D3A9D1C@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <theraven@FreeBSD.org> 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 <theraven@FreeBSD.org> 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 <theraven@FreeBSD.org> = 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 <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 >>=20 >=20 --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE 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;">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.<div><br></div><div>The only problem I encountered was with samba416 = and fruit:zero_file_id, which severely borked TM shares, see <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269883">https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269883</a> for the = gory details.</div><div><br></div><div>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.</div><div><br></div><div>-Dimitry</div><div><br></div><div><div><di= v><blockquote type=3D"cite"><div>On 8 Sep 2024, at 14:10, 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 style=3D"overflow-wrap: = break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I = have opened <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360">https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281360</a> to track = this.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>David<br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 8 Sep 2024, at 12:48, 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 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></div></div></blockquote></div><br></div></div></di= v></blockquote></div><br></div></div></body></html>= --Apple-Mail=_95B3836D-5324-4998-A047-4379409D1DBE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63540459-7D2E-4B70-962D-957550D294A3>