Bug 135109 - Nfs mount problem whith complex /etc/exports
Nfs mount problem whith complex /etc/exports
Status: CLOSED DUPLICATE of bug 127521
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
2
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-08 14:14 EDT by Martin Goik
Modified: 2008-05-09 13:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:06:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to linux/net/sunrpc/svcauth_unix.c (2.91 KB, patch)
2004-10-20 10:17 EDT, Jan "Yenya" Kasprzak
no flags Details | Diff

  None (edit)
Description Martin Goik 2004-10-08 14:14:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803

Description of problem:
I was unable to mount an exported NFS directory.

On the Server (hostname = raid) I used the following /etc/exports:

/ma   192.168.1.0/255.255.255.0(rw,no_root_squash)   
192.168.6.126/255.255.255.255(ro,no_root_squash)
192.168.6.162/255.255.255.255(ro,no_root_squash)

/stud           192.168.0.0/255.255.0.0(rw,no_root_squash)

So the /ma directory is exported to the whole class A subnet
192.168.1.0 and in addition to the 2 distinct clients 192.168.6.126
and 192.168.6.162 which will subsequently be called "exceptions".
/stud is exported to the whole class B net 192.168.0.0 .

Now an attempt to mount /stud from e.g. client 192.168.6.126 fails.
After some time the client's /var/log/messages shows a "NFS server
raid not responding, still trying" line. In the server's
/var/log/messages I can see :
raid rpc.mountd: authenticated mount request from
r133-001.pool.mintern.mi.hdm-stuttgart.de:898 for /stud (/stud)

If I change the client's IP adress to any value in the same subnet but
distinct from the two "exception" adresses in the /stud rule of
/etc/exports I have no problem at all. And finally, if I remove the
two exception rules in /etc/exports, i.e.:
/ma   192.168.1.0/255.255.255.0(rw,no_root_squash)

In this case I have no mounting problem at all.

I tried older and newer Versions of nfs-utils (FC1, FC3-test2,
FC-development) which all show the same behaviour.

BTW, non-technical issue: I recently read that it is not a good idea
to call a directory /stud due to its meaning as a "four letter word".
At our site this is just an abbreviation for the german word /student,
my apologies.


Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-22, kernel-smp-2.6.8-1.521

How reproducible:
Always

Steps to Reproduce:
1.Create a corresponding /etc/exports
2.Try to mount from a client with "exception rule IP"

    

Additional info:
Comment 1 Martin Goik 2004-10-08 14:18:30 EDT
Sorry for a small error: 

The line "distinct from the two "exception" adresses in the /stud rule
of" should be replaced by "distinct from the two "exception" adresses
in the /ma rule of"
Comment 2 Jan "Yenya" Kasprzak 2004-10-14 11:31:29 EDT
What happens if you add "no_subtree_check" option into all rules in
/etc/exports? I may have a similar problem. It seems that 2.6 kernel
NFS sometimes does not work correctly when you export two subdirs of
the same filesystem (are your /stud and /ma on the same FS?). The
no_subtree_check goes around this problem, but then you export
something more than you have originally intended to.
Comment 3 Jan "Yenya" Kasprzak 2004-10-20 10:10:23 EDT
Does the attached patch fix this to you? For description see my post
to LKML and nfs@lists.sf.net from today (or to the patch itself).
Comment 4 Jan "Yenya" Kasprzak 2004-10-20 10:17:06 EDT
Created attachment 105509 [details]
Patch to linux/net/sunrpc/svcauth_unix.c
Comment 5 JM 2004-10-20 13:05:46 EDT
This is similar to bug 127521
Comment 6 Martin Goik 2004-10-22 02:22:37 EDT
Refering to comment no. 3 the patch did it's job i.e. I am able to
mount the share in question. Will this patch find its way into the
next updated FC2 Kernel?
Comment 7 Steve Dickson 2004-11-01 04:35:09 EST

*** This bug has been marked as a duplicate of 127521 ***
Comment 8 Red Hat Bugzilla 2006-02-21 14:06:14 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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