RsyncProject / rsync

An open source utility that provides fast incremental file transfer. It also has useful features for backup and restore operations among many other use cases.
https://rsync.samba.org
Other
2.71k stars 327 forks source link

rsync -AX as root between ext4 and xfs can drop ACLs on the target #301

Open traktofon opened 2 years ago

traktofon commented 2 years ago

When rsync'ing a directory from an ext4 filesystem to an xfs filesystem (on Linux) as root, and trying to preserve both ACLs (option -A) and extended attributes (option -X), then on the first pass the ACLs are copied correctly, but on a second pass (which should be idempotent if there are no changes on the source) the ACLs on the target are deleted. (A third pass will restore the ACLs, etc.)

Steps to reproduce:

Be root. Let /a be an ext4 filesystem (also tested: ext3; I guess anything non-xfs would do, as long as it supports ACLs). Let /b be an xfs filesystem (created with default options in Debian 11). Have any files/folders on /a with ACLs, e.g.

$ mkdir -p /a/TEST/folder
$ setfacl -m u:nobody:rwx /a/TEST/folder
$ getfacl /a/TEST/folder
getfacl: Removing leading '/' from absolute path names
# file: a/TEST/folder
# owner: root
# group: root
user::rwx
user:nobody:rwx
group::r-x
mask::rwx
other::r-x

Now rsync the TEST directory to /b:

# mkdir /b/TEST
$ rsync -aAX /a/TEST/ /b/TEST/
$ getfacl /b/TEST/folder
getfacl: Removing leading '/' from absolute path names
# file: b/TEST/folder
# owner: root
# group: root
user::rwx
user:nobody:rwx
group::r-x
mask::rwx
other::r-x

We see that the ACLs have been copied correctly. But running the same rsync command again:

$ rsync -aAX /a/TEST/ /b/TEST/
$ getfacl /b/TEST/folder/
getfacl: Removing leading '/' from absolute path names
# file: b/TEST/folder/
# owner: root
# group: root
user::rwx
group::rwx
other::r-x

We see that the ACLs on the target have been deleted.

I suspect that this is caused by xfs storing ACLs in an extended attribute:

$ attr -l /b/TEST/folder
Attribute "SGI_ACL_FILE" has a 64 byte value for /b/TEST/folder

and perhaps this needs to be special-cased inside rsync when copying xattrs?

Workaround:

If you know which extended attributes are actually in use (e.g. only those of the user.* kind) then an additional rsync option like --filter='-x! user.*' can be used to only process these specific attributes, and this seems to prevent the destruction of ACLs on the target.

Software version:

Tested with v3.2.4pre3-18-gd821e4cb (current git master) and 3.2.3 (from Debian 11). Tested with a local source as well as a remote source (over ssh).

jkbremer commented 3 weeks ago

I have the same issue. It seems to be related to the kernel version that is running. With kernel version 4.19.0-27 rsync between ext4 and xfs worked great, including xattr sync.

After booting with kernel version 5.10.0-0, no xattrs are synced on the first sync. From the second sync on, only a subset of files/directories get xattrs. But never all of them.

With kernel version 6.1.0-23, I exeperience the exact same behavior of @traktofon. After the first sync, all files have correct xattrs. Afterwards, they are subsequently deleted and restored.