thanks. I can work with that info. Restarting the server isn't practical. This is a large-scale system serving hundreds of students. We generally keep it up uninterrupted for a whole semester. > So, the NFS client will keep caching the result of previous calls to unchanged inodes until it notices that the process' oldest parent with the same user/credential has a task start_time that is older than the currently cached entries. I trust you mean newer. This is jupyterhub, which likes to keep user processes around after logout and reattach when they login. But as long as we know what's going on, there's a way for a user to kill their processes manually. From: Benjamin Coddington <bcodding@xxxxxxxxxx> Sent: Thursday, September 21, 2023 9:49 AM To: Charles Hedrick <hedrick@xxxxxxxxxxx> Cc: linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> Subject: Re: bad info in NFS context 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 clears 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 group membership has changed in order to invalidate the cache, since the change to the user's group membership is not reflected on the inodes themselves. So, the NFS client will keep caching the result of previous calls to unchanged inodes until it notices that the process' oldest parent with the same user/credential has a task start_time that is older than the currently cached entries. TL;DR - you probably want to restart the web server. Ben > ________________________________ > From: Benjamin Coddington <bcodding@xxxxxxxxxx> > Sent: Thursday, September 21, 2023 6:44 AM > To: Charles Hedrick <hedrick@xxxxxxxxxxx> > Cc: linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> > 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=sys. I add a user to a group, but they can't see things that the group should be able to see. /proc/net/rpc/auth.unix.gid/content shows that the nfs group cache has their group membership. Doing a mount -o vers=4.1 works (4.1 to force a different context). Other users that didn't try before work. It's been 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, that > should cause the user's NFS ACCESS cache to clear. > > Ben
