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

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.

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 . . .

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.

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.

>> 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