::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]
X-Rspamd-Queue-Id: 4fv8py33xjz3cZ6
X-Spamd-Bar: ----

On Sun, Apr 12, 2026 at 4:24=E2=80=AFPM Dan Shelton <dan.f.shelton@gmail.co=
m> wrote:
>
> On Mon, 13 Apr 2026 at 01:06, Rick Macklem <rick.macklem@gmail.com> wrote=
:
> >
> > On Sun, Apr 12, 2026 at 3:58=E2=80=AFPM Dan Shelton <dan.f.shelton@gmai=
l.com> wrote:
> > >
> > > On Wed, 11 Mar 2026 at 01:13, Rick Macklem <rick.macklem@gmail.com> w=
rote:
> > > >
> > > > On Tue, Mar 10, 2026 at 3:40=E2=80=AFPM Dan Shelton <dan.f.shelton@=
gmail.com> 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/nf=
s41_ops.c#L1394)
> > > > Hmm. The most obvious cause would be that the file system is not ex=
ported.
> > > > 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 mo=
unt
> > > >   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 w=
ireshare.)
> > >
> > > 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=3Ddir <volume>

If this is not the case for all file systems in the mount path, that
might explain the problem?

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
>