Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've used from some time rsync/ssh to backup my shared host contents to my personal Synology NAS (212j for that matter), and it worked quite well. For information, I use a password-less ssh connection.

3 days ago, I updated my NAS software and since (or at least I believe it's since that), the backup won't work anymore. I get the following error on the host:

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only 

..which I do not understand. beside that nothing changed that I know of in both source and destination that can be related to rsync or ssh, I did check a few things and all seems to be alright:

  • I can still connect through ssh from the host to my NAS with the good user, so ssh stuff like keys haven't changed.
  • I also have the correct file permissions on the NAS (I checked, and also tried to create files, directories, .. with the user used by rsync through ssh).

I read here and there that the error means that I have to ensure that my rsyncd.conf have the right read only = no in it, but as far as I know, I never used rsyncd as well as I never configured anything for it and until now it worked like a charm..

I use the following command to do the backup:

rsync -ab --recursive \
--files-from="$FILES_FROM" \
--backup-dir=backup_$SUFFIX \
--delete \
--filter='protect backup_*' \
$WDIRECTORY/ \
remote_backup:$REMOTE_BACKUP/

So I'm stuck and really can't figure out what happened.


Edit:

As suggested in comments, I also tried passing commands to ssh (but not from inside a ssh session), that worked as expected, and also tried a single rsync command, which didnt worked, failing just like the complete backup command.

(sharedHost):hostuser:~ > touch test.txt
(sharedHost):hostuser:~ > rsync test.txt remote_backup:backups/test.txt
ERROR: module is read only
rsync error: syntax or usage error (code 1) at main.c(1034) [Receiver=3.0.8]
rsync: connection unexpectedly closed (9 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]

and

(sharedHost):hostuser:~ > ssh remote_backup 'touch /abs_path_to_backups/backups/test2.txt && echo "ProoF" > /abs_path_to_backups/backups/test2.txt'
(sharedHost):hostuser:~ > ssh remote_backup 'cat /abs_path_to_backups/backups/test2.txt'
ProoF
share|improve this question
    
Try doing the remote update tests, but with commands given to ssh on the command line instead of through a ssh login session. Also be sure the target space is not full. –  Skaperen Sep 8 '12 at 17:23
    
Thanks for your suggestions. I edited the question with their result. Also, the target space is not full at all (I was already sure, but I checked again) –  user978548 Sep 10 '12 at 12:41

5 Answers 5

up vote 11 down vote accepted

I had the same problem after updating my Synology NAS to DSM 4.1. I also do rsync over SSH. In my situation using rsync user root@ip also worked but left the files on the server with owner root which I did not want.

I found in the NAS admin userinterface, that for some reason in ControlPanel->Users->MyRSyncUser->Edit->"Priviliges setup" there was no read/write access to the homes. My RSYNC destination is under the homes.

Setting this to privilidge worked for me. I hope this helps.

share|improve this answer
    
Thank you so much ! That worked ! Next time I update DSM, I'll double-check the permissions.. –  user978548 Oct 11 '12 at 22:39
3  
This seems to work if I use full path names (i.e., rsync something nas:/volume2/homes/foo/bar/ instead of rsync something nas:bar/). –  Jukka Suomela Dec 14 '13 at 22:37
    
full path was the last step for me in annoying bout of debugging. thanks! –  joevallender Jun 5 at 15:30

I encountered the same problem after upgrading a synology ds1010+ to dsm 4.1-2661.

I don't have the time to understand what happened to the rsync provided by synology but it does not seem standard. So here is my workaround...

I didn't want to hack the privileges (multi-user setup), so I've recompiled rsync in static on my laptop, then I've transfered the binary on the sinology nas.

wget https://rsync.samba.org/ftp/rsync/rsync-3.0.9.tar.gz
tar xzvf rsync-3.0.9.tar.gz
cd rsync-3.0.9
export CFLAGS=--static
./configure
make

scp rsync <login>@<nas_hostname>:

You can tell rsync to use your new binary instead of the default one, with this parameter:

--rsync-path=<myhome>/rsync

Now I can continue using duplicity with rsync, by adding the following parameter to duplicity:

--rsync-options="--rsync-path=<myhome>/rsync"
share|improve this answer
    
This is what I did with my DS212j, except I used ipkg to install the new rsync. Synology's directions for installing ipkg are here. –  Jason Jun 9 '13 at 19:42

I had the same kind of issue, but I wasn't using a dedicated user for rsync.

I had to fix privileges in Control Panel -> Shared folders.

share|improve this answer

I had similar issue while connecting to Synology 211j over Putty's ssh. I had to enable

"Control Panel -> Network backup -> Enable network backup service".

It is working now.

share|improve this answer

I got it working by logging in as root instead of admin or regular user.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.