Red Hat Bugzilla – Bug 127521
It's not possible to export (NFS) directories to a single host only
Last modified: 2007-11-30 17:10:45 EST
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)
Try added fsid=0 to the export line
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.
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.
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).
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
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?
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.
*** Bug 135109 has been marked as a duplicate of this bug. ***
Created attachment 106005 [details] proposed upstream patch See http://lkml.org/lkml/2004/10/26/127 for details.
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.
Looks like it works in FC3 and FC4.