NFS occassionally gives "permission" denied in the middle of a large transfer

[Dan Nelson]

In the last episode (Apr 26), Tillman Hodgson said:
> On Mon, Apr 26, 2004 at 01:47:10PM -0500, Dan Nelson wrote:
> > In the last episode (Apr 26), Tillman Hodgson said:
> > > On Mon, Apr 26, 2004 at 01:37:17PM -0500, Dan Nelson wrote:
> > > > The only time I've seen incorrect permission denied messages is
> > > > when mountd is refreshing the exports list.  It's not atomic,
> > > > so there's a small window where the old exports have been
> > > > deleted but the new ones aren't in place yet.
> > > 
> > > Is there anything in the default weekly cron jobs that would do
> > > something like that on the file server?
> > 
> > I don't think so.  Mounting or dismounting local (not NFS)
> > filesystems might do it, but I'm not sure.
> 
> Including local filesystems that aren't exported?
> 
> If so, that's interesting because I do that in my weekly periodic
> cron job. It's a simple script that umounts a backup partition,
> newfs's it, dumps a local copy of /home over to it, and then
> re-mounts it (for easy user-accessible near-line backup storage that
> doesn't require going to tape for the "real" backup).

That's probably it, then.  /sbin/mount has code that sends SIGHUP to
mountd on any mount operation.  Which implies that any manual mount
request, including NFS mounts would, cause the problem.  Amd calls the
mount syscall directly, bypassing /sbin/mount.

Ideally, mountd would be able to compare the current and new export
settings and only update the ones that changed, or have a way to create
a new mountlist and ask the kernel to replace the old one in a single
atomic operation.

-- 
	Dan Nelson
	dnelson at allantgroup.com