NFSv4 on MacOS Monterey

From: Adonis Peralta <donileo_at_gmail.com>
Date: Thu, 02 Jun 2022 19:13:42 UTC
I have some NFSv4 (sec=sys) shares on FreeBSD 13.1 which I'm trying to connect correctly with MacOS 12.4 Monterey.
I got the basics down but don't think I have permissions and extended attributes working correctly.

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"
mountd_enable="YES"
### mountd_flags="-R"
### rpcbind_enable="YES"
### rpc_lockd_enable="YES"
### rpc_statd_enable="YES"
# Enable NFSv4
nfsv4_server_enable="YES"
nfsv4_server_only="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-domain rambo.lan"
===

===
/etc/exports
# Exports Configuration
/drivepool/backups -alldirs -mapall=adonis:wheel
/drivepool/media -alldirs -mapall=adonis:wheel
/drivepool/home/adonis -alldirs -mapall=adonis:wheel
/drivepool/public -mapall=adonis:wheel
V4: /drivepool adonis-mbp adonis-pc
===

===
/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
# Applies to both nfs server and client. Asks client/server to send numeric strings for uid/gid.
### vfs.nfs.enable_uidtostring=0
vfs.nfsd.debuglevel=3
===

The directories above are hosted on ZFS and nfs4 acls support is turned on.

CLIENT CONFIGURATION

OS: MacOS 12.4 Monterey

===
nfs.client.mount.options=vers=4.0,intr,namedattr
nfs.client.default_nfs4domain = rambo.lan
===

Note: above I'm using namedattr to try to get the client to connect with named attributes support.

RESULTS

What I see when I connect via finder is the following:

1. I am able to read/write to the shares since /etc/exports contains the -mapall line, yet inspecting a packet trace shows me:

===
packet #1
---
client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR
Opcode: PUTFH (22)
Opcode: ACCESS (3), [Check: RD LU MD XT DL XE]
Opcode: GETATTR (9)

packet #2
---
server ip -> client ip Operations (count: 3)
Opcode: PUTFH (22)
Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], [Allowed: RD LU]
    Status: NFS4_OK (0)
    Supported types (of requested): 0x1f
    Access rights (of requested): 0x03
        .... ...1 = 0x001 READ: allowed
        .... ..1. = 0x002 LOOKUP: allowed
        .... .0.. = 0x004 MODIFY: *Access Denied*
        .... 0... = 0x008 EXTEND: *Access Denied*
        ...0 .... = 0x010 DELETE: *Access Denied*
Opcode: GETATTR (9)
===

Why is MD, XT, DL coming up as Access Denied if I can read/write to the share?

I have a feeling this is because UID/GID mapping is not happening correctly. I can see in the packet trace that FreeBSD's `nfsd` is sending some credentials as `adonis@rambo.lan`, but MacOS's nfs client is sending uid 501 and gid 20 for my user in the RPC credentials. I don't see how `nfsd` will be able to map uid 501, gid 20 to the server's uid and gid and instead I was expecting `adonis@rambo.lan` to be sent for credentials from the client side.

The link below tells me that this is an inherent issue with NFSv4?
https://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+with+AUTH_UNIX

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' #
===

-- 
Adonis