I am currently migrating from Ubuntu 20.04 to Fedora 34. Following backup script has worked fine so far:

rsync                        \
  -avixXEH                   \
  --stats                    \
  --delete                   \
  --numeric-ids              \
  --log-file="$LOG_FILE"     \
  --link-dest "$LATEST"      \
  --exclude '/some/exclude'  \
  admin@nas:/{a,b,c}         \ # source is remote nas (via ssh)
  "$TARGET"                  \ # $TARGET is ext. USB disk on fedora OS desktop

Unfortunately on Fedora, every copied path now results in a warning, polluting the log:

rsync_xal_set: lremovexattr("/my/path/file.zPXUj1","security.selinux") failed: Permission denied (13)


This seems to be an issue with rsync wanting to preserve/erase extended attributes (-X) and SELinux.

Recent quote from Michal Ruprich, Red Hat:

This was 'fixed' in RHEL5 by suppressing the error message so that it does not disrupt running systems. [...]

"rsync-2.6 does not remove extended attribute of target file in the case that this attribute has been erased in the source file. Lets call it bug.

rsync-3.0 correctly tries to remove erased extended attributes.

If the selinux is present on the target system, rsync can't erase security context of file and it outputs mentioned error. The behaviour of 2.6 and 3.0 is therefore identical except the informational error message."

Using rsync 3.2.3 with a non-SELinux source, my interpretation is - please correct me otherwise:

Copying files from a source without SELinux to a target using this security feature is interpreted as deleting the extended "security.selinux" file attribute. And rsync cannot remove it due to SELinux security restrictions on the target.

Which raises the question:

How to suppress these warnings?

I still would like to copy extended attributes with -X and not temporarily disable complete SELinux as suggested here. Also, stumbled over an alternative that suggests setsebool -P rsync_full_access 1 - not sure, what that does exactly.

It really would be nice to solve the problem at its root only for this particular case: Given USB disk mount point /run/media/user/<SOME-UID>, is there some way to grant necessary permissions in SELinux just for this path or similar?

Thanks in advance

  • On my side, neither setenforce 0 or setsebool -P rsync_full_access 1 does the trick. Only removing -X does, but I think omitting -X breaks the podman files I'm trying to backup. It seems the problem is rsyncing from a non-selinux fs to an selinux fs, making it seem like selinux labels are being removed while they were not present in the first place. May 7 at 15:12
  • Side note: in your rsync options, -E is already in -a because it does -p. explainshell.com/explain?cmd=rsync+-rlptgoDvixXEH May 7 at 15:22
  • Good catch with the unnecessary -E option. I also did comment your answer down under.
    – grisha
    May 8 at 17:36

After some more research and finding this outdated response, it seems this option fixes it:

--filter='-x security.selinux'

As per the man:

       --xattrs, -X


              The above name filtering can be overridden by using one or
              more filter options with the x modifier.  When you specify
              an xattr-affecting filter rule, rsync requires that you do
              your own system/user filtering, as well as any additional
              filtering for what xattr names are copied and what names
              are allowed to be deleted.  For example, to skip the
              system namespace, you could specify:

                  --filter='-x system.*'


    rsync -aHAXX \
      --filter='-x security.selinux' \
      --numeric-ids \
      --no-inc-recursive \
      --delete \
      --exclude={"/lost+found"} \
      --info=progress2 \
      source \
  • Thank you, this is helpful and a step in the right direction! I tried the following: rsync -avixXH --filter='-x security.selinux' user@snas:/path /backup/path, but got: invalid modifier sequence at 'x' in filter rule: -x security.selinux, rsync error: syntax or usage error ..., rsync: connection unexpectedly closed. Is there anything, you have done differently?
    – grisha
    May 8 at 17:35
  • @grisha i have updated my answer to reflect how i'm using it, works on my side. rsync 3.2.3 protocol version 31 Jun 16 at 9:09
  • Does that also work with an SSH remote source for you? If yes: my sender rsync version is 3.0.9, my receiver rsync version 3.2.3. Then there might be some a version incompatibility or improvements since 3.0.9 regarding the --filter function. Unfortunately, I cannot easily upgrade the remote source version. A test with two local directories on 3.2.3 with your configuration also works on my machine.
    – grisha
    Jun 17 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.