Re: Feature table: FreeBSD 14.3, 14.4, ... 15.0, ... 16.0, which version supports which NFSv4 feature?

On Fri, Mar 13, 2026 at 7:12 PM Mark Millard <[email protected]> wrote:
>
> On 3/13/26 17:42, Rick Macklem wrote:
> > On Fri, Mar 13, 2026 at 5:21 PM Rick Macklem <[email protected]> wrote:
> >>
> >> On Fri, Mar 13, 2026 at 7:59 AM Aurélien Couderc
> >> <[email protected]> wrote:
> >>>
> >>> Which FreeBSD version of 14.3, 14.4, ... 15.0, ... 16.0, ... supports
> >>> which of the following NFSv4 features, for each of ZFS, UFS, TMPFS:
> >>> - attribute: FATTR4_ARCHIVE [yes/no]
> >>> - attribute: FATTR4_HIDDEN [yes/no]
> >>> - attribute: FATTR4_SYSTEM [yes/no]
> >>> - feature: NFSv4 named attributes [yes/no]
> >>> - feature: ZFS case insensitive filesystem sets FATTR_CASE_INSENSITIVE
> >>> to true [yes/no]
> >> For 14.n - no to all
> >> For 15.1 (coming out end of May) - ZFS - yes to all, UFS and TMPFS -
> >> yes for archive/hidden/system
> >> For 16.0 (which is at leas 18months away) ?? (unlikely to change except maybe
> >>   named attributes for tmpfs)
> >>
> >> Note that exporting of tmpfs is not a good plan imho, since the
> >> changes are all lost when the system crashes.
> >>
> >> Note to other readers..this only affects Windows NFSv4.n client(s)
> >> (and maybe the MacOS NFSv4.1 client). (I can't afford a Mac, so
> >> I have no access to one and Apple doesn't talk about NFS support,
> >> so it can only be determined by testing.
>
> macOS has an nfs man page that mentions NFSv4.0 and NFSv4.1 but not
> NFSv4.2 . It also has a mount_nfs man page.
The transition from NFSv4.0->4.1 was not a minor revision, it was a major
change (minor numbered only because the IETF working group is the NFSv4
working group, so a major # change would have required a new working group).

4.1->4.2 is a minor update, where assorted new optional operations and
attributes are added. (Technically, a NFSv4.1 client can be a conformant
NFSv4.2 client with the only change being the minor version number in
the RPC request header.)

macOS only added NFSv4.1 recently and it is how well it interoperates
with the FreeBSD server that I am interested in.

I will note that I have not seen bug reports related to the macOS client
mounting a FreeBSD server and I do know of someone who has done
some successful testing (one of the IETF working group's co-chairs).

Someone off-list has offered to help with some testing.

>
> One quote: "If the server is known to only have NFSv4 clients or is
> only exporting file systems with NFSv4 then MacOS clients should use the
> namedattr option". This is not the default for macOS because . . .
Since ZFS/NFSv4.1 on FreeBSD does now know how to do named attributes,
that is an area where testing will be useful.

>
> Otherwise Apple Double Files for extended attributes and resource forks
> for macOS clients should be used instead for avoiding mixes of nfs
> client versions for file systems exported as both v3 and v4 (the
> default) being data-loss incompatible based on what is visible vs. not
> for changes from each across versions: only NFSv4 supports named attributes.
And only certain NFSv4 servers. Basically Solaris and recent appropriately
configured FreeBSD systems exporting ZFS storage, plus ?? I know Linux
servers do not do named attributes.

>
> There is a procedure for converting an Apple Double style context for a
> file system to only NFSv4 style with named attributes used instead.
>
> Sounds messy.
Only someone testing it will find out.
(I'm guessing "Apple Double style" refers to the use of .<files> for
resource forks.)

It gets even more confusing for me. There is Apple macOS doc that
refers to "extended attributes" and it is not obvious if they are
referring to the fork-file/named-attribute stuff or the Linux style
extended attributes or ??

And on Windows, they have what they call extended attributes
(similar to the Linux/FreeBSD style ones, but not 100% compatible)
and "alternate data streams", which are named attributes.

Yep, messy is a pretty good description of it. Without a standard like POSIX,
you get whatever you get, rick

>
> >> I am not sure if what Microsoft
> >> calls the Exceed client is affected or not?
> > I will admit NFSv4.1/4.2 is odd, in that it is so complex no one will even
> > do a complete implementation of it (at least in my lifetime).
> > (The draft for the next RFC for it is currently 855 pages and growing.)
> >
> > What does happen roughly twice/year is what the IETF NFSv4 working
> > group calls a Bakeathon. It is an interoperability testing event, usually
> > with "most up to date, bits de jur" systems. Interoperability problems
> > identified during these events can usually be resolved before releases.
> >
> > Unfortunately (imho), neither the Windows NFSv4.1/4.2 developers nor
> > Apple attend these events. (Many years ago, Hummingbird did attend
> > with their NFSv4.0 client.)
> > As such, interoperability problems with these clients are only identified
> > when reported as bugs, typically after code is in releases.
> > (The above features are examples of these.)
> >
> > All I can say is that I have tried to encourage the Windows NFSv4.1/4.2
> > developers to attend these events (and others have, as well). I have also
> > tried to contact the Apple engineering people involved in their client,
> > but without success (I have never found a way to contact Apple's
> > engineering people and even people with Apple developer contracts
> > have also been unsuccessful).
> >
> > Bottom line, if anyone has the "connections" to get these engineers
> > involved in the Bakeathons, it would be good news for users of
> > these clients. (Attendance can be done remotely via the tailscale vpn,
> > so no travel $$ are required.)
> >
> > rick
> > ps: The next Bakeathon is scheduled for April 13-17, 2026.
> >
> >>
> >>>
> >>> I'll be nice to have that in table form in the FreeBSD mount.nfs manual page.
> >> This is not something typically in a FreeBSD man page.
> >>
> >> rick
> >>>
> >>> Aurélien
> >>> --
> >>> Aurélien Couderc <[email protected]>
> >>> Big Data/Data mining expert, chess enthusiast
> >>>
> >
> >
>
>
> --
> ===
> Mark Millard
> marklmi at yahoo.com