The last line is telling you that there were prior errors in either transferring files or file permissions/attributes.  In this case, all the xattr removal failures.

Ignore the remark in comment #0.  The issue is that SELinux won't allow any process to remove the "security.selinux" attribute, so perhaps rsync should not try.  OTOH, if SELinux is disabled, removing the attribute might be a useful thing to do.  One option would be to block this on bug 4573 and require the user to specify --xattr-filter='P security.selinux' when desired.

Ordinary warnings and data dependent errors are not bugs and shouldn't look like bugs. Source code file name and line number makes it look like a bug and should not be shown except for a bug.

I have been having problems with this bug on 3.1.1 and 3.1.2. To test if the latest version's xattr fixes would affect it, I also built the git version of 3.1.3dev which is git commit 31e93c322865acea7533176c2278b259890662fc but it has not helped. What I am seeing:

rsync: rsync_xal_set: lremovexattr(""/media/backup/main/2016-08-09/sys"","security.selinux") failed: Permission denied (13)

rsync does not error out, and completes without an errno but prints this message at the end:
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1186) [sender=3.1.3dev]

Here is the directory in question on my various backups as well as the actual directory it is attempting to backup:

tm@roll:~/src/rsync$ ls -laZd /media/backup/main/2016-*/sys /sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:default_t:s0   4096 Jul 21 20:09 /media/backup/main/2016-07-22/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Jul 26 12:24 /media/backup/main/2016-07-26/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Jul 29 22:00 /media/backup/main/2016-07-30/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  3 12:41 /media/backup/main/2016-08-03/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  6 13:34 /media/backup/main/2016-08-06/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  9 14:25 /media/backup/main/2016-08-09/sys
dr-xr-xr-x. 13 root root system_u:object_r:sysfs_t:s0            0 Aug  9 14:25 /sys

I imagine the problem may be related to the fact I am using unusual features such as --link-dest, so I will do some further testing to determine what actually is making rsync goof up with this.

After some further testing I have some fairly odd results, possibly related. Using --link-dest to point to an already existing backup set, or the same empty directory that we are backing up to causes the bug to appear. If I use --link-dest while pointing it at an empty directory and backing up to an empty directory, it does not happen.

Using rsync without it with the destination being an empty directory causes no errors.

Using rsync without it with the destination already having copies of the files causes the error to occur.

So it appears that if rsync notices that the /sys directory exists on the destination, it does the wrong thing.

here's two examples of how I'm invoking it:
without --link-dest:
/home/tm/src/rsync/rsync --stats -vaxAXRHS --preallocate --progress --delete --delete-excluded / /media/backup/test/1 --exclude-from /root/backupexcludes.txt

with --link-dest: (2 is empty and holds nothing. 1 was rm'd before the copy began.)
/home/tm/src/rsync/rsync --stats -vaxAXRHS --preallocate --progress --delete --delete-excluded --link-dest=/media/backup/test/2 / /media/backup/test/1 --exclude-from /root/backupexcludes.txt

Anything else I can provide to help identify this?

I'm seeing this on a clean Centos 7.2.1511 install, rsync 3.0.9.

selinux is disabled on the src, and enabled on the dst, but in permissive mode, so I'm not expecting errors.

'ausearch -m avc -ts recent' shows nothing, and there's nothing recent in /var/log/audit/audit.log. So selinux isn't reporting an issue, but rsync is.

My specific errors are

# rsync -avXz -e 'ssh -p 1234' remote-sys:/var/www/ www
...lots of:
rsync: rsync_xal_set: lremovexattr(""/var/www/."","security.selinux") failed: Permission denied (13)

Note that this only happens when I run as root, and when backing up something with extended attributes. I'm not seeing any of the --link-dest/whatver complciations from comment #5 - this is a completely standard backup of a remote system with xattrs.

Any workaround suggestions? It's difficult to run as an ordinary user because I can't run as the remote user (apache).

You can now specify xattr filter rules, such as -f='-x! user.*' to make a root copy ignore everything but user.* xattrs, or the combo of -f='-x system.*' -f='-x security.*' to ignore  the system & security prefixes.