From nobody Tue Feb 28 20:34:49 2023 X-Original-To: ports-bugs@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 4PR8HZ0tG6z3tvLv for ; Tue, 28 Feb 2023 20:34:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PR8HY6y6Pz3x4F for ; Tue, 28 Feb 2023 20:34:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677616490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6zYX9s8HzEKGxjY3kvza1NfBnQC1u4nH/HmNlRd5Rig=; b=c9daOz8q7HX/DK2JR9tt6po0BSyxbkLFeyQgwvgANcW1EyFYEcVFhH11VRg503LJkztLLQ sJNQRxllUhGNo5VX8zz8ra9c324V/eJeqqh5E2hkOE9DmuA/Ka9SVtYmgyVHlgiuF2GC8m b19G7QkHDebdgDvNXI1v5a2ABPseZejUndaPSyZqvzxcOS+AHLfOLCQUwtko66zMwlYg6b PwOPoUpUAIL/f+xxhUnnNmnCU6KQgQOe3h00c9p59aHQRSUbud4PRpFl+snq/Y4emi16ZC 1rPXLSbF8xyKYUFjPX1T7/lVN68URlFhF+kZ0hwvBEKkZy3xRX5BnNw9aScH/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677616490; a=rsa-sha256; cv=none; b=eQ14xTW+RGUbmETni9pdWXOSkLlqPVq6e0Vf0oPHMVwCkC2M0NKVqjSxkiOy2RNnSanAY4 irQG3/Qmms7EDHHPRI9RFLS118UW8OjljyFXUEJe10CTzpLyIxVJwkdC64l/7iW+jYSlQU AZuasaMiIJFctoaykkKlhNeZrdt8zqTsjlnVpgzPp3GBN+qdoN7U6DKGIX5wPWXXYhjfJK HHlx4WYW2MwzhIS/h2ZG44Dv/9b1LMwk5cjtQXC4VCwWyp3u+bEZwPo4P1vooTCbpIiRzE w+MUZlk2EZvNq55Fr+plGx/Ohz8Web/V0taNR6fwRsV0D9t1IQh7ynt4Z+lS3Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PR8HY5w5Wz1LLn for ; Tue, 28 Feb 2023 20:34:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31SKYnDQ034193 for ; Tue, 28 Feb 2023 20:34:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31SKYnq9034192 for ports-bugs@FreeBSD.org; Tue, 28 Feb 2023 20:34:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 269883] net/samba416: macOS Time Machine backups broken after contrib/tzcode update in 13.2 Date: Tue, 28 Feb 2023 20:34:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: timur@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269883 Bug ID: 269883 Summary: net/samba416: macOS Time Machine backups broken after contrib/tzcode update in 13.2 Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: timur@FreeBSD.org Reporter: dim@FreeBSD.org Assignee: timur@FreeBSD.org Flags: maintainer-feedback?(timur@FreeBSD.org) TL;DR: the "fruit:zero_file_id" setting should be "yes" by default and we should apply upstream Samba patches for this, otherwise existing Time Machi= ne backups over SMB can get messed up. Long story: I recently encounted problems with Apple's Time Machine backing up to a Fre= eBSD server with samba416-4.16.8 installed. These problems started after I upgra= ded the base system from 13.1-STABLE (of ~3 months ago) to 13.2-STABLE (as of a= few days ago), and then rebuilding all my ports, including the samba416-4.16.8 package. The problems initially showed as hanging or aborting Time Machine backups, = and if you would attempt a "verify backups" action, it would run fsck_apfs on t= he disk image mounted over SMB, which then showed errors similar to: /dev/disk5s1: fsck_apfs started at Mon Feb 27 00:20:36 2023 /dev/disk5s1: ** Checking the container superblock. /dev/disk5s1: Checking the checkpoint with transaction ID 2199286. /dev/disk5s1: ** Checking the space manager. /dev/disk5s1: ** Checking the space manager free queue trees. /dev/disk5s1: ** Checking the object map. /dev/disk5s1: ** Checking volume /dev/rdisk5s1. /dev/disk5s1: ** Checking the APFS volume superblock. /dev/disk5s1: The volume Backups of mac was formatted by newfs_apfs (1677.81.1) and last modified by apfs_kext (2142.81.1). /dev/disk5s1: ** Checking the object map. /dev/disk5s1: warning: (oid 0x2126b29c) om: btn: invalid o_cksum (0x1700608e55352f42) /dev/disk5s1: Object map is invalid. /dev/disk5s1: ** The volume /dev/rdisk5s1 was found to be corrupt and canno= t be repaired. /dev/disk5s1: ** Verifying allocated space. /dev/disk5s1: ** The volume /dev/disk5s1 could not be verified completely. /dev/disk5s1: fsck_apfs completed at Mon Feb 27 00:20:44 2023 Even if you would rollback the share (with zfs rollback) to a known-good st= ate, i.e. which had successfully verified OK in the past, it would *still* get fsck_apfs errors like above. However, when I reinstalled the samba416-4.16.8 package from the old poudri= ere packages directory, which had been built with 13.1-STABLE, it all worked fi= ne again, and full fsck_apfs runs were completely OK! So what was the cause for the difference, even if the port versions were exactly the same? It turned out to be quite a deep rabbit hole! After a *lot* of experimentation, swapping back .so files from "good" and "= bad" packages, and even going so far as to swap .o files from "good" and "bad" builds and re-linking them, I found that the culprit was in libsamba-util.s= o.0, specifically the lib/util/time.c.26.o file. This file got compiled differently on 13.2-STABLE than on 13.1-STABLE: On 13.2-STABLE, the TIME_T_MAX define would have been set by the configure script, to the value 67768036191676799ll. On 13.1-STABLE, the TIME_T_MAX define would *not* have been set by the configure script, and time.h would then define it as: #define TIME_T_MAX MIN(INT32_MAX,_TYPE_MAXIMUM(time_t)) which effectively becomes INT32_MAX, i.e. 0x7fffffff. This was also visible in one the changed lines in the build logs (I had logs from both the poudriere run with 13.1 world, and with 13.2 world): 1606c1606 < Checking for the maximum value of the 'time_t' type=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 : not found=20 --- > Checking for the maximum value of the 'time_t' type = : ok=20 So on 13.1 it could not find the maximum value, while on 13.2 it could. The reason for this is a recent contrib/tzcode update, , which now makes gmtime(0x7fffffffffffffffll) fail, whereas it succeeded before. Samba uses = this check in its configure script. It turns out that Samba uses this TIME_T_MAX value in all kinds of places, = but most importantly (in some cases) it used to generate SMB file IDs! If TIME_T_MAX is a different value, some files might get completely different = file ID numbers, and apparently this greatly confuses the Apple SMB client. The code deriving file IDs from timestamps was added for Samba bug 14928 in , arou= nd the Samba 4.15.4 release. But later, after talking to Apple people, they have ripped out this whole t= hing again, in : smbd: remove itime and file_id logic and code This bases File-Ids on the inode numbers again. The whole stuff was added because at that time Apple clients 1. would be upset by inode number reusage and 2. had a client side bug in their fallback implemetentation that assigns File-Ids on the client side in case the server provides File-Ids of 0. After discussion with folks at Apple it should be safe these days to rely on the Mac to generate its own File-Ids and let Samba return 0 File-Ids. and its follow-up, : vfs_fruit: change default for "fruit:zero_file_id" option to yes After discussion with folks at Apple it should be safe these days to re= ly on the Mac to generate its own File-Ids and let Samba return 0 File-Ids. Signed-off-by: Ralph Boehme Reviewed-by: Jeremy Allison For now, if anybody encounters this bug with Apple's Time Machine, you shou= ld work around it by setting "fruit:zero_file_id =3D yes" in your smb4.conf, e= ither in the [global] section, or in the specific shares for Time Machine (i.e. t= hose with "fruit:time machine =3D yes"). But it would be nice if we could import the two above Samba commits: because that seems a lot safer. At the least the last one, which is trivial because it only sets the default for "fruit:zero_file_id" to "yes". --=20 You are receiving this mail because: You are the assignee for the bug.=