Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
From:   Benjamin Coddington <bcodding@redhat.com>
To:     Charles Hedrick <hedrick@rutgers.edu>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: bad info in NFS context
Date:   Thu, 21 Sep 2023 09:49:52 -0400
Message-ID: <650954F9-F67D-4F62-AD7B-4D16DF45E168@redhat.com>
In-Reply-To: <PH0PR14MB5493AB9814249EC5D66E635DAAF8A@PH0PR14MB5493.namprd14.prod.outlook.com>
References: <PH0PR14MB5493ED33985C95FEBE4DA808AAF9A@PH0PR14MB5493.namprd14.prod.outlook.com>
 <B7D023CD-2810-4BD6-8570-AB0C0EE95287@redhat.com>
 <PH0PR14MB5493AB9814249EC5D66E635DAAF8A@PH0PR14MB5493.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 21 Sep 2023, at 9:36, Charles Hedrick wrote:

> this is a web app. What is it about logging out and logging in that cle=
ars the cache? We'll need to make sure that the web app does it.

There's a very real performance tradeoff to perform NFS ACCESS operations=
 for every part of a tree walk vs. caching the results of previous ACCESS=
 calls.  There's not a sane way for the client to know when a user's grou=
p membership has changed in order to invalidate the cache, since the chan=
ge to the user's group membership is not reflected on the inodes themselv=
es.  So, the NFS client will keep caching the result of previous calls to=
 unchanged inodes until it notices that the process' oldest parent with t=
he same user/credential has a task start_time that is older than the curr=
ently cached entries.

TL;DR - you probably want to restart the web server.

Ben


> ________________________________
> From: Benjamin Coddington <bcodding@redhat.com>
> Sent: Thursday, September 21, 2023 6:44 AM
> To: Charles Hedrick <hedrick@rutgers.edu>
> Cc: linux-nfs@vger.kernel.org <linux-nfs@vger.kernel.org>
> Subject: Re: bad info in NFS context
>
> On 20 Sep 2023, at 19:14, Charles Hedrick wrote:
>
>> Ubuntu 22 client and server (5.15). Mount is 4.2, sec=3Dsys. I add a u=
ser to a group, but they can't see things that the group should be able t=
o see. /proc/net/rpc/auth.unix.gid/content shows that the nfs group cache=
 has their group membership. Doing a mount -o vers=3D4.1 works (4.1 to fo=
rce a different context). Other users that didn't try before work. It's b=
een several hours, and 4.2 still won't work for this user.
>>
>> What do I need to flush?
>>
>> Note that I'm using gssproxy on the server.
>
> Have the user log out and then back in again after the group change, th=
at
> should cause the user's NFS ACCESS cache to clear.
>
> Ben