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

On 3/13/26 19:42, Rick Macklem wrote:
> 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.

I should have noted that the man page also reported that some older
macOS versions did not use Apple Double by default when both NFSv3 and
NFSv4 were exported and the NFSv4 server supported named attributes:

"On the other hand NFSv4 can optionally support ACLs. And can optionally
support the storing of resource forks and extended attributes as NFSv4
named attributes.  Previous versions of NFSv4 on MacOS would use NFSv4
named attributes if supported by the server for storing extended
attributes and resource forks, . . ."

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

The name prefix used is: ._
'"Apple Double" (also known as a dot under bar file)'

macOS for NFSv3 uses such for extended attributes, including the
resource fork for a file.

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

man setxattr reports related to the handling of name/data pairs:

"The maximum supported size of extended attribute can be found out using
pathconf(2) with _PC_XATTR_SIZE_BITS option."

Looking . . .

"     _PC_XATTR_SIZE_BITS
             Returns the number of bits used to store maximum extended
attribute size in bytes.  For example, if the maximum attribute size
supported by a file system is 128K, the value returned will be 18.
However a value 18 can mean that the maximum attribute size can be
anywhere from (256KB - 1) to 128KB.  As a special case, the resource
fork can have much larger size, and some file system specific extended
attributes can have smaller and preset size; for example, Finder Info is
always 32 bytes."

That wording is definitely macOS specific for various details about what
an extended attribute is in macOS terminology. Back to setxattr:

"An extended attribute's name is a simple NULL-terminated UTF-8 string."
(const char *name). Also: just one open namespace with a reverse-DNS
naming convention for avoiding collisions. No security vs. system vs.
trusted vs. user concept.

There is a "u_int32_t position" parameter that is special:
"Position specifies the offset within the extended attribute.  In the
current implementation, only the resource fork extended attribute makes
use of this argument.  For all others, position is reserved and should
be set to zero."

On macOS file systems the resource fork is an extended attribute named
"com.apple.ResourceFork". For HFS+ updating the resource fork updates
the file's modification time (mtime). Some others might not.

There are (int) XATTR_NOFOLLOW, XATTR_CREATE, and XATTR_REPLACE options,
creation and replacement are allowed by default when the options are not
explicit. There is the "size_t size" parameter and the void *value
parameter.

fsetxattr takes an int fd (for an open file) instead of a const char*
path. There is also: getxattr, fgetxattr, listxattr, removexattr. There
is for the getxattr routines: XATTR_SHOWCOMPRESSION that seems to be
HFS+ specific, returning an attribute name if it is present.
XATTR_NOFOLLOW is also allowed.

(I'm not familiar with the above. I just read about it to give some idea.)

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


-- 
===
Mark Millard
marklmi at yahoo.com