Date: Thu, 02 Jun 2022 18:16:06 -0400 From: Adonis Peralta <donileo@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-net@freebsd.org Subject: Re: NFSv4 on MacOS Monterey Message-ID: <C0BD4628-9C6E-4455-B860-521FEA45BF63@gmail.com> In-Reply-To: <YQBPR0101MB9742A0A5CACD34C777B2570EDDDE9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> References: <5B070ACE-9ECD-4FAA-A975-C77BE87CEFAA@gmail.com> <YQBPR0101MB9742A0A5CACD34C777B2570EDDDE9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>> mountd_enable=3D"YES" > Since you have specified nfsv4_server_only, mountd will be configured c= orrectly (using the -R), > so this line is not needed (although I don't thing it will cause troubl= e). Got it. >> My configuration is as follows: >> >> SERVER CONFIGURATION >> >> OS: FreeBSD 13.1 >> >> =3D=3D=3D >> /etc/rc.conf >> # NFS Configuration >> nfs_server_enable=3D"YES" >> nfs_server_flags=3D"-u -t -n 4" > 4 is very small, although that will only be a performance issue. Increased to 12. >> =3D=3D=3D >> /etc/sysctl.conf >> # Asks nfsd to convert remote uids/gid encoded as numeric strings to b= e mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=3D1 > 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, c= ompletely 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 /e= tc/passwd on MacOS states: =3D=3D=3D ## # User Database # # Note that this file is consulted directly only when the system is runni= ng # 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. ## =3D=3D=3D I believe there shouldn't be a problem because as I state a little down b= elow 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 b= e mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=3D1 > 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, c= ompletely 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 nu= meric strings for uid/gid. >> ### vfs.nfs.enable_uidtostring=3D0 > 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 t= o do the "uid/gid" in > the string for Getattr/Setattr, That is what you are doing when the abo= ve 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 clie= nt 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 nam= e strings for OWNER and OWNER_GROUP in the following format "adonis@rambo= =2Elan 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: >> =3D=3D=3D >> $ cd /Volumes/media >> $ touch test.txt >> $ xattr -w com.example.color blue test.txt >> >> # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # >> =3D=3D=3D > Yep, as noted above, they aren't supported and will not work. FreeBSD u= ses the Linux style extended > attribute model, not the resource fork/subfile one that Mac OSX and Sol= aris use. > Is this still the case if the shares are on ZFS? Is there any info on whe= n or if FreeBSD will get namedattr support? -- = Adonis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0BD4628-9C6E-4455-B860-521FEA45BF63>