Bug 127521 - It's not possible to export (NFS) directories to a single host only
Summary: It's not possible to export (NFS) directories to a single host only
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
: 135109 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-09 11:25 UTC by JM
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-06 11:52:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to linux/net/sunrpc/svcauth_unix.c (2.91 KB, patch)
2004-10-20 14:22 UTC, Jan "Yenya" Kasprzak
no flags Details | Diff
proposed upstream patch (2.00 KB, patch)
2004-11-01 09:38 UTC, Steve Dickson
no flags Details | Diff

Description JM 2004-07-09 11:25:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040706 Firefox/0.9.1

Description of problem:
It's not possible to export a directory to a single host only. For
example, my /etc/exports on the system "bar" looks like this

/test       foo(rw,sync)

which should export the directory /test on the system "bar" to the
system "foo". I restart the nfsd (service nfs restart) on the system
"bar" and then I try to mount the directory on the system "foo", but
it doesn't work, the mount request hangs and never comes back. It
works when I export the directory to all systems (then I can mount the
directory on "foo") but not when I choose only "foo" in the export
statement. There is no firewall in place (iptables are disabled) the
/etc/hosts.allows contains a ALL:ALL and I even did a exportfs -ra
before and after the nfsd restart. The same configuration worked
without any problems with FC1 but since FC2 it's broken. The key is
the FC2 NFS-Server because even an old RH 7.3 can't mount the
directory when I add the RH 7.3 as host to the /etc/exports file.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-22, kernel-2.6.6-1.435.2.3

How reproducible:
Always

Steps to Reproduce:
1. Export "/test       foo(rw,sync)" on system bar
2. "service nfs restart" on system bar
3. "mount bar:/test /test" on system foo
    

Actual Results:  mount hangs on system foo or sometimes I get a
"permission denied" (which is not correct, the permissions are okay)


Expected Results:  mount should work (like it did on FC1)


Additional info:

I added the lines

nfsd /proc/fs/nfsd           nfsd    defaults        0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs defaults     0 0

to the /etc/fstab but it doesn't help.

I get only one line in /var/log/message on the NFS-Server:

Jul  9 12:49:43 bar rpc.mountd: authenticated mount request from
foo:818 for /test (/test)

Comment 1 Steve Dickson 2004-07-12 18:00:57 UTC
Try added fsid=0 to the export line

Comment 2 JM 2004-07-13 02:11:30 UTC
Nope, a fsid=0 changed nothing but I must add something to my first 
report, it's necessary to export the directory to a single host AND 
to an entire network at the same time to reproduce the bug, so the 
line in /etc/exports must look like this (for example)

/test       foo(rw,sync) 192.168.1.0/255.255.255.0(ro,sync)

If you export the directory ONLY to a single host or ONLY to an 
entire network, then it works, so the important part is that a single 
host AND an entire network is involed in the export.


Comment 3 JM 2004-08-16 10:54:40 UTC
It's now kernel 2.6.7-1.494.2.2 and it's still not possible to mount a
directory from a FC2 system. This way FC2 is completely useless as
Fileserver.

Comment 4 JM 2004-08-17 11:13:42 UTC
I found a workaround. This /etc/exports doesn't work:

/test       192.168.1.10(rw,sync) 192.168.1.0/255.255.255.0(ro,sync)

but this works:

/test       192.168.1.10(rw,sync) 192.168.1.0/24(ro,sync)

(192.168.1.0/255.255.255.0 or 192.168.1.0/24 is the same subnet)

It looks like the Netmask is the problem, but ONLY when an additional
single host is specified. To me this looks like a bug in the kernel
(but I'm not an expert in this :)) (btw. I tried the same with the
vanilla 2.6.8.1 kernel and got the same problem).

Comment 5 Jan "Yenya" Kasprzak 2004-10-19 12:06:35 UTC
I have found a similar problem - reproducible both on FC2 and
FC3test3. I think there is something wrong with handling NFS wildcard
exports. Details are in the following mail to LKML:
http://lkml.org/lkml/2004/10/15/95


Comment 6 JM 2004-10-19 12:49:57 UTC
Yes, looks like it is the same bug, it would be nice if this could be
fixed before "FC3 final" :). I don't know if this bug is only related
to Fedora Core/Kernel 2.6 and RH/Kernel 2.6 or if other distributions
with Kernel 2.6 have similar problems?

Comment 7 Jan "Yenya" Kasprzak 2004-10-20 14:22:19 UTC
Created attachment 105511 [details]
Patch to linux/net/sunrpc/svcauth_unix.c

This is probably similar to bug 135109. Can you compile the kernel with the
attached patch? See also the comment in patch or my post to LKML and
nfs@lists.sf.net from today.

Comment 8 Steve Dickson 2004-11-01 09:35:12 UTC
*** Bug 135109 has been marked as a duplicate of this bug. ***

Comment 9 Steve Dickson 2004-11-01 09:38:03 UTC
Created attachment 106005 [details]
proposed upstream patch

See http://lkml.org/lkml/2004/10/26/127 for details.

Comment 10 Matthew Miller 2005-04-26 16:41:05 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 11 JM 2005-09-06 11:33:39 UTC
Looks like it works in FC3 and FC4.


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