Description of problem: trying to do a mount, while providing path as symlink to a dir and it fails. whereas for kernel nfs it works well. Version-Release number of selected component (if applicable): [root@nfs1 ~]# rpm -qa | grep glusterfs glusterfs-fuse-3.4.0.13rhs-1.el6rhs.x86_64 glusterfs-3.4.0.13rhs-1.el6rhs.x86_64 glusterfs-server-3.4.0.13rhs-1.el6rhs.x86_64 How reproducible: always Steps to Reproduce: 1. create a volume, start it 2. mount the volume over nfs. 3. create a dir inside and symlink to this dir. [root@rhsauto030 nfs-test2]# file symdir symdir: symbolic link to `dir' [root@rhsauto030 nfs-test2]# pwd /mnt/nfs-test2 [root@rhsauto030 nfs-test2]# mount | grep nfs-test2 10.70.37.123:/dist-rep2 on /mnt/nfs-test2 type nfs (rw,addr=10.70.37.123) [root@rhsauto030 nfs-test2]# 4. try to do a mount, using symlink created in step 3. [root@rhsauto030 nfs-test2]# mount -t nfs -o vers=3 10.70.37.123:/dist-rep2/symdir /mnt/nfs-test-dir/ mount.nfs: an incorrect mount option was specified Actual results: mount fails to hapen, packet trace while mount is tried out, 73 1.482975 10.70.37.5 -> 10.70.37.123 NFS V3 NULL Call 75 1.483534 10.70.37.123 -> 10.70.37.5 NFS V3 NULL Reply (Call In 73) 95 1.488580 10.70.37.5 -> 10.70.37.123 MOUNT V3 NULL Call 97 1.490332 10.70.37.123 -> 10.70.37.5 MOUNT V3 NULL Reply (Call In 95) 105 1.493355 10.70.37.5 -> 10.70.37.123 MOUNT V3 NULL Call 107 1.495088 10.70.37.123 -> 10.70.37.5 MOUNT V3 NULL Reply (Call In 105) 109 1.495406 10.70.37.5 -> 10.70.37.123 MOUNT V3 MNT Call /dist-rep2/symdir 110 1.498474 10.70.37.123 -> 10.70.37.5 MOUNT V3 MNT Reply (Call In 109) 117 1.500338 10.70.37.5 -> 10.70.37.123 NFS V3 FSINFO Call, FH:0xf36fddf6 118 1.501397 10.70.37.123 -> 10.70.37.5 NFS V3 FSINFO Reply (Call In 117) 119 1.501591 10.70.37.5 -> 10.70.37.123 NFS V3 PATHCONF Call, FH:0xf36fddf6 120 1.502558 10.70.37.123 -> 10.70.37.5 NFS V3 PATHCONF Reply (Call In 119) 122 1.509865 10.70.37.5 -> 10.70.37.123 NFS V3 FSINFO Call, FH:0xf36fddf6 123 1.511058 10.70.37.123 -> 10.70.37.5 NFS V3 FSINFO Reply (Call In 122) Expected results: our implementation should work similarly to kernel nfs implementation Additional info: similar stuff works for kernel works, [root@rhsauto030 saurabh]# file symdir symdir: symbolic link to `dir/' [root@rhsauto030 saurabh]# mount -t nfs -o vers=3 rhsqe-repo.lab.eng.blr.redhat.com:/opt/qa/saurabh/symdir /mnt/nfs-test-dir [root@rhsauto030 saurabh]# pwd /opt/qa/saurabh 162 5.035347 10.70.37.5 -> 10.70.34.52 NFS V3 NULL Call 164 5.035825 10.70.34.52 -> 10.70.37.5 NFS V3 NULL Reply (Call In 162) 171 5.037502 10.70.37.5 -> 10.70.34.52 MOUNT V3 NULL Call 172 5.038393 10.70.34.52 -> 10.70.37.5 MOUNT V3 NULL Reply (Call In 171) 173 5.038997 10.70.37.5 -> 10.70.34.52 MOUNT V3 NULL Call 174 5.039452 10.70.34.52 -> 10.70.37.5 MOUNT V3 NULL Reply (Call In 173) 175 5.039578 10.70.37.5 -> 10.70.34.52 MOUNT V3 MNT Call /opt/qa/saurabh/symdir 176 5.041213 10.70.34.52 -> 10.70.37.5 MOUNT V3 MNT Reply (Call In 175) 180 5.042339 10.70.37.5 -> 10.70.34.52 NFS V3 FSINFO Call, FH:0xfc4facec 181 5.042735 10.70.34.52 -> 10.70.37.5 NFS V3 FSINFO Reply (Call In 180) 182 5.042910 10.70.37.5 -> 10.70.34.52 NFS V3 PATHCONF Call, FH:0xfc4facec 183 5.043385 10.70.34.52 -> 10.70.37.5 NFS V3 PATHCONF Reply (Call In 182) 184 5.043507 10.70.37.5 -> 10.70.34.52 NFS V3 GETATTR Call, FH:0xfc4facec 185 5.044022 10.70.34.52 -> 10.70.37.5 NFS V3 GETATTR Reply (Call In 184) Directory mode:0755 uid:1000 gid:1000 186 5.047614 10.70.37.5 -> 10.70.34.52 NFS V3 FSINFO Call, FH:0xfc4facec 187 5.048020 10.70.34.52 -> 10.70.37.5 NFS V3 FSINFO Reply (Call In 186) 188 5.048199 10.70.37.5 -> 10.70.34.52 NFS V3 GETATTR Call, FH:0xfc4facec 189 5.048627 10.70.34.52 -> 10.70.37.5 NFS V3 GETATTR Reply (Call In 188) Directory mode:0755 uid:1000 gid:1000
Patch posted by Jiffin: https://code.engineering.redhat.com/gerrit/36702
Test done to verify this fix with these steps, 1. create a volume of 6x2 type, start it 2. mount the volume over nfs 3. create a directory inside mount-point, say dir1 4. create symlink for this directory. 5. mount with symlink. 6. execute some I/O say iozone. So mount in step 5 and I/O in step6 were successful Although, two BZs have been filed based on the case executed. BZ 1166051 BZ 1166060
Jiffin, Please review the edited doc text and sign-off.
Divya, The doc looks fine too me.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0038.html