Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#69135 - [rsync] failed to set permissions on ... after update

Attached to Project: Arch Linux
Opened by Stephan von Krawczynski (skraw) - Monday, 28 December 2020, 14:06 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 30 December 2020, 10:37 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

since the last update from rsync-3.2.3-1-x86_64.pkg.tar.zst to rsync-3.2.3-2-x86_64.pkg.tar.zst lots of error messages occur during rsync'ing like this:

2020/12/26 01:03:51 [293332] rsync: [generator] failed to set permissions on "<filename>" (in <host>): Operation not supported (95)

These messages name files that really exist on the rsync remote-host.

Additionally errors like this exist:

2020/12/26 04:54:35 [1103991] rsync: [receiver] failed to set permissions on "<filename>" (in <host>): Operation not supported (95)

Where <filename> does not even exist on the remote-host.



Additional info:
* package version(s)
rsync-3.2.3-2-x86_64.pkg.tar.zst

* config and/or log files etc.
See above log lines

* link to upstream bug report, if any

Steps to reproduce:

Log into remote box and rsync to arch with above rsync version, then do on remote:
rsync -avx <localdir> <<arch-host-with-new-rsync-daemon>
Watch Logfile for above problem.

This task depends upon

Closed by  Christian Hesse (eworm)
Wednesday, 30 December 2020, 10:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  rsync 3.2.3-3
Comment by Dean Wallace (duffydack) - Tuesday, 29 December 2020, 20:51 GMT
Same issue here. I'll revert back for now.
Comment by Christian Hesse (eworm) - Tuesday, 29 December 2020, 21:28 GMT
Only change in that version is in rsync-ssl to properly verify the hostname in the certificate when using openssl.
No idea how this version can generate (new) error messages like the above...

Also please give more specific example, naming hosts `host-a` and `host-b`, including all commands and giving used versions.
Comment by Christian Hesse (eworm) - Tuesday, 29 December 2020, 21:33 GMT
What filesystems are used on source and destination?
Are symbolic links involved?
Comment by Dean Wallace (duffydack) - Wednesday, 30 December 2020, 00:46 GMT
Ok, I'll try be as thorough as possible. My use case for the last year or so has been to perform rsync full backups (like described in wiki) to an rsync daemon running on my arch "server" machine. Previously I just rsync'd to an external drive with pretty much the same command and flags.

Host-A runs archlinux with rsync running as daemon on default port, backup path on ext4 as /srv/rsyncd
Its /etc/rsyncd.conf as follows

uid = root
gid = root
use chroot = yes #so links get stored properly as /path/file and not path/file
read only = false
max connections = 8
syslog facility = local5
pid file = /run/rsyncd.pid

[backup]
path = /srv/rsyncd
comment = full rsync arch backups


Client-A running arch, simple ext4 setup, running the command
rsync -aAXHv /* hostA::backup/clientA --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} --delete

Lots of file get transferred, lots getting operation not supported. For instance, this file
rsync: [receiver] failed to set permissions on "/clientA/var/log/.wtmp.bRZvVw" (in backup): Operation not supported (95)

-rw-rw-r-- 1 root utmp 1.5K Dec 30 00:11 /var/log/wtmp <-- File on the client
-rw------- 1 root utmp 1.5K Dec 30 00:11 /srv/rsyncd/clientA/var/log/wtmp <--- File on rsyncd host, missing perms, but both md5sums match.


Roll back to rsync 3.2.3-1 and everything is fine.

-rw-rw-r-- 1 root utmp 1.5K Dec 30 00:11 /srv/rsyncd/clientA/var/log/wtmp <--- File transferred with rsync 3.2.3-1

This has always worked, and I have restored a full backup to a client machine multiple times.
Comment by Dean Wallace (duffydack) - Wednesday, 30 December 2020, 00:58 GMT Comment by loqs (loqs) - Wednesday, 30 December 2020, 04:22 GMT
Please try rebuilding rsync with the attached diff applied. It cherry-picks two commits fixing glibc's lchmod bug.
Comment by Dean Wallace (duffydack) - Wednesday, 30 December 2020, 10:17 GMT
Excellent, it works. Thank you
Comment by Christian Hesse (eworm) - Wednesday, 30 December 2020, 10:37 GMT
Thanks for investigating!

Loading...