Turns out I'd overlooked -f for exportfs, so a simple `exportfs -rf` is enough to flush the data I want it to.
Apologies! --- Matthew Ward e: [email protected] On Wednesday, 9 November 2011 at 13:54, Matthew Ward wrote: > I'm having a problem with file permissions being cached via NFS that > disallows access to newly created directories and files from a secondary > group-user until the NFS daemon is restarted when the users are managed by > LDAP. > > I have a generic user `developers` that belongs to many primary groups of > individual users. If I create a new user on my LDAP server (which is also my > NFS server) and add the `developers` user to the new primary group I can see > it on the client straight away (due to my caching setup with SSSD). However, > if I create a new directory for that new user, I get permission denied on the > client when trying to access that directory over NFS as the `developers` > user. If I restart the NFS server, I can then access it fine with that user. > > I'm managing LDAP on the client through SSSD, and any resetting/restarting of > that service doesn't make a difference (and the `developers` group is shown > as being in the new user's group immediately anyway), so the fact that the > NFS daemon restart is the only thing that helps makes me think there's a > cache somewhere with NFS that's denying the existence of the `developers` > membership of the new group. > > I've got actimeo=3 in my mount options and have tried mounting with noac as > well to no avail. It appears to be a server-side issue, as even un-mounting > and re-mounting the share doesn't make a difference (and I wouldn't want to > have to do this every time anyway). > > I always need the `developers` group to access the new user's directory > pretty much immediately, so can't afford to wait for the timeout (which seems > to be a long time, at least 15 minutes). Is there a way to update whatever > this is without being forced to restart the NFS daemon on every user addition? > > --- > Matthew Ward > e: [email protected] (mailto:[email protected]) > > > >
