Red Hat Bugzilla – Bug 307301
NFS v4 exports of /etc/fstab bind mounts invalid after boot
Last modified: 2008-09-22 11:00:24 EDT
Created about ten /exports 'mount --bind' entries in /etc/fstab,
then referenced them in /etc/exportfs. No errors after boot
but remote NFS clients cannot mount exports, receive
"permission denied" error. Problem corrected by manual
'exportfs -ua' then 'exportfs -a' cycle. Mounts work fine
Could you post an example of the export you're using here?
Also, could you run:
on the server before running "exportfs -ua;exportfs -a" and paste the output
from both here?
Also, are nfsv3 mounts refused in the same fashion?
It might be worthwhile to test the beta nfs-utils package. This change in
particular might have an effect here:
- fix race condition between mountd and exportfs (bz 239795)
Created attachment 207441 [details]
Created attachment 207451 [details]
Created attachment 207461 [details]
Created attachment 207471 [details]
Created attachment 207481 [details]
Problem affects only NFSv4 exports. Can mount parallel NFSv3
exports from same system successfully, then umount and V4
mounts continue to fail.
When will that beta go out to a release?
Actually it looks like the problem heals itself a few
minutes after the boot. Didn't notice this earlier.
I've not been able to reproduce this. I've set up a host with a single bind mount:
/dev/VolGroup00/export /foo ext3 defaults 0 0
/foo /export/foo auto bind 0 0
...and set up /etc/exports like this:
...after booting the server, I can mount /foo via nfs4 filesystem from another
host as soon as the NFS daemons come up. For reference:
I'm using kernel:
The kernel I'm using is available here:
...though I don't think there's much in it that would affect this.
Can you confirm whether this is still a problem with a more recent kernel and
nfs-utils package? If so, can you provide a way to reproduce this (preferably
with as simple a testcase as possible).
Don't have time for latest kernel and NFS right now as we need
to patch our kernel and are up to our necks in work. Maybe it's
fixed with all the recent NFS updates as NFSv4 certainly is a
WIP. Can probably look at it again in late Q3 or early Q4.
My only thought is that perhaps the number of mounts is a
factor, so maybe you could try it with a similar set?
This bug doesn't affect us much as we don't use NFSv4. Tripped
over it while trying out NFSv4 during the tracking down of evil
bug 396281 that turned out to be our real problem. The behavior
is wrong and the upstream developer agrees; I'm unimpressed by
RH refusing to fix it. This is why we have to patch our kernel.
Ok. I'm afraid I don't have the time at the moment to guess as to the source of
this problem. I've given this a go with my test rig and can't reproduce it. It
may have something to do with the number of filesystems, but at what point is
I'll need some detailed info on how to reproduce this in order to go further
with it. When you're able to provide it, then please post it here and flip this
back to being ASSIGNED and I'll have a look.
As a side note, you may want to take note of the comment that I posted to the
upstream BZ relating to bug 396281:
...there are good reasons why that patch is in place. While Bruce may think it's
a good idea to remove that function, I'm not entirely convinced.
I was never able to reproduce this and there has been no response in several months. Closing case. Please reopen if this is still an issue.