NFSv4 on MacOS Monterey
- Reply: Rick Macklem : "Re: NFSv4 on MacOS Monterey"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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