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:
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.
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?
As mentioned in the comment#2, this is expected behaviour. Closing the bug.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days