Just to add, if you look at packet 100 (READDIR response) in tcpdump,
the mode bits are set to 0755. But what is displayed by "ls" is 0555.
I'm trying to figure out where that one bit gets lost.
On Fri, Sep 4, 2020 at 8:55 AM Pradeep <pradeepthomas@xxxxxxxxx> wrote:
>
> Hello,
>
> I'm seeing an issue where stat (and ls) reports wrong mode bits on
> referral directories. Actual permissions are 755; but Linux client
> displays 555. This causes some operations like setattr (chmod) to
> fail. Traversing to the directory fixes the issue.
>
> Kernel version : 5.8.6-2.el7.elrepo.x86_64
>
> [nfstest@centos77 ~]$ mkdir /mnt/nfsh1/dir.{1..5}
> [nfstest@centos77 ~]$ ls -l /mnt/nfsh1
> total 3
> dr-xr-xr-x. 2 nfstest wheel 2 Sep 3 17:55 dir.1
> drwxr-xr-x. 2 nfstest wheel 2 Sep 3 17:55 dir.2
> dr-xr-xr-x. 2 nfstest wheel 2 Sep 3 17:55 dir.3
> dr-xr-xr-x. 2 nfstest wheel 2 Sep 3 17:55 dir.4
> dr-xr-xr-x. 2 nfstest wheel 2 Sep 3 17:55 dir.5
> [nfstest@centos77 ~]$ stat /mnt/nfsh1/dir.1
> File: ‘/mnt/nfsh1/dir.1’
> Size: 2 Blocks: 1 IO Block: 1048576 directory
> Device: 30h/48d Inode: 3940649673949864 Links: 2
> Access: (0555/dr-xr-xr-x) Uid: ( 2000/ nfstest) Gid: ( 10/ wheel)
> Context: system_u:object_r:nfs_t:s0
> Access: 2020-09-03 17:55:59.082327209 -0400
> Modify: 2020-09-03 17:55:59.082327209 -0400
> Change: 2020-09-03 17:55:59.082327209 -0400
> Birth: -
> [nfstest@centos77 ~]$ ls /mnt/nfsh1/dir.1 <-- Try traversing into the
> dir, see the mode bits in stat after traversal.
> [nfstest@centos77 ~]$ stat /mnt/nfsh1/dir.1
> File: ‘/mnt/nfsh1/dir.1’
> Size: 2 Blocks: 1 IO Block: 32768 directory
> Device: 32h/50d Inode: 3940649673949864 Links: 2
> Access: (0755/drwxr-xr-x) Uid: ( 2000/ nfstest) Gid: ( 10/ wheel)
> Context: system_u:object_r:nfs_t:s0
> Access: 2020-09-03 17:55:59.082327209 -0400
> Modify: 2020-09-03 17:55:59.082327209 -0400
> Change: 2020-09-03 17:55:59.082327209 -0400
> Birth: -
>
> Attached is the tcpdump for requests. It looks like the server sends
> back correct attributes; but the client somehow is ignoring it. Any
> ideas why?
>
> Thanks,
> Pradeep
