Date: Tue, 16 Jun 2026 15:01:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 296088] nfscl: chflags(<file>, 0) on an NFSv4.x mount returns EIO instead of being handled as a NOP. Message-ID: <bug-296088-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296088 Bug ID: 296088 Summary: nfscl: chflags(<file>, 0) on an NFSv4.x mount returns EIO instead of being handled as a NOP. Product: Base System Version: 15.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd@kumba.dev 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. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-296088-227>