Note: I had assistance from Google's AI in tracing down the cause of this bug, so the analysis represents of that plus my own. It looks like there is a regression in 15.1-RELEASE for chflags(2) operations on an NFSv4 mount when 'chflags(<file>, 0)' is used. In 15.0, my understanding is that call gets treated as a NOP by the nfscl layer, but in 15.1, due to the change in commit d842c511d84c (nfscl: Add some support for POSIX draft ACLs), the NFS layer is returning an explicit error back and this breaks userland components expecting something else. In my case, the error manifests when trying to run "make package" on sysutils/flashrom when /usr/ports is mounted over NFSv4.2. Changing to NFSv4.1 or 4.0 doesn't resolve it (I don't run NFSv3). Python, called by meson during flashrom's build, bails out because it is only expecting errno.EOPNOTSUPP or errno.ENOTSUP, not errno.EIO. Here's a test case (originally generated by Google's AI, but modified by me to make it return the errno to the shell): > #include <unistd.h> > #include <sys/stat.h> > #include <stdio.h> > #include <errno.h> > > int main() > { > int result = chflags("test.txt", 0); > > if (result == -1) > return errno; > > return result; > } 1. Create an empty file: > # touch test.txt 2. Compile: > # cc -O2 -pipe text.c -o test 3. Run the test case; on 15.0: > # ./test > # echo $? > 0 But on 15.1: > # ./test > nfsv4 err=10032 > # echo $? > 5 That "nfsv4 err=10032" string is literally printed to the screen, I assume from the kernel layer. My guess is this could affect other meson-based packages built over NFS. My workaround is to set WRKDIRPREFIX in /etc/make.conf to make it build locally vs over NFS, and that allows the build to complete.
Note: > 2. Compile: > > # cc -O2 -pipe text.c -o test Should read "test.c", not "text.c". If only Bugzilla allowed editing comments...
Well, it was actually commits c5d72d2 and 3b6d4c6, which only checked for support if the archive/hidden/system attributes were non-zero. Specifying chflags(<path>, 0) set them to zero, so it didn't fail this check, but attempted to set them to false on the server when the server did not support one or more of these attributes. The patch in the attachment should fix this. Btw, "chflags(<path>, 0)" is not a no-op, for ZFS stores (and NFS servers exporting them) it clears the UF_ARCHIVE (uarch) bit, which is set for any new file created on ZFS. You didn't mention what NFS server you were using, but I'll assume it was one that does not support all of the archive/hidden/system attributes. Please test the patch in the attachment and let us know if it fixed the problem for you? Thanks for reporting this, rick
Created attachment 271888 [details] Check for support of attributes if va_flags bit not set This patch fixes the case where the archive/hidden/system flags are being cleared. For this case, the attributes must be supported by the NFSv4 server.
(In reply to Rick Macklem from comment #2) > Well, it was actually commits c5d72d2 and 3b6d4c6, which > only checked for support if the archive/hidden/system > attributes were non-zero. Ah, whoops, I was looking only at commits checked into stable/15 between Jan 2026 and May 2026, since I wasn't seeing the issue on 15.0-RELEASE, and didn't think to look further back in time. I threw several commits in that range at Google's AI, and it locked onto d842c511d84c, since it modified the nfsrpc_setattr() function. I felt its analysis wasn't accurate, though, which is why I didn't quote it in more depth. That's also where I got the "treated as a NOP by the nfscl layer" bit from. > You didn't mention what NFS server you were using, but > I'll assume it was one that does not support all of the > archive/hidden/system attributes. My NFS server runs FreeBSD 15.0-RELEASE at the moment. I'll be upping that to 15.1-RELEASE in the next day or two. > Please test the patch in the attachment and let us know > if it fixed the problem for you? Confirmed that it fixes it. I was able to build sysutils/flashrom with the work dir on the NFS share and it built without error. My little test.c bit also returns errno 45 to the shell, which matches what the Meson/Python are looking for in flashrom's build logic. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=572680712c317b81d66475203ac1b9d6bbeca5d5 commit 572680712c317b81d66475203ac1b9d6bbeca5d5 Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2026-06-18 00:30:29 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2026-06-18 00:34:57 +0000 nfs_clvnops.c: Fix the case where va_flags are being cleared Commits c5d72d2 and 3b6d4c6 broke the case where the archive/hidden/system attributes are being set false (UF_ARCHIVE, UF_HIDDEN or UF_SYSTEM bits being cleared.) and the NFS server does not support those attributes. These patches only checked for support if the archive/hidden/system attributes were non-zero. This patch fixes the problem. PR: 296088 Tested by: Joshua Kinard <freebsd@kumba.dev> MFC after: 1 week Fixes: c5d72d29fe0e ("nfsv4: Add support for the NFSv4 hidden and system attributes") sys/fs/nfsclient/nfs_clvnops.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
Patch has been committed and will be MFC'd.
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3a3d12112483d22624971ca97c8b975329416122 commit 3a3d12112483d22624971ca97c8b975329416122 Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2026-06-18 00:30:29 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2026-06-25 00:48:15 +0000 nfs_clvnops.c: Fix the case where va_flags are being cleared Commits c5d72d2 and 3b6d4c6 broke the case where the archive/hidden/system attributes are being set false (UF_ARCHIVE, UF_HIDDEN or UF_SYSTEM bits being cleared.) and the NFS server does not support those attributes. These patches only checked for support if the archive/hidden/system attributes were non-zero. This patch fixes the problem. PR: 296088 (cherry picked from commit 572680712c317b81d66475203ac1b9d6bbeca5d5) sys/fs/nfsclient/nfs_clvnops.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
The patch has been MFC'd. I'll leave this In Progress until the OpenZFS patch finds its way into stable/15.