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 after this. kernel-smp-2.6.9-55.EL nfs-utils-1.0.6-80.EL4
Could you post an example of the export you're using here? Also, could you run: exportfs -v ...and... showmount -e 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] exports_server
Created attachment 207451 [details] fstab_server
Created attachment 207461 [details] fstab_client
Created attachment 207471 [details] exportfs_v
Created attachment 207481 [details] showmount_e
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: /foo *(rw,sync,no_root_squash,no_subtree_check) /export *(rw,sync,insecure,fsid=0,no_root_squash,no_subtree_check,crossmnt) /export/foo *(rw,sync,insecure,no_root_squash,no_subtree_check) ...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: kernel-smp-2.6.9-69.EL.jtltest.36 nfs-utils-1.0.6-84.EL4 The kernel I'm using is available here: http://people.redhat.com/jlayton ...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 the breakover? 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: http://bugzilla.kernel.org/show_bug.cgi?id=9454 ...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.