Re: NFSv4 on MacOS Monterey

>> mountd_enable="YES"
> Since you have specified nfsv4_server_only, mountd will be configured correctly (using the -R),
> so this line is not needed (although I don't thing it will cause trouble).

Got it.

>> My configuration is as follows:
>>
>> SERVER CONFIGURATION
>>
>> OS: FreeBSD 13.1
>>
>> ===
>> /etc/rc.conf
>> # NFS Configuration
>> nfs_server_enable="YES"
>> nfs_server_flags="-u -t -n 4"
> 4 is very small, although that will only be a performance issue.

Increased to 12.

>> ===
>> /etc/sysctl.conf
>> # Asks nfsd to convert remote uids/gid encoded as numeric strings to be mapped to an actual uid/gid
>> vfs.nfsd.enable_stringtouid=1
> You probably do not want this. Since you are running nfsuserd, it will be mapping between
> the client uid/gid <-> the names for the Getattr/Setattr.
> If the Mac OSX client does not have "adonis" in its password database, that will be a problem.
> (These mappings have nothing to do with the uid/gids in the RPC header. The latter is used
>  to set the credentials for the RPC against the server. In your case, completely ignored.
>  The name<->uid/gid mappings are used for Setattr/Getattr. Things like "chmod", "stat"...)
>

Ok got it. So by default /etc/passwd doesn't have my user "adonis" but /etc/passwd on MacOS states:

===
##
# User Database
#
# Note that this file is consulted directly only when the system is running
# in single-user mode.  At other times this information is provided by
# Open Directory.
#
# See the opendirectoryd(8) man page for additional information about
# Open Directory.
##
===

I believe there shouldn't be a problem because as I state a little down below MacOS is sending the uid/gid as names as per below:

>> /etc/sysctl.conf
>> # Asks nfsd to convert remote uids/gid encoded as numeric strings to be mapped to an actual uid/gid
>> vfs.nfsd.enable_stringtouid=1
> You probably do not want this. Since you are running nfsuserd, it will be mapping between
> the client uid/gid <-> the names for the Getattr/Setattr.
> If the Mac OSX client does not have "adonis" in its password database, that will be a problem.
> (These mappings have nothing to do with the uid/gids in the RPC header. The latter is used
>  to set the credentials for the RPC against the server. In your case, completely ignored.
>  The name<->uid/gid mappings are used for Setattr/Getattr. Things like "chmod", "stat"...)
>
>> # Applies to both nfs server and client. Asks client/server to send numeric strings for uid/gid.
>> ### vfs.nfs.enable_uidtostring=0
> For a server, you either set both of the above to 1 and do not run the nfsuserd or set both of the
> above to 0 and set them both to 0. I do not know if Mac OSX knows how to do the "uid/gid" in
> the string for Getattr/Setattr, That is what you are doing when the above are set to 1 and is the
> default for Linux, plus works for FreeBSD so long as you are not using Kerberized mounts.
> (To know, you would need to look a Setattr RPC done by the Mac OSX client in wireshark for
>  either "chgrp" or "chown" and see how the Owner/Owner_Group string is formatted. A number
>  or a "name@domain".)
>

I inspected the packet trace for what MacOS sends for setattr when doing something like "chown adonis:wheel on a file" and indeed it does send name strings for OWNER and OWNER_GROUP in the following format "adonis@rambo.lan for OWNER" and "wheel@rambo.lan for OWNER_GROUP".

Given that, I set vfs.nfsd.enable_stringtouid back to 0.

>> 2. Extended attributes don't work at all. Here is the result:
>> ===
>> $ cd /Volumes/media
>> $ touch test.txt
>> $ xattr -w com.example.color blue test.txt
>>
>> # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' #
>> ===
> Yep, as noted above, they aren't supported and will not work. FreeBSD uses the Linux style extended
> attribute model, not the resource fork/subfile one that Mac OSX and Solaris use.
>

Is this still the case if the shares are on ZFS? Is there any info on when or if FreeBSD will get namedattr support?

-- 
Adonis