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
