Bug 1166060

Summary: nfs: mount command the mount of symlink dir as with original dir.
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Saurabh <saujain>
Component: gluster-nfsAssignee: Niels de Vos <ndevos>
Status: CLOSED NOTABUG QA Contact: storage-qa-internal <storage-qa-internal>
Severity: low Docs Contact:
Priority: unspecified    
Version: rhgs-3.0CC: jthottan, mzywusko, skoduri
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: 2016-01-29 12:17:11 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:

Description Saurabh 2014-11-20 10:56:06 UTC 
Description of problem:
in case we have a symlink for directory and we try to mount the symlink over nfs.
The subsequent execution of the mount command, does not the mount as done with symlink where as with original dir.

Version-Release number of selected component (if applicable):
glusterfs-3.6.0.33-1.el6rhs.x86_64

How reproducible:
always

Steps to Reproduce:
1. create a volume of type 6x2, start it
2. mount the volume over nfs on a client
3. create a directory
4. create a symlink for the directory
5. mount using the symlink

Actual results:
mount | grep dir1
10.70.37.74:/vol0/dir1 on /mnt/nfs-symdir type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.70.37.74,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=10.70.37.74)


Expected results:
in the actual results the mount command display the information as /vol0/dir1 was mounted, where as the mount is done using the symlink namely "symdir".
So, therefore it should display as symlink is mounted.

Additional info:
Comment 2 Jiffin 2014-11-25 11:58:51 UTC 
 The mount command will show the contents in /etc/mtab which is a symlink to /proc/mounts so it can't be updated by user  space utilities and what you see is constructed from the kernel VFS mount data structures when /proc/mounts is accessed.

That means when listing it's contents you see things that are actually mounted. And, when mounting, the kernel will attempt to resolve the paths to a directory (or device file, depending on parameter) as that's what's required for mounting. Those resolved paths is what the kernel  will report when /proc/mounts accessed.
Comment 3 Niels de Vos 2014-12-18 11:15:42 UTC 
In fact, this works fine for me:

# mount -t nfs -o vers=3 vm100-004:/one-brick/symlink.lnk /mnt
# mount
...
vm100-004:/one-brick/symlink.lnk on /mnt type nfs (rw,vers=3,addr=172.31.100.4)

# df -P /mnt
Filesystem                       1024-blocks   Used Available Capacity Mounted on
vm100-004:/one-brick/symlink.lnk      499712 133120    329728      29% /mnt

# umount /mnt

# mount -t glusterfs vm100-004:/one-brick /mnt
# ls -l /mnt/
...
drwxr-xr-x. 2 root root      4096 Dec 17 19:40 subdir.d
lrwxrwxrwx. 1 root root         8 Dec 17 19:40 symlink.lnk -> subdir.d
...


Would this issue be a duplicate of Bug 1166051?
Comment 5 Soumya Koduri 2016-01-29 12:17:11 UTC 
As mentioned in the comment#2, this is expected behaviour. Closing the bug.
Comment 6 Red Hat Bugzilla 2023-09-14 02:51:11 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days