Hide Forgot
Created attachment 824654 [details] Packet dump of the mount, cd (failed), cd, ls, umount transaction Description of problem: After mounting a GlusterFS NFS export intial cd'ing into directories on a Tru64 resaults in a Permission Denied error. cd'ing again allows me to enter the directory. How reproducible: After turning on nfs.mount-udp, mount the GlusterFS NFS export cd to the mount point, cd again. Steps to Reproduce: 1. Turn on mount-udp > gluster volume set VOLUME-NAME nfs.mount-udp on 2. Mount GlusterFS NFS Mount > mount -t nfs -o vers=3,tcp gluster04.switch.com:/resd/ /tmp/foo 3. cd to the mount point > #cd /tmp/foo > /tmp/foo: Permission denied 4. cd again to mount point ># cd /tmp/foo ># ls >boden/ cop/ csxmig/ hermes/ sctdev/ ># cd ># umount /tmp/foo Actual results: Get a permission denied after ls/cd of the directory Expected results: Don't get permission denied after ls/cd of a directory Additional info: I have attached a package dump of the above transaction genreated with tcpdump on the GlusterFS node.
additional information: 192.234.48.100 - Tru64 client 10.210.35.23 - GlusterFS NFS Server Also, the Tru64 NFS client works fine with a Native Linux NFS (kernel) server.
The filehandle that the MOUNT MNT Reply contains (Frame 6) is incorrect. The filehandle actually identifies the root-directory of the volume, and not the /resd sub-directory. Mount Service [Program Version: 3] [V3 Procedure: MNT (1)] Status: OK (0) fhandle length: 34 [hash (CRC-32): 0x249cd73e] decode type as: unknown filehandle: 3a4fcb008a4b41fa41cc85fd1e5d5d9d8b84000000000000... Flavors: 1 Flavor: AUTH_UNIX (1) filehandle in bytes: 0040 .. .. .. .. .. .. .. .. .. .. 3a 4f cb 00 8a 4b .........":O...K 0050 41 fa 41 cc 85 fd 1e 5d 5d 9d 8b 84 00 00 00 00 A.A....]]....... 0060 00 00 00 00 00 00 00 00 00 00 00 01 00 00 .. .. ................ 0070 .. .. .. .. .. .. On GlusterFS 3.4.1 the marker ":O" indicates a Gluster/NFS filehandle. The filehandle consists out of the UUID for the volume, followed by the GFID of the file/directory on the volume. The GFID 00000000-0000-0000-0000-000000000001 is the value for the root of the volume. Using that filehandle and access a different directory will not work as expected. This problem should be fixed when Bug 1118311 is resolved. *** This bug has been marked as a duplicate of bug 1118311 ***