-----Original Message----- From: Benjamin Coddington <bcodding@xxxxxxxxxx> Sent: Thursday, September 22, 2022 6:42 AM To: Alan Maxwell <amaxwell@xxxxxxxxx> Cc: linux-nfs@xxxxxxxxxxxxxxx Subject: [EXTERNAL] Re: nfsv4 client idmapper issue Caution! This email originated outside of FedEx. Please do not open attachments or click links from an unknown or suspicious origin. On 21 Sep 2022, at 14:13, Alan Maxwell wrote: > I am reporting an issue, not a fault or bugreport. > NFS client : Redhat 7 kernel: 3.10.0-1160.71.1.el7.x86_64. > The issue lies with the feature that nfs client that: if an nfs server > rejects an unmapped uid or gid, then the client will automatically > switch back to using the idmapper. > > Our particular configuration of nfsv4 server and client are based on > using numeric uidNumber and gidNumber communication. The nfs server > we are using , OneFS (Dell/EMC/Isilon) has a setting explicitly for > this use: "Do not send names". We have this set and our testing > showed working 100% with our nfs client. The main driver for us using > this feature is that our uid's are numeric. That causes issues with > commands like chown and apparently NFS setattr. Once we realized > that, we set the numeric setting and everything worked as planned. > Our problem with the feature comes due to a simple mistake made by an > Admin: > chgrp groupnotvalid file > When the admin issued a chgrp, but that group does not exist in the > directory service for the NFS server, the NFS server rejected the > change. Then the feature kicked in that "client will automatically > switch back to using the idmapper. " Which did make changes, the > /proc/self/mountstats showing the caps=0x7fff instead of 0xffff. > The only solution to get the mount to work as originally configured is > to umount/mount the share. > Bottom line: Our environment can not support idmapping. Having the > feature to disable it and that disable be forceful and not something > the kernel can decide to re-enable. > We would envision that if an invalid chown/chgrp were issued, to > simply return an error, report that the chown/chgrp were not applied > and simply leave the nfsmount as is. > > Alan Maxwell | Sr. System Programmer | Platinum Infrastructure|20 > FedEx Pkwy 1st Fl Vert,Collierville, TN 38017 Seems like a server bug to me -- if you want to set a numeric group on a file, the server doesn't need to "look up" the group to see if it exists, it should just set the value on the underlying filesystem. How would the server know what gidNumber to assign if the nfs client sent a name? Is there a method in Redhat to have the nfsclient only send uidNumbers/gidNumbers? What the server is signaling by sending back NFS4ERR_BADOWNER is that it actually /is/ doing id mapping. Doing id mapping or better name , id verification, is expected. We hope the server would tell us, "client sent name I can't verify or lookup" Why doesn't OneFS just set the value when told "Do not send names"? The nfsclient sends both a bad name and bad gidNumber, we actually think that should be the case, even and security=sys , there should be validation of users and groups. Ben
