Bug 1031164

Summary: After mounting a GlusterFS NFS export intial cd'ing into directories on a Tru64 resaults in a Permission Denied error
Product: [Community] GlusterFS Reporter: Derek Schrock <dereks>
Component: nfsAssignee: Ric Wheeler <rwheeler>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.4.1CC: gluster-bugs, lbalbalba, ndevos
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: 2014-08-18 13:43:21 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:
Attachments:
Description Flags
Packet dump of the mount, cd (failed), cd, ls, umount transaction none

Description Derek Schrock 2013-11-15 18:37:35 UTC 
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.
Comment 1 Derek Schrock 2013-11-15 21:42:31 UTC 
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.
Comment 3 Niels de Vos 2014-08-18 13:43:21 UTC 
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 ***