Yes Benjamin. If the referral mounts already exist, then rsync will
try to chmod to the source. That will not work because of mode bits.
rsync will continue to traverse into the referral mount and create
inner directories and copy other stuff. At the end, it will copy
everything except the attributes for referral mounts and also displays
an error. This is what I see:
[nfstest@centos77 ~]$ mkdir rsync-dataset
[nfstest@centos77 ~]$ mkdir -p rsync-dataset/dir.{1..5}
[nfstest@centos77 ~]$ touch rsync-dataset/dir.{1..5}/file
[nfstest@centos77 ~]$ rsync -avz rsync-dataset/* /mnt/nfsh1/
sending incremental file list
rsync: failed to set times on "/mnt/nfsh1/dir.1": Permission denied (13)
rsync: failed to set times on "/mnt/nfsh1/dir.3": Permission denied (13)
rsync: failed to set times on "/mnt/nfsh1/dir.4": Permission denied (13)
rsync: failed to set times on "/mnt/nfsh1/dir.5": Permission denied (13)
dir.1/
dir.1/file
dir.2/
dir.2/file
dir.3/
dir.3/file
dir.4/
dir.4/file
dir.5/
dir.5/file
sent 432 bytes received 439 bytes 1,742.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1179) [sender=3.1.2]
On Fri, Sep 4, 2020 at 11:30 AM Benjamin Coddington <bcodding@xxxxxxxxxx> wrote:
>
> Ah, maybe you're just trying to copy the NFS namespace and cross the
> referral, not actually create a new referral. In that case - yes,
> perhaps
> this needs a fixup. We might look at how rsync crosses other
> mountpoints,
> because I think the same problem would exist. You'd want rsync to
> create
> the directory with the attributes of the root of the mounted filesystem,
> not
> the mountpoint.
>
> Ben
>
> On 4 Sep 2020, at 14:20, Benjamin Coddington wrote:
>
> > I don't understand how the client can create a directory that can be a
> > referral. Doesn't the directory have to be a mountpoint on the
> > server?
> >
> > I don't think that rsync can copy a namespace that contains refferal
> > mounts
> > from the client side, but maybe I am really misunderstanding things..
> >
> > Ben
> >
> > On 4 Sep 2020, at 14:09, Pradeep wrote:
> >
> >> Thanks Benjamin. Looks like it is added as part of commit
> >> 72de53ec4bca39c26709122a8f78bfefe7b6bca4 by Bryan Schumaker.
> >>
> >> Given that neither chmod nor readdir traverses the referral mount
> >> points, wouldn't this be an issue to return mode bits as 0555?
> >> The issue I see is with rsync. rsync first creates the directory and
> >> calls chmod. If this directory happens to be a referral mount, then
> >> chmod fails because the user doesn't have write access (0555).
> >>
> >> Thanks
> >>
> >> On Fri, Sep 4, 2020 at 10:15 AM Benjamin Coddington
> >> <bcodding@xxxxxxxxxx> wrote:
> >>>
> >>> Probably in nfs_fixup_secinfo_attributes(), and looks deliberate.
> >>> I'm not
> >>> sure about the reasoning behind it, though. Maybe it's to clarify
> >>> that you
> >>> can't traverse this directory.
> >>>
> >>> Ben
> >>>
> >>> On 4 Sep 2020, at 12:57, Pradeep wrote:
> >>>
> >>>> 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
> >>>
>
