Re: FreeBSD 15.0 nfsd makes all write accesses EPERM

On Tue, Jan 6, 2026 at 3:05 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Tue, Jan 6, 2026 at 12:36 PM Aurélien Couderc
> <aurelien.couderc2002@gmail.com> wrote:
> >
> > On Tue, Jan 6, 2026 at 9:07 PM Aurélien Couderc
> > <aurelien.couderc2002@gmail.com> wrote:
> > >
> > > Our CI uses this script to quickly setup a FreeBSD NFSv4.1 server for
> > > testing. The script worked with FreeBSD 14.2, but with FreeBSD 15.0
> > > all files are suddenly read-only (write access gets EPERM):
> > >
> > > sysrc rpcbind_enable="YES"
> > > sysrc mountd_enable="YES"
> > > sysrc nfs_server_enable=YES
> > > sysrc nfsv4_server_enable=YES
> > > sysrc nfsuserd_flags="-domain GLOBAL.LOC"
> > > sysrc nfsuserd_enable=YES
> > > sysrc nfscbd_enable=YES
> > > printf 'vfs.nfs.enable_uidtostring=0\n' >>'/etc/sysctl.conf'
> > > printf 'vfs.nfsd.enable_stringtouid=0\n' >>'/etc/sysctl.conf'
> > > printf 'vfs.nfsd.issue_delegations=1\n' >>'/etc/sysctl.conf'
> > > mkdir /nfsdata
> > > chmod a+rwxt /nfsdata
> > > printf 'V4: /\n' >'/etc/exports'
> > > printf '/nfsdata -network=80.247.17.0 -mask=255.255.255.0  -sec=sys\n'
> > > >>'/etc/exports'
> > > service nfsd start
> > >
> > >
> > > The failed NFS4.2 op looks like this in wireshark:
> > >
> > > Network File System, Ops(8): SEQUENCE, PUTFH, SAVEFH, OPEN, GETFH,
> > > GETATTR, RESTOREFH, GETATTR
> > >     [Program Version: 4]
> > >     [V4 Procedure: COMPOUND (1)]
> > >     Tag: open
> > >     minorversion: 2
> > >     Operations (count: 8): SEQUENCE, PUTFH, SAVEFH, OPEN, GETFH,
> > > GETATTR, RESTOREFH, GETATTR
> > >         Opcode: SEQUENCE (53)
> > >         Opcode: PUTFH (22)
> > >         Opcode: SAVEFH (32)
> > >         Opcode: OPEN (18)
> > >             seqid: 0x00000000
> > >             share_access: OPEN4_SHARE_ACCESS_WRITE (2)
> > >             share_deny: OPEN4_SHARE_DENY_NONE (0)
> > >             clientid: 0x0000000000000000
> > >             owner: <DATA>
> > >             Open Type: OPEN4_CREATE (1)
> > >                 Create Mode: UNCHECKED4 (0)
> > >                 Attr mask[0]: 0x02000010 (Size, Hidden)
> > >                     reqd_attr: Size (4)
> > >                         size: 0
> > >                     reco_attr: Hidden (25)
> > >                         fattr4_hidden: No
> > >                 Attr mask[1]: 0x00004002 (Mode, System)
> > >                     reco_attr: Mode (33)
> > >                         mode: 0644, Name: Unknown, Read permission for
> > > owner, Write permission for owner, Read permission for group, Read
> > > permission for others
> > >                     reco_attr: System (46)
> > >                         fattr4_system: No
> > >             Claim Type: CLAIM_NULL (0)
> >
> > I think I found the problem: If our JAVA client does not set the
> > FATTR_HIDDEN and FATTR_SYSTEM attributes, then write access works.
> >
> > Why did this change in FreeBSD?
> Support for these was added for 15.0 (archive is in stable/15,
> but didn't quite make the release cutoff). Mostly because you
> guys requested them.
>
> It appears that you've found a bug in the handling of system, hidden
> in this new support. (In FreeBSD, they are never specified in OPEN, only
> in SETATTR, so you've tested the OPEN case and it appears to be broken.
> At this point, I am not sure if the breakage is in ZFS or the NFS server code,
> but I do see a place where the NFS server is missing code.
I think the bug is in ZFS. For file creation, it calls secpolicy_xvattr()
if any of the flags (system and hidden are in there).
secpolicy_xvattr() returns EPERM unless the caller is root.
--> This isn't correct for the flags that can be set by the owner
     of the file, such as system and hidden.
(This check is not done for zfs_setattr(), so chflags works as
expected.)

The fix is either to not call secpolicy_xvattr() when the flags are
ones that can be set by the file owner OR secpolicy_xvattr()
needs to be changed to handle these cases.

I can come up with a patch that disables the secpolicy_xvattr()
call if you can test it?

rick

>
> Can you build a kernel from sources with a test patch, if I email
> you the patch?
>
> rick
>
> >
> > Aurélien
> > --
> > Aurélien Couderc <aurelien.couderc2002@gmail.com>
> > Big Data/Data mining expert, chess enthusiast
> >