-----Original Message----- From: Benjamin Coddington <bcodding@xxxxxxxxxx> Sent: Thursday, September 22, 2022 9:06 AM To: Alan Maxwell <amaxwell@xxxxxxxxx> Cc: linux-nfs@xxxxxxxxxxxxxxx Subject: Re: [EXTERNAL] nfsv4 client idmapper issue On 22 Sep 2022, at 9:45, Alan Maxwell wrote: > How would the server know what gidNumber to assign if the nfs client > sent a name? I'm not familiar with this server, but I'm guessing if you have it set to "Do not send names", then it also will try not to translate uid/gids it receives. Are you asking a theoretical question? We have server set to "do not send names" because our uid's are fully numeric and that causes similar problem with nfs-client. > Is there a method in Redhat to have the nfsclient only send > uidNumbers/gidNumbers? Better to use Red Hat's support for these type of questions because this list is mostly upstream development work, but I believe that's the point of nfs4_disable_idmapping which exists on that kernel. I have an open case with Redhat, they have instructed that, "the upstream kernel has this feature, we can't make any corrections" > 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" Right, and that is a signal to the client that the server is not doing the "Do not send names" thing, rather trying to map values, so the client changes its behavior. If you're only sending integer gid values, what does it mean to verify a group id? If you want your server to treat the values as integer gids, then it shouldn't return an error that means "I couldn't translate this into a gid". Again, we would expect ultimately if the server returns error, nfs client should do same, show and error, not change the configuration and ignore our disable_id_mapping. > 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. I'm sorry, I don't understand what you trying to say here. Ben
