Recently I have been unable to rsync over ssh. Each time I get the same error

bash: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

I am running

sudo rsync -av /var/www/html/somedir/ myuser@999.999.99.9:Users/myuser/Desktop/ec2backup

Please note the username, IP, and directories have been changed for the purposes of this post.

In the past I have ran the exact same command as verified using bash_history.

What I have tried:

  1. Ran a similar command from another server, resulting in the same error message.
  2. Tested rsync locally (local dir to local dir), which worked perfectly.

The only thing that has changed is I've recently installed Virtualbox and Vagrant. Is it possible I may have messed up authentication/ports/etc on my local machine?

Any help is greatly appreciated.

  • I had a lot of mysterious rsync problems along these lines that wound up being caused y large hidden files . Once deleted, rsync started working normally again Jun 14, 2021 at 12:31

10 Answers 10


rsync is not installed on 999.999.99.9

  • 999.999.99.9 is my local, I verified it was installed even tested by locally rsync a directory.
    – TucDev990
    Aug 29, 2018 at 15:38
  • The error message is clear : rsync is missing either on source , or on destination. I don't know what you mean by local. Source is where you have /var/www/html/somedir , and in my definition that would be the local ( since you clearly are logged to that machine ) . Destination is myuser@999.999.99.9 , which would be the remote side, since you are trying to reach that via SSH Aug 29, 2018 at 16:28
  • run rsync --version and ssh myuser@999.999.99.9 "rsync --version" , and see which returns command not found Aug 29, 2018 at 16:30
  • rsync --version rsync version 3.0.6 protocol version 30 When I do ssh myuser@999.999.99.9 "rsync --version" I get bash: rsync: command not found . What I mean by local is when I am on my local machine (999.999.99.9) I can run rsync and rsync --version returns rsync version 2.6.9 protocol version 29
    – TucDev990
    Aug 29, 2018 at 17:11
  • Then i guess the rsync binary is not in 'myuser' path. Try a which rsync when on local machine ( 999 ), that should give a path ( like /usr/local/bin/rsync ), then add the full name to rsync command with 'rsync-path', something like sudo rsync -av --rsync-path=/usr/loca/bin/rsync /var/www/html/somedir/ myuser@999.999.99.9:Users/myuser/Desktop/ec2backup Aug 29, 2018 at 19:35

my problem was that I was using cwrsync_6.2.1_x64 in conjunction with SSH_for_Windows_7.7p1, LibreSSL 2.6.5 that was preinstalled in win10 2004 build 19041.685.

in your rsync command, you need to point to the ssh.exe that comes with that specific rsync build. For example:

rsync -avHz -e "path_to\cwrsync_6.2.1_x64_free\bin\ssh.exe" --partial ...
  • Thank you, this solved my issue too
    – MrCarrot
    Mar 13, 2021 at 12:06

I got this error error when the target directory didn't pre-exist. With a source data file: /a/b/c/d/data, rsync -av -e ssh /a/b/c/d/ hostname:/a/b/c/d needs the target directory: hostname:/a/b/c to pre-exist.

In reading the man page as a last resort I see that this is the intended behavior.


With the exception of the rsync: command not found you might get 12 Error in rsync protocol data stream if the remote (ssh) user requests a password change. I.e on an expired password - even if you use ssh keys.

Got that exact error message in a backup script, and when manually logging in to the remote server - from the backup server - I got this:

WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user logs.
Changing password for logs.
(current) UNIX password:

Either set the new password, or remove password expiry rules. ymmv - and check with your admin if your not it.

On the remote server:

chage -l logs ; chage -I -1 -m 0 -M -1 -E -1 logs ; chage -l logs

I got this error in rsync protocol data stream (code 12) for a pair of rsync's with different versions.

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 (using brew) and that fixed the problem.

  • I suspect it wasn't this error you were getting, but a similar one. In this one, there's only a sender=3.0.6, with no server=. I suspect your error was more similar to that listed in stackoverflow.com/q/56721446
    – Mathieu K.
    Oct 3, 2020 at 3:45

Using cygwin, I did a 'which rynsc' and the result was the rsync provided by the cygwin setup program. I had previously installed rsync through Cygwin setup. However, when I did, from Cygwin, 'which ssh', it was pointing to the ssh of the Windows path. So, I exited Cygwin, executed the cygwin setup program and installed ssh from cygwin. After I did that, I did the same two previous commands again (which rsync and which ssh) and both binaries were pointing to the cygwin binaries. Then when I did my rsync from cygwin, it worked without any issue at all.


When I get this error, it is usually because the path on the remote server is invalid or does not exist. mkdir -p fixes it up.


Rsync must be installed in both servers, origin and destine.


Lack of permissions to access the remote directory caused the same error.

on the server

~# sudo -u ubuntu ls -l /opt/aws/opsworks/current/
   ls: cannot access /opt/aws/opsworks/current/: Permission denied

on the client

$ rsync --dry-run -v -r --checksum ./ ubuntu@
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.2/rsync/io.c(453) [sender=2.6.9]

I was getting a similar error on macOS when trying to rsync from macOS to Ubuntu. Both had the same version of rsync, but it turned out ssh server was not installed on Ubuntu. To install it:

sudo apt install openssh-server
  • While this may have resolved your specific problem, there is nothing to indicate this answer will resolve the problem described in the question.
    – Paul
    Apr 27, 2021 at 15:16
  • Of course. Which is true for all the other answers here.
    – lenooh
    Apr 27, 2021 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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