Bug 307301 - NFS v4 exports of /etc/fstab bind mounts invalid after boot
NFS v4 exports of /etc/fstab bind mounts invalid after boot
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils (Show other bugs)
4.5
All Linux
low Severity low
: ---
: ---
Assigned To: Jeff Layton
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-26 12:25 EDT by starlight
Modified: 2008-09-22 11:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-22 11:00:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
exports_server (2.61 KB, text/plain)
2007-09-26 16:24 EDT, starlight
no flags Details
fstab_server (2.01 KB, text/plain)
2007-09-26 16:24 EDT, starlight
no flags Details
fstab_client (1.71 KB, text/plain)
2007-09-26 16:25 EDT, starlight
no flags Details
exportfs_v (2.51 KB, text/plain)
2007-09-26 16:25 EDT, starlight
no flags Details
showmount_e (1.11 KB, text/plain)
2007-09-26 16:26 EDT, starlight
no flags Details

  None (edit)
Description starlight 2007-09-26 12:25:59 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
after this.

kernel-smp-2.6.9-55.EL
nfs-utils-1.0.6-80.EL4
Comment 1 Jeff Layton 2007-09-26 16:01:47 EDT
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)
Comment 2 starlight 2007-09-26 16:24:30 EDT
Created attachment 207441 [details]
exports_server
Comment 3 starlight 2007-09-26 16:24:56 EDT
Created attachment 207451 [details]
fstab_server
Comment 4 starlight 2007-09-26 16:25:16 EDT
Created attachment 207461 [details]
fstab_client
Comment 5 starlight 2007-09-26 16:25:40 EDT
Created attachment 207471 [details]
exportfs_v
Comment 6 starlight 2007-09-26 16:26:15 EDT
Created attachment 207481 [details]
showmount_e
Comment 7 starlight 2007-09-26 16:27:54 EDT
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?
Comment 8 starlight 2007-09-26 16:36:16 EDT
Actually it looks like the problem heals itself a few
minutes after the boot.  Didn't notice this earlier.
Comment 9 Jeff Layton 2008-04-23 14:30:06 EDT
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).
Comment 10 starlight 2008-04-23 14:56:40 EDT
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.
Comment 11 Jeff Layton 2008-04-23 15:49:16 EDT
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.
Comment 12 Jeff Layton 2008-04-23 16:51:28 EDT
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.
Comment 13 Jeff Layton 2008-09-22 11:00:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.