Bug 845714

Summary: Wrong NFS export from FC16 server mounted to FC17 client
Product: [Fedora] Fedora Reporter: Roger Odle <fedora-bugs>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: bfields, jlayton, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-09 06:43:44 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
servver config file - /etc/sysconfig/nfs none

Description Roger Odle 2012-08-03 23:07:01 EDT
Created attachment 602214 [details]
servver config file - /etc/sysconfig/nfs

Description of problem:
When mounting directory from Feodra 16 server on Fedora 17 client, wrong exported directory is mounted

* Have /home mounted as separate partition on harddrive
* Have website development area on home partition at /home/site of server
* Attempting to upgrade laptop so need to mount /home/site to transfer files
* Had trouble mounting on client
  - found fsid=0 issue on web search and added that
  - would not mount at all then noticed that system-config-nfs added empty mount point (mp=) to /etc/exports file, removed this from /home/site then client could complete mount
* Observed that content of mount point on client (/mnt/site) was same as content of client directory that appeared in exports file earlier.

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

ON SERVER:
# yum list installed | grep nfs
libnfsidmap.x86_64                      0.24-7.fc16                  @updates   
nfs-utils.x86_64                        1:1.2.5-8.fc16               @updates   
nfs4-acl-tools.x86_64                   0.3.3-7.fc15                 @Everything
nfswatch.x86_64                         4.99.11-2.fc15               @Everything
system-config-nfs.noarch                1.3.51-2.fc15                @Everything
system-config-nfs-docs.noarch           1.0.9-2.fc15                 @Everything

# yum list installed | grep kernel
abrt-addon-kerneloops.x86_64            2.0.7-3.fc16                 @updates   
kernel.x86_64                           3.4.2-1.fc16                 @updates   
kernel.x86_64                           3.4.4-4.fc16                 @updates   
kernel.x86_64                           3.4.6-1.fc16                 @updates   
kernel-devel.x86_64                     3.4.2-1.fc16                 @updates   
kernel-devel.x86_64                     3.4.4-4.fc16                 @updates   
kernel-devel.x86_64                     3.4.6-1.fc16                 @updates   
kernel-headers.x86_64                   3.4.6-1.fc16                 @updates   
libreport-plugin-kerneloops.x86_64      2.0.10-3.fc16                @updates   

ON CLIENT:
libnfsidmap.x86_64                    0.25-3.fc17                @updates       
nfs-utils.x86_64                      1:1.2.6-3.fc17             @updates       
abrt-addon-kerneloops.x86_64          2.0.10-4.fc17              @updates       
kernel.x86_64                         3.4.4-3.fc17               @updates       
kernel.x86_64                         3.4.5-2.fc17               @updates       
kernel.x86_64                         3.4.6-2.fc17               @updates       
kernel-devel.x86_64                   3.4.4-3.fc17               @updates       
kernel-devel.x86_64                   3.4.5-2.fc17               @updates       
kernel-devel.x86_64                   3.4.6-2.fc17               @updates       
kernel-headers.x86_64                 3.4.6-2.fc17               @updates       
kernel-tools.x86_64                   3.4.6-2.fc17               @updates       
libreport-plugin-kerneloops.x86_64    2.0.10-3.fc17              @anaconda-0    

How reproducible:
Attempted three times with same result every time.

Steps to Reproduce:
1. Modify /etc/exports on server then execute exports -r
2. Restart NFS server to reload exports (service nfs-server restart)
3. Mount directory on client (mount -t nfs 192.168.3.98:/home/site /mnt/site
  
Actual results:
Server directory /home/some_user is mounted to /mnt/site instead of /home/site

Expected results:
/home/site of server to be mounted to /mnt/site

Additional info:


========================================================
exports file on server: (some_user replaces real account name)
========================================================

/home/some_user             192.168.122.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,fsid=0,no_root_squash)  192.168.3.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,fsid=0,no_root_squash)  192.168.2.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,mp=/mnt/some_user,fsid=0,no_root_squash)
/home/site               *(rw,insecure,sync,no_wdelay,fsid=0,no_root_squash)

========================================================
Attempt to mount directory /home/site results in mounting /home/some_user instead
========================================================

mount -v -t nfs 192.168.3.98:/home/site /mnt/site
mount.nfs: timeout set for Fri Aug  3 19:14:04 2012
mount.nfs: trying text-based options 'vers=4,addr=192.168.3.98,clientaddr=192.168.3.96'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.3.98'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.3.98 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.3.98 prog 100005 vers 3 prot UDP port 20048

========================================================
Attempt to mount /home/some_user succeeds but is this chance?
========================================================

mount -v -t nfs 192.168.3.98:/home/some_user /mnt/some_user

mount.nfs: timeout set for Fri Aug  3 19:19:46 2012
mount.nfs: trying text-based options 'vers=4,addr=192.168.3.98,clientaddr=192.168.3.96'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.3.98'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.3.98 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.3.98 prog 100005 vers 3 prot UDP port 20048
Comment 1 Steve Dickson 2012-11-08 10:22:12 EST
> 
> /home/some_user            
> 192.168.122.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,fsid=0,
> no_root_squash) 
> 192.168.3.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,fsid=0,
> no_root_squash) 
> 192.168.2.0/255.255.255.0(rw,insecure,sync,no_wdelay,insecure_locks,mp=/mnt/
> some_user,fsid=0,no_root_squash)
> /home/site               *(rw,insecure,sync,no_wdelay,fsid=0,no_root_squash)

I'm thinking the problem is that you have two fsid=0 so the second one is defining a different root that is expected. What happens when you don't set fsid=0?
Comment 2 Roger Odle 2012-11-08 14:45:17 EST
Never used fsid=0 before.  Couldn't mount NFS exports at all.  Found comment about NFS-4 on Internet that said fsid=0 parameter was required by NFS-4.  Adding this made it appear to work but with the consequences described above.

I did not try fsid=1 or some other numbers.  If this is the issue then it have saved some trouble if NFS had reported a conflict in the configuration parameters.

I have not worked this issue in a long time.  I only needed to transfer tiles in one direction so I used the Apache webserver on my workstation to share the directories then accessed the files using http download.  This webserver is only used for testing web applications so the configuration changes frequently and it is only used on the local intranet.
Comment 3 Steve Dickson 2012-11-09 06:43:44 EST
(In reply to comment #2)
> Never used fsid=0 before.  Couldn't mount NFS exports at all.  Found comment
> about NFS-4 on Internet that said fsid=0 parameter was required by NFS-4. 
> Adding this made it appear to work but with the consequences described above.
Early on that was the case, but now fsid=0 is no longer needed.

> 
> I did not try fsid=1 or some other numbers.  If this is the issue then it
> have saved some trouble if NFS had reported a conflict in the configuration
> parameters.
fsid should be used to identify filesystems which is usually done with UUIDs. Since most filesystems support the notion of UUIDs, setting the fsid is probably not a good idea. 

> 
> I have not worked this issue in a long time.  I only needed to transfer
> tiles in one direction so I used the Apache webserver on my workstation to
> share the directories then accessed the files using http download.  This
> webserver is only used for testing web applications so the configuration
> changes frequently and it is only used on the local intranet.
Ok... So I'm going to close this bug but please feel free to reopen it if necessary..