Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Alan Maxwell" <amaxwell@fedex.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: nfsv4 client idmapper issue
Date:   Thu, 22 Sep 2022 07:42:18 -0400
Message-ID: <46FAEBBD-50BC-464B-A983-1DC2232795C5@redhat.com>
In-Reply-To: <DS0PR12MB6486987EC76AD88C7A80D229C84F9@DS0PR12MB6486.namprd12.prod.outlook.com>
References: <DS0PR12MB6486987EC76AD88C7A80D229C84F9@DS0PR12MB6486.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

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.

What the server is signaling by sending back NFS4ERR_BADOWNER is that it
actually /is/ doing id mapping.

Why doesn't OneFS just set the value when told "Do not send names"?

Ben