Re: FreeBSD 16 nfsd: Unexpected NFS error 'NFS4ERR_NOFILEHANDLE' while probing named attr support

On Sun, Apr 12, 2026 at 6:24 PM Rick Macklem <[email protected]> wrote:
>
> On Sun, Apr 12, 2026 at 4:24 PM Dan Shelton <[email protected]> wrote:
> >
> > On Mon, 13 Apr 2026 at 01:06, Rick Macklem <[email protected]> wrote:
> > >
> > > On Sun, Apr 12, 2026 at 3:58 PM Dan Shelton <[email protected]> wrote:
> > > >
> > > > On Wed, 11 Mar 2026 at 01:13, Rick Macklem <[email protected]> wrote:
> > > > >
> > > > > On Tue, Mar 10, 2026 at 3:40 PM Dan Shelton <[email protected]> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > some odd issue with ms-nfs41-client: when connecting to a FreeBSD
> > > > > > 16.0-CURRENT main-n284403-895a97c875a0 (installed from
> > > > > > FreeBSD-16.0-CURRENT-amd64-20260224-16822dac32ab-284159-disc1.iso) NFS server:
> > > > > >
> > > > > > Windows side:
> > > > > > $ /sbin/nfs_mount -o rw 'F:' 'nfs://42.28.16.228//nfsdata'
> > > > > > Successfully mounted '42.28.16.228@NFS@2049' to drive 'F:'
> > > > > >
> > > > > > ms-nfs41-client prints this warning:
> > > > > > 204c: nfs41_superblock_getattr: Unexpected NFS error
> > > > > > 'NFS4ERR_NOFILEHANDLE' while probing named attr support
> > > > > > (the warning comes from
> > > > > > https://github.com/kofemann/ms-nfs41-client/blob/master/daemon/nfs41_ops.c#L1394)
> > > > > Hmm. The most obvious cause would be that the file system is not exported.
> > > > > Check the /etc/exports and, if you use the ZFS nfshare property,
> > > > > /etc/zfs/exports
> > > > > and make sure the file system is exported?
> > > > >
> > > > > As I've already mentioned, a packet capture is what I use to figure out
> > > > > what is going on. On the FreeBSD server..
> > > > > # tcpdump -s 0 -w out.pcap host <windows-client>
> > > > > - For a simple failure like the above, start it before doing the mount
> > > > >   and then kill it after the failure and send me "out.pcap".
> > > > >   (If there is going to be stuff in out.pcap that you need to keep
> > > > >    confidential, then you'll need to look at out.pcap yourself in wireshare.)
> > > >
> > > > We hit this bloody problem several times in February and March.
> > > > Workaround was to reboot until FILE_NAMED_STREAMS was reported.
> > > I'll admit I have no idea what you mean by this?
> >
> > Windows API: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
> >
> > Windows sets the FILE_NAMED_STREAMS flag if a volume supports "Win32
> > named streams". msnfs41client implements Win32 named streams via NFS
> > named attr support. If the NFS server does not support NFS named
> > attrs, then the FILE_NAMED_STREAMS is not enabled, which breaks some
> > Windows applications.
> >
> > Sometimes NFS named attrs are not detected. CAD/CAM customers want my
> > head because of this right now.
> The FreeBSD server will only report that it supports named attributes if
> the exported file system is ZFS with the xattr property set to dir.
> # zfs set xattr=dir <volume>
>
> If this is not the case for all file systems in the mount path, that
> might explain the problem?
Also, the "named_attr" attribute will only be true for files that
have a named attribute directory.
This might be checked by the client and causes the confusion,
where it expects "true" even if there is not yet any named attribute
directory for the file?

rick

>
> Otherwise, I need to see a packet trace, rick
>
> >
> > >
> > > >
> > > > What is the preferred tool to make a package capture on FreeBSD?
> > > (Assuming you meant packet capture..)
> >
> > Yes, classic autocorrect fail. Welcome to the age of AI. Also the day
> > when my wife says I must not touch coffee.
> >
> > >
> > > # tcpdump -s 0 -w out.pcap host <nfs-client-host>
> >
> > Thank you
> >
> > Dan
> > --
> > Dan Shelton - Cluster Specialist Win/Lin/Bsd
> >