rsync - Mar 2019 - [Bug 13820] New: rsync is not preserving ACLs

https://bugzilla.samba.org/show_bug.cgi?id=13820

            Bug ID: 13820
           Summary: rsync is not preserving ACLs
           Product: rsync
           Version: 3.1.3
          Hardware: x64
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: core
          Assignee: wayne at opencoder.net
          Reporter: dinesh.k at nokia.com
        QA Contact: rsync-qa at samba.org

Hi,
rsync seems to be not preserving ACLs like it is mentioned in the man pages.
Here the case is that source files don't have any ACLs set, and destination
file has group ACL.
When the file is copied using rsync from another VM, destination file ACLs are
lost. Even though I am not using "-A" or by using "--no-A"
ACLs are being lost.


[root at mn-0:/root]
# setfacl -m "g:wheel:rw-" /root/test.txt
[root at mn-0:/root]
# getfacl /root/test.txt
getfacl: Removing leading '/' from absolute path names
# file: root/test.txt
# owner: root
# group: root
user::rw-
group::r--
group:wheel:rw-
mask::rw-
other::r--

[root at mn-0:/root]
# rsync /tmp/dummy /root/test.txt
[root at mn-0:/root]

# getfacl /root/test.txt
getfacl: Removing leading '/' from absolute path names
# file: root/test.txt
# owner: root
# group: root
user::rw-
group::rw-
other::r--

[root at mn-0:/root]
#

========================================

[root at mn-0:/root]
# setfacl -m "g:wheel:rw-" /root/test.txt
[root at mn-0:/root]

# getfacl /root/test.txt
getfacl: Removing leading '/' from absolute path names
# file: root/test.txt
# owner: root
# group: root
user::rw-
group::rw-
group:wheel:rw-
mask::rw-
other::r--

[root at mn-0:/root]
# rsync --no-A /tmp/dummy /root/test.txt
[root at mn-0:/root]
# getfacl /root/test.txt
getfacl: Removing leading '/' from absolute path names
# file: root/test.txt
# owner: root
# group: root
user::rw-
group::rw-
other::r--

[root at mn-0:/root]

===================================================$ uname -a
Linux mn-0 4.14.101-1.wf29.x86_64 #1 SMP Sun Feb 17 20:39:50 EET 2019 x86_64
x86_64 x86_64 GNU/Linux
[robot at mn-0:/home/robot]

$ rsync --version
rsync  version 3.1.3  protocol version 31

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13820

--- Comment #1 from Kevin Korb <rsync at sanitarium.net> ---
You have -A backwards.  If you want rsync to copy the ACLs you have to use -A.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13820

--- Comment #2 from Paul Slootman <paul at debian.org> ---
I think the point Dinesh is trying to make is that rsync is removing ACLs from
the destination even though it's not asked to preserve the source's ACLs
(which
don't exist).

I think the problem is that rsync creates a new file on the destination. The
same thing will happen to any other metadata such as group or owner, if you
don't use -g or -o (the group and owner will become the user transferring
the
file).

Try using --inplace to update the existing file.

IMHO this is not a bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13820

--- Comment #3 from Dinesh Reddy <dinesh.k at nokia.com> ---
(In reply to Paul Slootman from comment #2)
Thanks for the suggestion. --inplace is actually working for my case.
Our use-case is to distribute sparse file across the VMs (--sparse is being
used), hopefully, this --inplace don't have any impact on --sparse option.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13820

Wayne Davison <wayne at opencoder.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

-- 
You are receiving this mail because:
You are the QA Contact for the bug.