Date: Thu, 2 Jun 2022 19:42:56 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Adonis Peralta <donileo@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: NFSv4 on MacOS Monterey Message-ID: <YQBPR0101MB9742A0A5CACD34C777B2570EDDDE9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <5B070ACE-9ECD-4FAA-A975-C77BE87CEFAA@gmail.com> References: <5B070ACE-9ECD-4FAA-A975-C77BE87CEFAA@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adonis Peralta <donileo@gmail.com> wrote:=0A= > I have some NFSv4 (sec=3Dsys) shares on FreeBSD 13.1 which I'm trying to = connect correctly with MacOS 12.4 > Monterey.=0A= > I got the basics down but don't think I have permissions and extended att= ributes working correctly.=0A= Well, here are a few comments. Note that I haven't used Mac OSX in over a d= ecade, so I don't remember=0A= much of anything about it.=0A= =0A= > My configuration is as follows:=0A= > =0A= > SERVER CONFIGURATION=0A= >=0A= > OS: FreeBSD 13.1=0A= >=0A= > =3D=3D=3D=0A= > /etc/rc.conf=0A= > # NFS Configuration=0A= > nfs_server_enable=3D"YES"=0A= > nfs_server_flags=3D"-u -t -n 4"=0A= 4 is very small, although that will only be a performance issue.=0A= =0A= > mountd_enable=3D"YES"=0A= Since you have specified nfsv4_server_only, mountd will be configured corre= ctly (using the -R),=0A= so this line is not needed (although I don't thing it will cause trouble).= =0A= =0A= > ### mountd_flags=3D"-R"=0A= > ### rpcbind_enable=3D"YES"=0A= > ### rpc_lockd_enable=3D"YES"=0A= >### rpc_statd_enable=3D"YES"=0A= > # Enable NFSv4=0A= > nfsv4_server_enable=3D"YES"=0A= > nfsv4_server_only=3D"YES"=0A= > nfsuserd_enable=3D"YES"=0A= > nfsuserd_flags=3D"-domain rambo.lan"=0A= > =3D=3D=3D=0A= > =0A= > =3D=3D=3D=0A= > /etc/exports=0A= > # Exports Configuration=0A= > /drivepool/backups -alldirs -mapall=3Dadonis:wheel=0A= > /drivepool/media -alldirs -mapall=3Dadonis:wheel=0A= > /drivepool/home/adonis -alldirs -mapall=3Dadonis:wheel=0A= > /drivepool/public -mapall=3Dadonis:wheel=0A= These lines mean that the uid/gids in the RPC headers will be ignored and a= ll=0A= RPCs will be done as whatever uid is assigned to "adonis" in the server's p= assword database.=0A= =0A= > V4: /drivepool adonis-mbp adonis-pc=0A= > =3D=3D=3D=0A= > =0A= > =3D=3D=3D=0A= > /etc/sysctl.conf=0A= > # Asks nfsd to convert remote uids/gid encoded as numeric strings to be m= apped to an actual uid/gid=0A= > vfs.nfsd.enable_stringtouid=3D1=0A= You probably do not want this. Since you are running nfsuserd, it will be m= apping between=0A= the client uid/gid <-> the names for the Getattr/Setattr.=0A= If the Mac OSX client does not have "adonis" in its password database, that= will be a problem.=0A= (These mappings have nothing to do with the uid/gids in the RPC header. The= latter is used=0A= to set the credentials for the RPC against the server. In your case, compl= etely ignored.=0A= The name<->uid/gid mappings are used for Setattr/Getattr. Things like "chm= od", "stat"...)=0A= =0A= > # Applies to both nfs server and client. Asks client/server to send numer= ic strings for uid/gid.=0A= > ### vfs.nfs.enable_uidtostring=3D0=0A= For a server, you either set both of the above to 1 and do not run the nfsu= serd or set both of the=0A= above to 0 and set them both to 0. I do not know if Mac OSX knows how to do= the "uid/gid" in=0A= the string for Getattr/Setattr, That is what you are doing when the above a= re set to 1 and is the=0A= default for Linux, plus works for FreeBSD so long as you are not using Kerb= erized mounts.=0A= (To know, you would need to look a Setattr RPC done by the Mac OSX client i= n wireshark for=0A= either "chgrp" or "chown" and see how the Owner/Owner_Group string is form= atted. A number=0A= or a "name@domain".)=0A= =0A= > vfs.nfsd.debuglevel=3D3=0A= > =3D=3D=3D=0A= >=0A= > The directories above are hosted on ZFS and nfs4 acls support is turned o= n.=0A= >=0A= > CLIENT CONFIGURATION=0A= >=0A= > OS: MacOS 12.4 Monterey=0A= >=0A= > =3D=3D=3D=0A= > nfs.client.mount.options=3Dvers=3D4.0,intr,namedattr=0A= Named attributes are not supported by the FreeBSD server and won't work.=0A= =0A= > nfs.client.default_nfs4domain =3D rambo.lan=0A= > =3D=3D=3D=0A= >=0A= > Note: above I'm using namedattr to try to get the client to connect with = named attributes support.=0A= As above, named attributes won't work.=0A= =0A= > RESULTS=0A= >=0A= > What I see when I connect via finder is the following:=0A= > =0A= > 1. I am able to read/write to the shares since /etc/exports contains the = -mapall line, yet inspecting a packet > trace shows me:=0A= > =0A= > =3D=3D=3D=0A= > packet #1=0A= > ---=0A= > client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR=0A= > Opcode: PUTFH (22)=0A= > Opcode: ACCESS (3), [Check: RD LU MD XT DL XE]=0A= > Opcode: GETATTR (9)=0A= >=0A= > packet #2=0A= > ---=0A= > server ip -> client ip Operations (count: 3)=0A= > Opcode: PUTFH (22)=0A= > Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], [Allo= wed: RD LU]=0A= > Status: NFS4_OK (0)=0A= > Supported types (of requested): 0x1f=0A= > Access rights (of requested): 0x03=0A= > .... ...1 =3D 0x001 READ: allowed=0A= > .... ..1. =3D 0x002 LOOKUP: allowed=0A= > .... .0.. =3D 0x004 MODIFY: *Access Denied*=0A= > .... 0... =3D 0x008 EXTEND: *Access Denied*=0A= > ...0 .... =3D 0x010 DELETE: *Access Denied*=0A= This is saying that the uid for "adonis" on the server does not have write = access to the file.=0A= =0A= > Opcode: GETATTR (9)=0A= > =3D=3D=3D=0A= >=0A= > Why is MD, XT, DL coming up as Access Denied if I can read/write to the s= hare?=0A= Hmm, not sure. If you were to show all the reply fields for the Getattr, th= en I could probably guess.=0A= It might be Owner (is it "adonis@rambo.lan"). it could be ACLs. To check th= ose, you should be able to=0A= do whatever the Mac OSX equivalent to getfacl is.=0A= =0A= > I have a feeling this is because UID/GID mapping is not happening correct= ly. I can see in the packet trace >that FreeBSD's `nfsd` is sending some cr= edentials 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 wa= s expecting `adonis@rambo.lan` to be sent for credentials from the client s= ide.=0A= As noted above, with "-mapall" the uid/gids in the RPC header are completel= y ignored.=0A= =0A= > The link below tells me that this is an inherent issue with NFSv4?=0A= > https://dfusion.com.au/wiki/tiki-index.php?page=3DWhy+NFSv4+UID+mapping+b= reaks+with+AUTH_UNIX=0A= >=0A= > 2. Extended attributes don't work at all. Here is the result:=0A= > =3D=3D=3D=0A= > $ cd /Volumes/media=0A= > $ touch test.txt=0A= > $ xattr -w com.example.color blue test.txt=0A= >=0A= > # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' #=0A= > =3D=3D=3D=0A= Yep, as noted above, they aren't supported and will not work. FreeBSD uses = the Linux style extended=0A= attribute model, not the resource fork/subfile one that Mac OSX and Solaris= use.=0A= =0A= rick=0A= =0A= --=0A= Adonis=0A= =0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB9742A0A5CACD34C777B2570EDDDE9>