rsync not working anymore after upgrading to LE10

Quote from bg.lebowski

With LE 9.2 i was able to setup rsync without any issue ... Also the the first "sync run" was successful.

and have you also tested a "first sync run" with LE 10 ?

Quote from bg.lebowski

... next i updated my box to LE 10.0 again ... means same configuration ...

and could also mean old addon's for LE 9.2 running on LE 10 (?!)

did you also upgrade the addon's for LE 10 ?

here is a man page for rsync:

rsync(1) - Linux man page

see there the "Exit Values".

if you run the rsync command manually you should get the exit value with "echo $?"

are both boxes in general pingable ? (LE 10 <=> second box)

addon "system-tools" gives a console

Quote from bg.lebowski

LE 10.0 didn't allow the Rsync Server (Synology NAS) to create the rsync folder configured in the "rsync module" in rsync.conf on Rsync Client (LibreELEC).

isn't there a ssh involved ?

are you able to ssh into LE from the the server ?

try it and run touch a (creates the file named "a" in the current folder).

Error ?

I'm rsyncing from a linux box to LE 10 via an bash script without errors here (running LE 10 generic)

both rsync version (rsync -V) are "protocol version 31"

are you sure you're try to rsync to an destination under ~/storage

- assuming generic and RPI disk layout are the same -

see the Usage section in the man page of rsync: a missing/wrong slash in the rsync command

Did you reboot, or logout and log back in via ssh? If yes, then check if the rsync executable exists in /storage/.kodi/addons/virtual.network-tools/bin/.

