On November 10, 2014, I updated my Synology NAS boxes (DS214se) to the latest DSM (DSM 5.1-5004). Next day, I found that the Network Backup jobs scheduled in Task Scheduler were failing (I’m backing up shared folders from one box to another on the LAN). Unfortunately, in the logs that can be viewed under Backup & Replication / Logs, it just says „Information … Backup task started“, followed by „Error … Failed to backup task“, without details what caused the failure. Before the DSM update, Network Backup jobs worked without issues.
Synology support seems to be overwhelmed by tickets; I filed one on Monday, and got a reply on Wednesday that they’ll take 3 to 5 business days to get back to me. (Normally, the turnaround is more like < 1 day.)
So, googling, and then logging on to the source box via SSH. (The source box is the one where the data come from, and where the Network Backup jobs are run from the Task Scheduler.) Inspecting the rsync error log unveils this:
zeus> tail /var/log/rsync.error Nov 11 02:00:23 (20726) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] Nov 11 02:15:05 (20907) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] Nov 11 02:30:05 (21091) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] Nov 11 02:45:05 (21272) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] Nov 12 02:00:23 (15542) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] Nov 12 02:15:05 (15722) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9] ...
The dates look right. In the error log, there aren’t any service is no running entries before November 11 (the day after I did the DSM update). Looks like rsyncd (the rsync daemon) isn’t running.
What the error lines don’t tell, and that took quite some more googling to find out, is that this is related to rsyncd on the target machine (the NAS where the backups end up). So I looked at the settings on the target machine, and voilà — the Enable network backup service checkbox wasn’t ticked. Ticking it, and then starting the Network Backup job manually on the source machine yielded success.
I can’t tell if it worked without the checkbox being ticked before the DSM update, or if the DSM update unticked the checkbox. In any case, Network Backup works again now, and I can sleep better again. 🙂
Quoi de neuf ? 
Thank you, Stefan. Your post solved my issue with rsync, which Synology’s support line did not solve.
I have the same problem. But checking „enable network backup“ did not solve it.
Can you please tell me how you start the rsyncd manually?
regards Hartmut
I don’t know how to do that. On my old Synology NAS boxes, I had IPKG installed, which more or less made the box behave like a real Linux machine. I try to stay away from stuff that’s not packaged with DSM 5 with my new boxes, though — I found that using stuff like IPKG causes too many maintenance headaches in the long run, that’s why.
Anyway, I *think* that disabling the SSH service in the DSM control center, then enabling it again, should restart rsyncd, too.
Your problem might be caused by the fact that the target box (the one you’re transferring data to) doesn’t allow access from the source box (where the data come from, and where you’re running the rsync command on).
In the target box’s Control Panel (Systemsteuerung in German), under Shared Folders (Gemeinsame Ordner), make sure that the user running rsync on the source machine has permissions to write. Check the rsync.error log (see blog post) on the source machine to see if an error shows up to that effect.
Hope this is helpful!
Thanks for your answer. The problem ame up ater update to dsm 5.1.
what I can see:
ps | grep rsync gives me:
29056 root 30144 S /usr/syno/bin/rsync –daemon
doing from my windows machine, (ds1 is my syno ds 412+)
rsync -r rsync://Rsync@ds1
shows my shared folders, for ex. music
But doing
rsync -r rsync://Rsync@ds1/music
gives error: @ERROR: service disabled
In my shared folders for service/module/folder music, I have under „berechtigung“ read/write enabled for the user Rsync and other users.
So, what acn I do?
Everything worked perfectly with dsm 5.0.x
regards Hartmut
Sorry, Hartmut, for that I’d have to dig deeper into the logs.
My suspicion is that this is related to SSH ciphers. See my blog post on November 14 (https://sejh.wordpress.com/2014/11/14/). Rsync failed from my Android, and since the app developer refused to update the app to newer SSH ciphers, I had to find a new app to back up my photos from the mobile.
It’s a good thing that Synology’s recent DSM update removed some old and insecure ciphers, but unfortunately the release notes under https://www.synology.com/de-de/releaseNote/DS214se don’t tell you that. So, with computers or devices/apps that use old insecure ciphers, you’re cut off all of a sudden.
If that’s the problem you’re facing, I’d suggest to see if there’s an update available for your Rsync on Windows. (You learn a new thing every day; I wasn’t aware that rsync would run on Windows!)
Thanks for your reply. I want to make my situatoin more clear.
I am running win7 x 64 pro on 3 machines and start here scheduled backup jobs, which call rsync (using cygwin’s rsync). I want to backup certain dirs on my Sno NAs 412+.. The way I call it does not use ssh but it is via rsync daemon:
rsync rsync://Rsync@ds1/music , which is
rsync://<user|@/dest. (see man rsync)
There is a user Rsync with admin rights, and the password for the user is held in the env-var RSYNC_PASSWORD.
I am using rsync 3.09 protocol 30 on windows machine and same version on syno. I am calling rsync this way from my own written perl-scripts, which handle the generations of backups. The problem is independent from perl, so for testing the following lines where qwritten on the commandline.
what is strange to me is:
the command
rsync rsync://Rsync@ds1
shows all my available modules/destinations:
—
I:\>rsync rsync://Rsync@ds1
music System default, music mp3
…. (and others)
—–
but the following command gives an error:
—-
I:\>rsync rsync://Rsync@ds1/music
@ERROR: service disabled
rsync error: error starting client-server protocol (code 5) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/main.c(1516) [Receiver=3.0.9]
——-
And I have no idea how to switch on the service. The problem came up with DSM 5.1, everytghing worked fine with DSM 5.0.x and even dsm 4.3.x since more than 1 year.
regards
Hartmut
Right, the „service disabled“ error is what I got with the Rsync Backup app on Android, after updating the Synology boxes to DSM 5.1. Read my article to understand what the underlying issue is.
BTW, I don’t think there’s an rsync protocol (rsync://), but maybe that’s just my ignorance, and there is in fact one. From what I know, rsync is always via SSH (ssh://), so rsync:// might just be a „wrapper“ or something which actually means SSH.
In any case, I’m pretty much convinced that the problems you’re facing have the same underlying cause as the problems I was facing (and not able to solve, unfortunately) with Rsync Backup. In other words, it’s not so much about SSH or rsync versions, but rather about the SSH ciphers you’d be able to use. Here are the available ciphers on my „destination“ box (after the upgrade to DSM 5.1; I suspect that before there were additional ones):
hera> pwd; cat syno_sshd_config
/etc/ssh
Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
as I understand you, you also could not fix the problem? So we are two (at least).
BTW-1 my is empty:
> ls -s /etc/ssh/syno_sshd_config
0 /etc/ssh/syno_sshd_config
BTW-2: here is a copy of man rsync on my win7-machine:
Access via remote shell:
Push: rsync [OPTION…] SRC… [USER@]HOST:DEST
Access via rsync daemon:
rsync [OPt..] SRC… rsync://[USER@]HOST[:PORT]/DEST
which is, what I use.
rsync –help on syno has the following line:
rsync [Op]… SRC [SRC]… rsync://[USER@]HOST[:PORT]/DEST
So I believe it is not justa wrapper, but a differnet method. As I understand, the rsync-daemon must be already running in this case.
BTW-3: I called he german syno-support, who could not help, but told me it is a well known problem and they want to call me back 😉
… perhaps they find a solution.
regards Hartmut
Okay, so this shows how much I know of rsync. Indeed, it’s not just a program, but also a protocol by the same name (see https://en.wikipedia.org/wiki/Rsync).
I couldn’t fix my rsync problems, because they were actually caused by the Rsync Backup app — it relies on outdated, insecure ciphers. I cannot blame Synology for fixing that.
Good luck getting this sorted out on your machine(s)!
Hartmut Bartels asked me to post this comment on his behalf:
In some way I solved my problem and want to let you know. Perhaps you
want to put it in the blog.
What I did (because synology did not answer, I continued to try):
I switched off IPv6 for the LAN (for me it is LAN2 on my ds412+).
And now the command
rsync rsync://@ds1/music
works fine for all my modules/destinations.
But to be honest, I do not know why. There seems to be a
conflict IPv4 IPv6. Anyway my perl-skript runs happily the rsync-jobs.
—-
How to switch off IPv6: (german version of DSM 5.1):
systemsteuerung->netzwerk->netzwerkschnittstelle, LAN 2 auswaehlen,
druecken, IPv6 abschalten.
dito fuer LAN1.
—–