Red Hat Bugzilla – Bug 1031164
After mounting a GlusterFS NFS export intial cd'ing into directories on a Tru64 resaults in a Permission Denied error
Last modified: 2014-08-18 09:43:21 EDT
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.
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
>boden/ cop/ csxmig/ hermes/ sctdev/
># umount /tmp/foo
Get a permission denied after ls/cd of the directory
Don't get permission denied after ls/cd of a directory
I have attached a package dump of the above transaction genreated with tcpdump on the GlusterFS node.
22.214.171.124 - 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.
[Program Version: 3]
[V3 Procedure: MNT (1)]
Status: OK (0)
[hash (CRC-32): 0x249cd73e]
decode type as: unknown
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
This problem should be fixed when Bug 1118311 is resolved.
*** This bug has been marked as a duplicate of bug 1118311 ***