Subject: Re: very weird NFS/VND error during "make depend" of kernel....
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 07/01/2001 15:20:55
On Sat, Jun 30, 2001 at 08:19:35PM -0400, Greg A. Woods wrote:
> [ On Thursday, June 28, 2001 at 19:19:49 (+0200), Manuel Bouyer wrote: ]
> > Subject: Re: very weird NFS/VND error during "make depend" of kernel....
> > I think this is the same thing: you have to check something when
> > a client comes it anyway (it may be allowed to access one mount point
> > but not one other).
> Indeed -- but if some state is maintained on the server side (state
> that's got to be there anyway for showmount to work, IIUC) then that
> would seem to be the best choice for such an authorisation check.
> > I actually like to be able to deny access to a client on the fly, without
> > need to umount the filesystem on the client.
> I agree that being able to forcibly deny access to a client with an
> existing mount is an important feature.
> However the current "implementation" is enirely the wrong way to go
> about authorisation. What ends up happening is that suddenly individual
> file accesses on the client side get strange errors, such as EIO of all
> things! (and EPERM only for new open() attempts) This is not right.
> (and it's very very annoying if you're running busy clients, such as
> with 'make build's too!)
The current isn't completely wrong. It's just that we need to stop the
nfsd server while mountd is working (and this is what I do by hand to avoid
this when I change the export list on the server:
About the EIO instead of something more sensible, it's possible that the
problem is on the client side, but I don't know NFS well enouth to
tell for sure.
Manuel Bouyer <firstname.lastname@example.org>