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
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
|
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
Wednesday, 30 December 2020, 10:37 GMT
Reason for closing: Fixed
Additional comments about closing: rsync 3.2.3-3
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.
Are symbolic links involved?
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.