25

I'm trying to rsync data from one ubuntu box to another, but whenever I try to run the command, I get the error,

error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]

I've seen people get io.c(600) and 610 errors in various other places around the web, but nothing about a 605 error. What's the cause of this issue? How can it be fixed?

The command i'm running is

/usr/bin/rsync -az -e /usr/bin/ssh user@remote:filename /path/to/local/filename
Jules
  • 14,200
  • 13
  • 56
  • 101
  • Got the same result when trying to "push" files to the server, but was able to "pull" them successfully from the server. Might be worth a try. – Oertls Dec 01 '16 at 16:13

11 Answers11

12

Make sure rsync is installed on remote server also.

Same issue was occurred but disappear after installing rsync on remote server. Without rsync on Remote server how it will work?

Dewlance
  • 441
  • 4
  • 7
  • As answered _three years ago_ and corroborated with a bug report, this was a bug in `rsync` itself. I also have no way of validating this answer as correct since the device from the question is no longer online. – Jules May 04 '17 at 02:19
  • 2
    Upvoted, a missing `rsync` on the remote host will also show this error message. – Florian Brucker May 17 '17 at 14:25
7

According to this it's an official bug. At the bottom of the page, one victim of the bug mentions he doesn't get it when the file he's trying to send is < 100 GB or when he uses the -W flag on the client (which indicates whole file copy, rather than rsync delta resolution; basically, turns rsync into little better than scp).

Parthian Shot
  • 1,390
  • 1
  • 13
  • 24
  • Would've spent much more time trying to fix this than implementing an alternative. Thanks! – Jules May 27 '14 at 22:51
  • I just encountered this--adding the -W flag didn't fix it. Turned out the directory/file permissions on the destination were insufficient. – karmakaze Oct 22 '16 at 02:48
7

I'm going for the stupid award here...

$ rsync -axv /source/path john@remotehost:/path/does/not/exist
john@192.168.1.10's password:
building file list ... done rsync: connection unexpectedly closed (8 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52.200.1/rsync/io.c(453) [sender=2.6.9]

The error was on my side. The remote path didn't exist. It took me a while to figure that out. I wonder why rsync can't report something like that.

SPRBRN
  • 2,406
  • 4
  • 35
  • 48
  • this was also my case: destination path did not exist – abu Dec 18 '20 at 22:14
  • or you've accidentally put a leading slash in dest:/Pictures rather than dest:Pictures – stevel Jan 09 '22 at 19:43
  • Same, there was a typo in my remote path and [this post](https://askubuntu.com/questions/625085/rsync-over-ssh-error-in-protocol-data-stream-code-12-ssh-works) led me to double checking my paths. – qwerty Apr 01 '23 at 21:56
6

I found that this error occurred when the hard disk drive of the target machine was full.

I found this after trying the accepted answer and getting the same error, so it might help someone for whom the accepted answer does not work. Clearly this is quite a specific answer and very easy to diagnose, so I do not presume that this error message is directly connected to a lack of space on the target.

M1ke
  • 6,166
  • 4
  • 32
  • 50
5

I got this error in rsync protocol data stream (code 12) for a pair of rsync's with different versions. So please check the rsync versions on both client and server.

In my case, local rsync was version 2.6.9 (on Mac OSX), while remote one was version 3 (can't remember now the exact version). Then I upgraded my local rsync to version 3 and that fixed the problem.

Gui Lima
  • 166
  • 1
  • 9
2

In my experience this error occurs because the local host does not yet have the remote host's key stored and ssh is rejecting the connection in background.

su - localUser -c "/usr/bin/rsync -avzh -e \"/bin/sshpass -p ${password} \
ssh -oPort=remotePort -l remoteUser\"  \
remoteServer:/remoteFolder /localFolder"

In the explained scenario, the above command fails with the error:

error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]

without prompting to accept the remote key.

To resolve the problem simply connect to the remote host manually via ssh as localUser, and when asked "Do you want to accept remote host key yes/no" select "yes".

Thereafter, running the full command above should work fine.

NOTE: if you are connecting to the remote using @[servername] and @[servername].[domainname] then the remote host key needs to be configured for both variants as explained above.

Pancho
  • 2,043
  • 24
  • 39
2

Permission denied, please try again. rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.2]

I had this error wit rsync from my ubuntu to Synology DS411j

  • protocol version was different but that was not problem
  • ssh was working

I fixed problem on Synology system (armv5tel) to allow user use rsync

Now it is working perfect!

user2308728
  • 91
  • 1
  • 2
1

I had the same error (on Debian Wheezy) along with a kernel oops. The -W flag suggested in the bug report mentioned in Parthian Shot's answer did not help. Also it wasn't SSH-related since the rsync was done locally.

The issue was due to errors on the filesystem. Correcting them with fsck solved the problem. (Be sure to check there are not remaining rsync processes.)

Skippy le Grand Gourou
  • 6,976
  • 4
  • 60
  • 76
1

This error occurred when uploading/updating files from a RHEL system (client) to a FreeBSD system (server). rsync did give a message about libiconv.so.3 that was required but not available. libiconv.so.3 was not on RHEL (client). rsync on RHEL (client) started and worked fine. Turned out the rsync install on FreeBSD (server) was broken. libiconv.so.3 was missing. As of that rsync on the FreeBSD system (server) was not able to start and causing the mentioned problem on the RHEL system (client). Reinstalling rsync on FreeBSD (server) solved the problem.

digitaldaemon
  • 141
  • 1
  • 2
  • I think the issue caused by a missing `rsync` install on the remote box is separate from what my question originally touched on (given that the error produced is different), and should be separated into its own thread. Site etiquette encourage you to ask _and_ answer your own questions if this is an original issue, which it seems to be. – Jules Sep 14 '17 at 13:16
  • Not a missing *rsync* install, but a broken *rsync* install. (Checking that it is installed gives a positive result). The actual error produced was very much alike if not exactly the same. The answer is yet an other variation to the problem that might help someone resolve a problem. – digitaldaemon Sep 19 '17 at 13:22
1

I will never ever ever understand!

I had this error:

rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [Receiver=3.1.3]

For this command to backup files from a server to a local machine (files deleted on the server will be deleted on the local machine):

rsync --update -vr --delete -e ssh --rsh='sshpass -p MYPASSWORD ssh -l www-prod -p 42' mydomain.com:/mnt/images/ /media/usb-Samsung/backup_prod/images_rsync >> /media/usb-Samsung/backup_prod/images_rsync_result.txt

I was trying to execute it as root on the local machine and was getting only the error mentioned above.

And by chance I tried from a "normal" user and it worked!

I will never understand why executed as root on the local machine it was not working whereas it's working executed as a simple user.

Dharman
  • 30,962
  • 25
  • 85
  • 135
London Smith
  • 1,622
  • 2
  • 18
  • 39
1

This seems to be a bit of a catch-all error as I got the same error trying to transfer a huge number of little files from one VM to another (300K+ files). The issue in my case was that of too little RAM available on the target VM. Bumped it from 2G to 8G and it is copying away happily.

Just wanted to add this in case someone else is facing the same issue.