Bug 884304

Summary: nfs4 does not parse netgroups
Product: [Fedora] Fedora Reporter: Gregory Lee Bartholomew <gregory.lee.bartholomew>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: 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 08:35:55 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
wireshark trace of NFS4 export with /etc/netgroup containing DNS name -- successful
none
wireshark trace of NFS4 export with /etc/netgroup containing IP address -- failed none

Description Gregory Lee Bartholomew 2012-12-05 16:29:18 EST
Description of problem:

Using a netgroup for the clientspec field in /etc/exports instead of an IP address fails.

I.E., this line works:

/export/test -fsid=1,rw,no_root_squash 1.2.3.2/32

But this line does not:

/export/test -fsid=1,rw,no_root_squash @test

Version-Release number of selected component (if applicable):

nfs-utils-1.2.6-6.fc17.x86_64

How reproducible:

Always.

Steps to Reproduce:

# I've substituted fake IP address for the server and client.

On NFS4 Server:

1. start with a minimal install of fedora 17
2. yum -y install nfs-utils
3. mkdir /test; mkdir -p /export/test; mount -o bind /test /export/test
4. 

# 1.2.3.2 = IP Address of NFS4 Client

cat <<- "END" > /etc/netgroup
test (1.2.3.2/32, , )
END

cat <<- "END" > /etc/exports
/export -fsid=0,ro,no_root_squash 1.2.3.0/24
/export/test -fsid=1,rw,no_root_squash @test
END

5. systemctl start nfs-server.service; systemctl stop iptables.service

On NFS4 Client:

# 1.2.3.1 = IP Address of NFS4 Server

1. mount -t nfs4 1.2.3.1:/test /test
2. 

[root@client /]# touch /test/testing.txt
touch: cannot touch `/test/testing.txt': Read-only file system
[root@client /]# df -h | grep test
1.2.3.1://test  3.0G  1.1G  1.8G  36% /test
[root@client /]# cat /proc/mounts | grep test
1.2.3.1://test /test nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.2,local_lock=none,addr=1.2.3.1 0 0

# note the double forward-slash in the output of previous two commands

3. umount /test

# Changing "@test" to "1.2.3.2/32" in /etc/exports fixes the problem.

On NFS4 Server:

1. sed -i 's/\@test/1.2.3.2\/32/' /etc/exports
2. exportfs -rv

On NFS4 Client:

1. mount -t nfs4 1.2.3.1:/test /test
2. 

[root@client /]# touch /test/testing.txt
[root@eb2024-01 /]# df -h | grep test
1.2.3.1:/test  3.0G  1.1G  1.8G  36% /test
[root@client /]# cat /proc/mounts | grep test
1.2.3.1:/test /test nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.2,local_lock=none,addr=1.2.3.1 0 0

# note that there is only one forward-slash in the output of the previous two commands this time

NFS4 Server Specs:

uname -r
3.6.8-2.fc17.x86_64

rpm -q nfs-utils
nfs-utils-1.2.6-6.fc17.x86_64

NFS4 Client Specs:

uname -r
3.6.7-4.fc16.x86_64

rpm -q nfs-utils
nfs-utils-1.2.5-8.fc16.x86_64
  
Actual results:

nfs4 exports do not work with netgroups

Expected results:

nfs4 exports should work with netgroups

Additional info:
Comment 1 Gregory Lee Bartholomew 2013-05-06 16:43:19 EDT
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@vger.kernel.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.
Comment 2 J. Bruce Fields 2013-05-07 10:44:50 EDT
I'm not clear--have you verified whether the patch you reference from Chuck Lever fixes the problem?
Comment 3 Gregory Lee Bartholomew 2013-05-07 10:54:06 EDT
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.
Comment 4 Steve Dickson 2013-05-07 12:48:09 EDT
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.
Comment 5 Gregory Lee Bartholomew 2013-05-07 17:11:25 EDT
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
Comment 6 Steve Dickson 2013-05-08 10:39:57 EDT
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.
Comment 7 Gregory Lee Bartholomew 2013-05-08 12:07:03 EDT
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 ~]#
Comment 8 Gregory Lee Bartholomew 2013-05-08 12:08:33 EDT
Created attachment 745313 [details]
wireshark trace of NFS4 export with /etc/netgroup containing DNS name -- successful
Comment 9 Gregory Lee Bartholomew 2013-05-08 12:09:10 EDT
Created attachment 745314 [details]
wireshark trace of NFS4 export with /etc/netgroup containing IP address -- failed
Comment 10 Steve Dickson 2013-05-08 13:54:41 EDT
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...
Comment 11 J. Bruce Fields 2013-05-08 14:47:25 EDT
(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.
Comment 12 Fedora End Of Life 2013-12-21 04:39:23 EST
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.
Comment 13 Fedora End Of Life 2014-02-05 08:35:58 EST
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.