>> 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 "ado...@rambo.lan for OWNER" and "wh...@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
