From nobody Mon Jun 15 05:27:50 2026 X-Original-To: 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 4gdzCp5cjTz6gqKL for ; Mon, 15 Jun 2026 05:27: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 "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gdzCp4YZfz3YN1 for ; Mon, 15 Jun 2026 05:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781501270; 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=ugh49BgRjywC95MTU/qq+CoiMqvKItWq+zKR6kEciDU=; b=r6BfD/zmyfKGQnzlr1xNCSqXbUqyH+l+IbYKRZIXFE4WI+Kwf2xYxE1ZPfe0l7oAKvbqM9 aQJvfcx1lvMXFv90ShztE8GWp9vZAj2nXLAAlpYtInDUyVKtURfsnmHjUG5R1Gd8pR6qzH VBXNwbKWkcf1QCv0C4LbtI39qCCLELeeSZ/UnIjcyD98scgOXT2LFZq0EHslNLVS68IK94 0MSCg7HCbd1zkq9u+nVJo1Te4JpVbwfM+SKwVaKC9ePCxkfA5zDPr8SbRdrh2FwjAedjSf E4WZl1XFT1cREH6VfvJ250FVW+IuLBmsZAwmoYMSaoHRzIfEvNeGJkNiZaRi0Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1781501270; a=rsa-sha256; cv=none; b=wPK24ajBm6XmVPkxrpLt0cXeBJVASK5KKkEGtfUKx27S46qhI61mARujz7+wyfPqhqLCh9 7K9RUoJ7mi2PmpkM0RryGfRPdK10gNLiLsDV42HGDMDnz4q+zPkLUxtBj5mZuihWaGpHei 2cJdpwCT+Yqfsg4Ac05bTDobZR7GBxM047DegMGHZdWwOG+fmyNhWcmsimGcnOqETldbWW 0b1tweV044AorOuNoZIcPQLihlwf6q/nmOHt0pGMPAQ4hNJELs76dLj8AZqJbrZisn+gSj El6SOjcMPng12yukoL2CnEbxFCsP5H9915dCiST7mCitA09BfqT/xoBF4FhP+g== 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=1781501270; 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=ugh49BgRjywC95MTU/qq+CoiMqvKItWq+zKR6kEciDU=; b=YEQKRVD+HUVNjPBLZlvgIuILAZoUFCIuaYI2mKHJdF3EpJUJa/aNRv6E38Uo5B4nXcy2b5 tBE7mCo+fkjcHQaN95bUKCrsodAgEBoU9QMk54lwLHrspjfl0k19hEbuNc93+OoRbTKgcD V8VgFIle39ONOz94/30TeWQeT/DpYKUUZtQQ7WfcVz/Q6NX3YyiIaHcCbetUVv4pR/CY78 qKF42kZGJ9PCoaj9V1LK5psCdUA4NSDCudCYrbzopkkz/b/Xxl/Vk3nNlY0MY1/huNwB36 4wQ7hMPNptHxvquiVh4HG9HOYRPHW+LNqw6wXdEIdkttS/fXW/aneZpxmSWsUA== 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 4gdzCp2hqmzhVB for ; Mon, 15 Jun 2026 05:27:50 +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 65F5RnjP004906 for ; Mon, 15 Jun 2026 05:27:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 65F5RnB7004905 for bugs@FreeBSD.org; Mon, 15 Jun 2026 05:27: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: bugs@FreeBSD.org Subject: [Bug 296066] macOS vi creates swap files with mode 0 on FreeBSD 15.1 NFSv4 export Date: Mon, 15 Jun 2026 05:27:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd.geography231@slmails.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D296066 Bug ID: 296066 Summary: macOS vi creates swap files with mode 0 on FreeBSD 15.1 NFSv4 export Product: Base System Version: 15.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd.geography231@slmails.com Created attachment 271811 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D271811&action= =3Dedit Patch to fix the two issues I've got a macOS 26.5 client mounting a NFSv4 share from a FreeBSD 15.1-REL= EASE server. The exported filesystem is on a ZFS pool. I noticed that on the Mac= , if I try to create a new file with vi, I get the following error: >>> E325: ATTENTION Found a swap file by the name "/Volumes/zraid/.foobar6.swp" dated: Fri Jun 12 14:50:49 2026 [cannot be opened] While opening file "/Volumes/zraid/foobar6" CANNOT BE FOUND (1) Another program may be editing the same file. If this is the case, be careful not to end up with two different instances of the same file when making changes. Quit, or continue with caution. (2) An edit session for this file crashed. If this is the case, use ":recover" or "vim -r /Volumes/zraid/foobar6" to recover the changes (see ":help recovery"). If you did this already, delete the swap file "/Volumes/zraid/.foobar6.= swp" to avoid this message. Swap file "/Volumes/zraid/.foobar6.swp" already exists! [O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort: <<< If I inspect the swap file, I see it has mode 0 permissions: $ ls -l /Volumes/zraid/.foobar6.swp ---------- 1 1001 1001 0 Jun 12 14:50 /Volumes/zraid/.foobar6.swp $ I am not versed in the NFS protocol, nor in the FreeBSD kernel or C, so I u= sed AI to help me debug some packet captures and trace the issue in the kernel.= It ultimately identified two separate bugs I was running into, and gave me a p= atch to fix both of them, which did indeed resolve the issues I was having. I generally take AI's conclusions with a grain of salt, but given that it w= as correct with a prior FreeBSD bug, and that its patch did fix this issue, I figure I'd bring it to you all the experts and see if there's anything ther= e. I've attached the patch for your reference rather than as a proposed fix, s= ince I imagine you all can do a better one. I'll also include its summary here in the hope that it is more illuminating: >>> Title: nfsrvd_setattr: SETATTR of time_create and BSD file flags fails non-fatally, leaving swap files with mode 0 on NFSv4 exports Component: sys/fs/nfsserver/nfs_nfsdserv.c Affected versions: FreeBSD 15.1-RELEASE (and likely earlier) # Summary: When a macOS NFSv4.0 client creates a file using OPEN4_CREATE with EXCLUSIV= E4 createmode and then issues a follow-up SETATTR containing mode, time_access_set, time_modify_set, time_create, archive, and hidden in a sin= gle compound, the FreeBSD NFSv4 server fails the entire SETATTR and reports a non-OK status to the client. This causes vim (and other applications using = the same open-create pattern) to leave swap files with mode 0 (----------), triggering spurious E325 ATTENTION warnings on every subsequent open of the file. Root cause =E2=80=94 two bugs in nfsrvd_setattr(): ## Bug 1: NFSATTRBIT_TIMECREATE in SETATTR nfsrvd_setattr() attempts to set birthtime (va_btime) via nfsvno_setattr() = =E2=86=92 VOP_SETATTR() when the client includes time_create in a SETATTR request. On FreeBSD, birthtime is not settable via VOP_SETATTR =E2=80=94 ZFS returns EI= NVAL (because AT_XVATTR is set but z_use_fuids is false, or simply because XAT_CREATETIME is a read-only attribute). This sets nd->nd_repstat before t= he mode attribute group is processed, so the mode is never applied and the file remains at mode 0. The attrsset bitmap in the reply shows only time_access_= set and time_modify_set (the groups that ran before time_create), and the overa= ll status is NFS4ERR_INVAL. RFC 7530 does not require servers to support setting time_create via SETATT= R. The correct behavior is to silently treat it as a no-op and report it as successfully set, consistent with the behavior of Linux nfsd and other NFSv4 server implementations. ## Bug 2: NFSATTRBIT_ARCHIVE/NFSATTRBIT_HIDDEN/NFSATTRBIT_SYSTEM in SETATTR After Bug 1 is fixed, a second failure surfaces: nfsrvd_setattr() attempts = to set BSD va_flags (via nfsvno_setattr()) when the client includes archive or hidden in the SETATTR request. On ZFS filesystems that do not support BSD f= ile flags (including any pool where z_use_fuids is false, such as ZFS pools at version 1), this call fails and the error is returned as the overall SETATTR status =E2=80=94 even though mode, time_access_set, and time_modify_set hav= e all been successfully applied. The result is NFS4ERR_IO on the wire, which causes vi= m to treat the swap file as unreadable even though its mode is now correct. These attributes are Windows/HFS+ compatibility metadata with no semantic equivalent on such filesystems. Failure to set them should be treated as non-fatal. # Fix: Two changes to nfsrvd_setattr() in sys/fs/nfsserver/nfs_nfsdserv.c: Replace the NFSATTRBIT_TIMECREATE block's nfsvno_setattr() call with an unconditional success =E2=80=94 skip the VOP call entirely and just set the= bit in retbits. After the NFSATTRBIT_ARCHIVE/HIDDEN/SYSTEM block's nfsvno_setattr() call, c= lear nd->nd_repstat if it is non-zero, treating the failure as non-fatal. # Reproduction: FreeBSD 15.1-RELEASE server exporting a ZFS filesystem via NFSv4. macOS client mounting the export via NFSv4.0. Run vim on the mount. Observe E325 ATTENTION and mode 0 on the .swp file. Packet capture confirms the follow-up SETATTR after EXCLUSIVE4 open-create includes time_create, archive, and hidden, and the server returns a non-OK status. <<< --=20 You are receiving this mail because: You are the assignee for the bug.=