Bug 884304
| Summary: | nfs4 does not parse netgroups | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gregory Lee Bartholomew <gregory.lee.bartholomew> | ||||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 18 | CC: | bfields, jlayton, steved | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-02-05 13:35:55 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Gregory Lee Bartholomew
2012-12-05 21:29:18 UTC
Found that this bug persists in Fedora 18, nfs-utils-1.2.7-6.fc18.x86_64 (server and client). Also found that the "official place to report bugs or make feature requests is linux-nfs.org" (http://linux-nfs.org/wiki/index.php/Reporting_bugs) so I'm guessing that that is why no one has responded here. In case someone else finds this report though, I found a reference to this problem here: http://article.gmane.org/gmane.linux.nfs/34124/match=netgroup The above link hints that the broken code only borks when an IP address is used in the /etc/netgroup file. Using a DNS name and defining that name in /etc/hosts has successfully worked around the issue for me. As I have found a workaround, this bug may be closed. The code probably should be changed to work with IP addresses though or else a note that IP address do not work should be made in the exports(5) man page. P.S. Just noticed that both the exports(5) and exportfs(8) man pages mention a netgroup(5) man page that does not seem to exist in Fedora 18. I'm not clear--have you verified whether the patch you reference from Chuck Lever fixes the problem? No. I don't know what that patch does. All I got from it was that the problem lye in the use of an IP address in /etc/netgroup as opposed to a DNS name. Because the subnet that I am working with is small, I can work around the issue by using DNS names. I would expect that there are people out there who would need to specify whole netmasks in /etc/netgroup though. This build has Chuck's patch in it
http://koji.fedoraproject.org/koji/buildinfo?buildID=413779
If possible please down load the package to see if the problem goes a way.
That build did not fix the problem. Here are the commands that I ran on the server (vm-09) and client (vm-10). Server: [root@vm-09 ~]# ./manual-export.sh test exporting @test:/fs-0/export/test [root@vm-09 ~]# exportfs -v /fs-0/export 146.163.150.0/24(ro,wdelay,no_root_squash,no_subtree_check,fsid=0,sec=sys,ro,no_root_squash,no_all_squash) /fs-0/export/test @test(rw,wdelay,no_root_squash,no_subtree_check,fsid=1,sec=sys,rw,no_root_squash,no_all_squash) [root@vm-09 ~]# cat /etc/netgroup test (146.163.150.0/24, , ) Client: [root@vm-10 ~]# mount -t nfs4 data.cs.siue.edu:/test /mnt [root@vm-10 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 489M 0 489M 0% /dev tmpfs 498M 0 498M 0% /dev/shm tmpfs 498M 1.3M 497M 1% /run tmpfs 498M 0 498M 0% /sys/fs/cgroup /dev/vda3 5.7G 1.3G 4.2G 24% / tmpfs 498M 0 498M 0% /tmp data.cs.siue.edu://test 1023M 259M 765M 26% /mnt [root@vm-10 ~]# ls /mnt [root@vm-10 ~]# touch /mnt/testing touch: cannot touch ‘/mnt/testing’: Read-only file system [root@vm-10 ~]# umount /mnt Server: [root@vm-09 ~]# vi /etc/netgroup [root@vm-09 ~]# cat /etc/netgroup test (vm-10.cs.siue.edu, , ) [root@vm-09 ~]# ./manual-unexport.sh test unexporting @test:/fs-0/export/test [root@vm-09 ~]# ./manual-export.sh test exporting @test:/fs-0/export/test Client: [root@vm-10 ~]# mount -t nfs4 data.cs.siue.edu:/test /mnt [root@vm-10 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 489M 0 489M 0% /dev tmpfs 498M 0 498M 0% /dev/shm tmpfs 498M 1.3M 497M 1% /run tmpfs 498M 0 498M 0% /sys/fs/cgroup /dev/vda3 5.7G 1.3G 4.2G 24% / tmpfs 498M 0 498M 0% /tmp data.cs.siue.edu:/test 1023M 259M 765M 26% /mnt [root@vm-10 ~]# touch /mnt/testing [root@vm-10 ~]# ls /mnt testing Server: [root@vm-09 ~]# rpm -q nfs-utils nfs-utils-1.2.8-0.fc19.x86_64 Client: [root@vm-10 ~]# rpm -q nfs-utils nfs-utils-1.2.8-0.fc19.x86_64 Summary: Using the DNS name "vm-10.cs.siue.edu" in /etc/netgroup works, but using the ip/netmask "146.163.150.0/24" does not. This bug persists in nfs-utils-1.2.8-0.fc19.x86_64 Would be possible to get a network trace of the failure and of the successful run? Something similar to:
yum install wireshark
One the server: tshark -w /tmp/success.pcap host <client>
tshark -w /tmp/failure.pcap host <client>
Then please bzip2 them and post them to this bz.
Here are the commands that I ran and the results as attachments. Server: [root@vm-09 ~]# date; tshark -w /tmp/success.pcap host vm-10.cs.siue.edu & Wed May 8 10:45:15 CDT 2013 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 [1] 1496 [root@vm-09 ~]# export MONITOR=$! [root@vm-09 ~]# exportfs -v [root@vm-09 ~]# exportfs -v -o fsid=0,ro,no_root_squash 146.163.150.0/24:/export exporting 146.163.150.0/24:/export [root@vm-09 ~]# exportfs -v -o fsid=1,rw,no_root_squash @test:/export/test exporting @test:/export/test [root@vm-09 ~]# cat /etc/netgroup test (vm-10.cs.siue.edu, , ) [root@vm-09 ~]# exportfs -v /export 146.163.150.0/24(ro,wdelay,no_root_squash,no_subtree_check,fsid=0,sec=sys,ro,no_root_squash,no_all_squash) /export/test @test(rw,wdelay,no_root_squash,no_subtree_check,fsid=1,sec=sys,rw,no_root_squash,no_all_squash) [root@vm-09 ~]# Client: [root@vm-10 ~]# date Wed May 8 10:45:21 CDT 2013 [root@vm-10 ~]# grep " /mnt " /proc/mounts [root@vm-10 ~]# mount -t nfs4 vm-09.cs.siue.edu:/test /mnt [root@vm-10 ~]# grep " /mnt " /proc/mounts vm-09.cs.siue.edu:/test /mnt nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=146.163.150.240,local_lock=none,addr=146.163.150.239 0 0 [root@vm-10 ~]# ls /mnt [root@vm-10 ~]# touch /mnt/test.success [root@vm-10 ~]# ls /mnt test.success [root@vm-10 ~]# umount /mnt [root@vm-10 ~]# Server: [root@vm-09 ~]# date Wed May 8 10:45:30 CDT 2013 [root@vm-09 ~]# kill $MONITOR [1]+ Done tshark -w /tmp/success.pcap host vm-10.cs.siue.edu [root@vm-09 ~]# cat /etc/netgroup test (vm-10.cs.siue.edu, , ) [root@vm-09 ~]# sed -i 's/vm-10.cs.siue.edu/146.163.150.240/' /etc/netgroup [root@vm-09 ~]# cat /etc/netgroup test (146.163.150.240, , ) [root@vm-09 ~]# date; tshark -w /tmp/failure.pcap host vm-10.cs.siue.edu & Wed May 8 10:45:31 CDT 2013 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 [1] 1542 [root@vm-09 ~]# export MONITOR=$! [root@vm-09 ~]# exportfs -rv [root@vm-09 ~]# exportfs -v -o fsid=0,ro,no_root_squash 146.163.150.0/24:/export exporting 146.163.150.0/24:/export [root@vm-09 ~]# exportfs -v -o fsid=1,rw,no_root_squash @test:/export/test exporting @test:/export/test [root@vm-09 ~]# exportfs -v /export 146.163.150.0/24(ro,wdelay,no_root_squash,no_subtree_check,fsid=0,sec=sys,ro,no_root_squash,no_all_squash) /export/test @test(rw,wdelay,no_root_squash,no_subtree_check,fsid=1,sec=sys,rw,no_root_squash,no_all_squash) [root@vm-09 ~]# Client: [root@vm-10 ~]# date Wed May 8 10:45:39 CDT 2013 [root@vm-10 ~]# grep " /mnt " /proc/mounts [root@vm-10 ~]# mount -t nfs4 vm-09.cs.siue.edu:/test /mnt [root@vm-10 ~]# grep " /mnt " /proc/mounts vm-09.cs.siue.edu://test /mnt nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=146.163.150.240,local_lock=none,addr=146.163.150.239 0 0 [root@vm-10 ~]# ls /mnt [root@vm-10 ~]# touch /mnt/test.failure touch: cannot touch ‘/mnt/test.failure’: Read-only file system [root@vm-10 ~]# ls /mnt [root@vm-10 ~]# umount /mnt [root@vm-10 ~]# Server: [root@vm-09 ~]# date Wed May 8 10:45:47 CDT 2013 [root@vm-09 ~]# kill $MONITOR [root@vm-09 ~]# Created attachment 745313 [details]
wireshark trace of NFS4 export with /etc/netgroup containing DNS name -- successful
Created attachment 745314 [details]
wireshark trace of NFS4 export with /etc/netgroup containing IP address -- failed
Its odd that nfserr_rofs error is being returned from the server... when its clearly not that... Bruce, any idea??? I'll try to reproduce this locally... (In reply to comment #10) > Its odd that nfserr_rofs error is being returned from the server... when its > clearly not that... Bruce, any idea??? If it fails to match the client against @test it instead matches it against 146.163.150.0/24, and the /export export, which is read-only. (Note e don't recommend using fsid=0. On rhel6 if you just export normally without specifying any fsid=0 export, everything will work over v4 as it does with v2 and v3.) That still doesn't explain why the client isn't matching against @test. This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |