Re: [Ms-nfs41-client-devel] FreeBSD-16.0-CURRENT-amd64-20260224: NFSv4.2 on Windows: mkdir fails, touch works

On Mon, Mar 23, 2026 at 7:56 PM Dan Shelton <[email protected]> wrote:
>
> On Tue, 17 Mar 2026 at 01:29, Rick Macklem <[email protected]> wrote:
> >
> > On Mon, Mar 16, 2026 at 3:23 PM Dan Shelton <[email protected]> wrote:
> > >
> > > On Thu, 12 Mar 2026 at 00:20, Rick Macklem <[email protected]> wrote:
> > > >
> > > > On Mon, Mar 9, 2026 at 4:36 PM Rick Macklem <[email protected]> wrote:
> > > > >
> > > > > On Mon, Mar 9, 2026 at 9:43 AM Roland Mainz <[email protected]> wrote:
> > > > > >
> > > > > > On Sat, Mar 7, 2026 at 10:28 PM Rick Macklem <[email protected]> wrote:
> > > > > > >
> > > > > > > On Sat, Mar 7, 2026 at 9:27 AM Dan Shelton <[email protected]> wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > some odd issue with FreeBSD 16.0-CURRENT main-n284403-895a97c875a0
> > > > > > > > (installed from
> > > > > > > > FreeBSD-16.0-CURRENT-amd64-20260224-16822dac32ab-284159-disc1.iso) and
> > > > > > > > ms-nfs41-client:
> > > > > > > > $ /sbin/nfs_mount -o rw 'F:' 'nfs://42.28.16.228//nfsdata'
> > > > > > > > Successfully mounted '42.28.16.228@NFS@2049' to drive 'F:'
> > > > > > > > $ cd /cygdrive/f/dsheldon/tmp/freebsdtests
> > > > > > > >
> > > > > > > > $ touch x
> > > > > > > > $ mkdir y_dir
> > > > > > > > mkdir: cannot create directory ‘y_dir’: Permission denied
> > > > > > > >
> > > > > > > > I tried this:
> > > > > > > > $ chmod a+rwx .
> > > > > > > > $ mkdir y_dir
> > > > > > > > mkdir: cannot create directory ‘y_dir’: Permission denied
> > > > > > > >
> > > > > > > >
> > > > > > > > No ACLs involved.
> > > > > > > > The same setup works with FreeBSD 15.0.
> > > > > > > >
> > > > > > > > How can I debug this, or is this a known issue?
> > > > > > > Hmm. I don't think anything has changed for mkdir between
> > > > > > > 15.0 and man/16 in the NFS server code.
> > > > > Yep, the change was that FreeBSD16 supports Archive, but didn't
> > > > > handle setting it when doing a CREATE operation.
> > > > >
> > > > > > >
> > > > > > > - If the mkdir request (actually MKNOD in NFSv4) specifies
> > > > > > >   an owner or owner_group, the permissions are checked as follows:
> > > > > > >   - For setting owner to anything other than the uid of the caller in
> > > > > > >     the RPC request's credentials, the caller must be root and the
> > > > > > >     file system exported -maproot=root.
> > > > > > >  - For setting an owner_group, the gid owner_group maps to must
> > > > > > >    be in the gid list of the RPC's credentials.
> > > > > > >
> > > > > > > I'd suggest you capture packets when the mkdir fails and then..
> > > > > > > - Either look at them in wireshark yourself and see what attributes
> > > > > > >   are being set by the operation. In particular, check for any ACL
> > > > > > >   being specified (I know you said ACLs are not involved, but..)
> > > > > > >   along with OWNER and OWNER_GROUP.
> > > > > > > or
> > > > > > > - Make the packet capture available to me and I'll look at it.
> > > > > > >
> > > > > > > I suspect the NFS4ERR_PERM is being generated because of
> > > > > > > the attributes being set by the MKNOD operation and I suspect
> > > > > > > there is some difference between how you have 15.0 configured
> > > > > > > and main/16 configured.
> > > > > > [snip]
> > > > > >
> > > > > > It seems to be an issue with |FATTR4_ARCHIVE| ... I filed
> > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293691 ("NFSv4.1
> > > > > > client trying to set |FATTR4_ARCHIVE| gets EPERM for file/dir creation
> > > > > > attempts") for this, and added
> > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292283 ("Bug 292283
> > > > > > - (JAVA) NFSv4.1 client trying to set FATTR4_SYSTEM or FATTR4_HIDDEN
> > > > > > gets EPERM for file and dir creation attemps") as reference since the
> > > > > > same kind of workaround seems to work.
> > > > > >
> > > > > > Next release for ms-nfs41-client includes a workaround (see
> > > > > > https://github.com/kofemann/ms-nfs41-client/commit/7156d9f9deb25843e57fd455d8ec67951b82c737)
> > > > > > which should avoid this bug, but I will remove that workaround as soon
> > > > > > as a fixed release version of FreeBSD will become available...
> > > > > I've put a patch on this FreeBSD PR and am attaching it here.
> > > > Dan, can you test the patch and let us know if it works for you?
> > >
> > > https://bz-attachments.freebsd.org/attachment.cgi?id=268667 works, and
> > > fixes the bug.
> > >
> > > Could you send a comment around when the next iso for FreeBSD
> > > 16.0-CURRENT comes out with that bugfix, please?
> > The patch is now committed to main/16.0-current, so any snapshot
> > generated after to-day should have it.
> > (They are typically generated once per week on Thursdays.)
>
> Is this fix included in
> https://download.freebsd.org/snapshots/ISO-IMAGES/16.0/FreeBSD-16.0-CURRENT-amd64-20260316-e6083790f217-284522-disc1.iso
Don't know. If you look, I posted on Mar. 17 at 01:29 and the date on
this one is Mar 16 (look for 20260316 in the name).

So, I doubt it, but it might have made it into it, rick

>
> >
> > Thanks for testing it, rick
>
> Thank you for fixing this!
>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd
>