The path is set by /etc/profile.d/*, so it requires a relog and/or reboot depending on how you are using the rsync executable for it to be in the system PATH.

rsync works fine on LE 10.

Ahh, your using rsyncd service (port 873). I am tunneling rsync over ssh (might want to see if Synology has that as an option). The official LE addon that I am using doesn't have a service option only console tools (network-tools addon). Not aware of a service add-on, if one existed prior to LE-10. The only other thing that comes to mind is perhaps you are following these instructions (or similar) to setup rsyncd as a service?

Personally, I would use rsync over ssh, it's a lot less hassle than running rsync as a service.

Quote from bg.lebowski

But unfortunately after pressing the save button and error message appears ...

"Insufficient privileges to access this destination shared folder. Please contact the destination administrator for assistance"

This is due the fact that the rsync process will create the destination share and store its rsync notes (synobkpinfo.db) inside.

I've no idea from that tool running on your NAS.

and couldn't find out what's the differences between the rsync versions are.

sorry !

but some wild guesses:

where is that "destination" on LE 10 exactly ?

have you tried to create the directory and the file "synobkpinfo.db" in it (maybe an old synobkpinfo.db from LE 9.x copied) ?

the password in the first picture is "libreelec" and the IP adress matches ?

what would be if you unselect "Enable configuration backup (mandatory)" ?

it seems the second picture is uncomplete.

there seem to be more config. options further down (?!)

all I cant do is provide my rsync script :

#!/bin/bash

CLIENT="192.168.100.22";
# export CLIENT;

OPTs="-vauH --delete --progress --stats -h";

STD_EXCLUDE="Sync.log" && for i in ${STD_EXCLUDE}; do EXCLUDES="${EXCLUDES} --exclude=$i"; done;

SRC="/home/otto/Media";    # What to sync

DEST="/storage/Media";     # where to sync to on the LE box

LOG="./Sync_$(date +%F).log" && rm -rvf ./Sync_*.log;

    $(which rsync) ${OPTs} -e ssh ${SRC}/ root@${CLIENT}:${DEST} ${EXCLUDES} --log-file=${LOG};
    RSYNC_RC=$?;

    echo -e "\n\n Sync_RC=${RSYNC_RC} \n\n" >> ${LOG};

exit 0;

please adjust:

- CLIENT

- SRC (path !)

- DEST (path !)

- LOG (path !)

script asks for ssh login password on LE10 (if you keep it default it's "libreelec")

script removes on each run the old Log file.

it runs that way without errors

you could add " --dry-run" to "OPTs" line (within the brackets '"' !!!)

see man page rsync => "--dry-run"

and/or run the script with "sh -vx ./<scriptname>"

chmod u+x ./<scriptname> done once (if you're not from the *nix world)

assuming the NAS run a sort of *nix and "which rsync" expands to something useful

Quote from bg.lebowski

Hmm ... I just imagine that I did a test upgrading from LE 9.2.6 to LE 9.95 but before disabling autoupdate for "network tools".

After LE upgrade to LE 9.95 "network tools" (rsync v .104) where marked as "incompatible" !!!

So there must be a change !!!

sure, that wasn't my argument.

I meant:

I couldn't find out what the differences between the rsync version exactly were.

I could find on github that the version number with a short comment had changed, but not what internal in the source has changed (a direct comparison of both version was impossible [to me])

I guess you should find a hint why 9.2.6 addons in 9.95 are "incompatible" here (somewhere):

LibreELEC

or maybe this one (after very short flying over it):

Upcoming Changes - LibreELEC

=> change from Python2 to Python3

In general:

to me it seems your problems are laying somewhere in

- user rights on the LE box (seen from the rsync server)

- network behaviour of the different rsync versions

I would also suggest to search the INet with keywords "rsync" and your exact "NAS type".

maybe there is a update for your NAS out that fixes that (too) ...??

are there no debug options on the NAS, to see what's going on.

on LE there is one: switch that on and start the rsync from the NAS again...

Quote from bg.lebowski

I'm more thinking in the smb (Samba) implementation on LE 10

I somewhat lately saw your comment #9 after I wrote the above and I'm somewhat confused:

What has SMB with rsync to do ?

and if needed: SMB/Samba has debug options too, switch them ON !

what is if you start with a lean rsyncd.conf and debug ON on both ends ?

means:

old cruft and defaults should be out e.g. "max connections = 0" is such an default

and double check all entries e.g. "host allow" correct ? , uid/gid, ..., even when the problem has something to do with rights

see:

rsyncd.conf(5) - Linux man page

config files working yesterday don't mean they will work today too...

maybe the newer version of rsync now looks somewhat "sharper" to some config options then the prev. version of rsync did ...

don't know

in a *nix world you also should mask blanks:

comment = Synology3 Video Backup

versus

comment = "Synology3 Video Backup"

Quote from bg.lebowski

Hmm ... I just imagine that I did a test upgrading from LE 9.2.6 to LE 9.95 but before disabling autoupdate for "network tools".

After LE upgrade to LE 9.95 "network tools" (rsync v .104) where marked as "incompatible" !!!

So there must be a change !!!

Well it may be a newer version of rsync, so that's a possible change. You will probably need to look what version of rsync was running with 9.2.6, and go through the upstream rsync projects changelogs (https://download.samba.org/pub/rsync/NEWS) and documentation to see what new features were introduced that is affecting you. (network-tools 104 and earlier is rsync 3.1.3, 105 and later is rsync 3.2.3)

Try using "log file" configuration directive and logging something may give you a hint what the issue is. Also, perhaps using strace or tcpdump to see if you can find out whether anything is actually getting to the daemon, and perhaps a basic "telnet" test to see if the port is open & responds, this is where I would start.

Quote from JoeAverage

I couldn't find out what the differences between the rsync version exactly were.

+++ correction +++

I couldn't temporary find...

network-tools version number's and the containing rsync version

LibreELEC.tv/changelog.txt at fc7984acc19d36613e4e1a2065537bcc45897261 · LibreELEC/LibreELEC.tv · GitHub

=> all network-tool version > 104 contain rsync version 3.2.3

=> all network-tool version < 104 contain rsync version 3.1.3

change logs (=>News), man pages, etc for the specific rsync version are here:

rsync

Not sure, but there are a couple of **root** changes in 3.2.0

• Added ‑‑copy-as=USER option to give some extra security to root-run rsync commands into/from untrusted directories (such as backups and restores).
• The default systemd config was made stricter by default. For instance, ProtectHome=on (which hides content in /root and /home/USER dirs), ProtectSystem=full (which makes /usr, /boot, & /etc dirs read-only), and PrivateDevices=on (which hides devices). You can override any of these using the standard systemctl edit rsync and add one or more directives under a [Service] heading (and restart the rsync service).
  

Would suggest using the debug options and trial / replicate what the synology is doing

Quote from heitbaum

The default systemd config was made stricter by default. For instance, ProtectHome=on (which hides content in /root and /home/USER dirs), ProtectSystem=full (which makes /usr, /boot, & /etc dirs read-only), and PrivateDevices=on (which hides devices). You can override any of these using the standard systemctl edit rsync and add one or more directives under a [Service] heading (and restart the rsync service).

This may be relevant for you, it appears to be a bug with glibc 2.32 (which is what LE 10 is using):

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

Newer glic versions provide a lchmod() that needs /proc mounted (their bug) · Issue #109 · WayneD/rsync · GitHub

26401 – Regressions in lchmod and fchmodat when /proc is not mounted

Arch is cherry picking these 2 commits on top of rsync 3.2.3, it seems:

+ # Force HAVE_LCHMOD off for Linux (for now).

+ git cherry-pick -n 85b8dc8abaca96fc3ea7421e09101b6ac41b6718

+ # Work around glibc's lchmod() issue a better way.

+ git cherry-pick -n 9dd62525f3b98d692e031f22c02be8f775966503

Quote from bg.lebowski

Okay, I post the rsync logs for two different systems ... one with LE 9.2.6 one with LE 10.0 ...

As a workaround, can you set in your rsyncd.conf:

use chroot = no

And see if that makes any difference?

Edit: Looking at the Fedora bug, it looks like "use chroot = yes" is the workaround. It's kind of confusing the way it is worded. But try both, I think "no" is the right option based on the Ubuntu description of the issue. My guess is this option is "yes" by default in rsync --daemon.