0

If shortly, when I submit my files to VPS from Ubuntu PC by Rsync, everything going well, however if I do the same thing from Windows, I get the 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]

Although unlike Linux, the Rsync is not installed as default for the Windows, I have installed it Rsync on my Windows PC.

enter image description here

Environment data

  • Local PC#1: Windows 10
  • Local PC#2: Ubuntu 20.04.5
  • VPS: Ubuntu 20.04

Preparations

I have initialized the VPS with clear Ubuntu. To eliminate some the variables from equations, I have done some things which should not be done at real (not experimental as in my case) VPS because of security.

  • I'll submit the data using the root account
  • I will not use the SLL

Also, I have created the /var/www/example.com directory at VPS to avoid the error about unable to sync the data because the destination directory has not been created.

Target

enter image description here

Submit the content of 06-ProductionBuild directory to VPS.

Experiment flow

On Windows terminal, input

rsync -azve ssh --progress 06-ProductionBuild [email protected]:/var/www/example.com

The password has been requested. After inputting the password got:

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]

enter image description here

If I just inputted the wrong password, the error was Permission denied, please try again.

Now same command from Ubuntu PC:

enter image description here

Everything was fine.

Please give me some hints.

Tried from WSL - it was fine. Looks like something wrong with Rsync from Windows.

enter image description here

Improve this question
6
  • Look through askubuntu.com/questions/625085/…. It looks like you can get this code 12 error if the remote folder doesn't exist, or if rsync was not installed correctly. Make sure the folder exists, and try reinstalling rsync. Make sure that powershell isn't treating some part of your path as special characters and eating them
    – Cpt.Whale
    Commented Feb 8, 2023 at 15:21
  • How exactly did you install rsync (mainly, where did you get it from)?
    – Tom Yan
    Commented Feb 10, 2023 at 5:56
  • @TomYan, thank you for the comment. I have installed it via chocolatey, the package manager for Windows.
    – Tokugawa Takeshi YD
    Commented Feb 10, 2023 at 10:48
  • Download complete CygWin and don't use this standalone stuff.
    – zomega
    Commented Feb 11, 2023 at 17:57
  • @zomega Thank you for the recommendation. After installing the Cygwin, can I invoke the rsync from the normal windows terminal somehow? I need to do it for automation.
    – Tokugawa Takeshi YD
    Commented Feb 12, 2023 at 1:14

1 Answer 1

Reset to default
1
+50

Apparently this is because you would be using the "system" ssh program (native build of OpenSSH from Microsoft) when you specify just -e ssh. (More precisely, it's probably because the PATH precedence of the bin directory of the (cw)rsync installation is lower than the other path in concern).

In my test the simpliest workaround is to specify -e /bin/ssh instead, which will make rsync use the (cygwin) ssh that comes with it. (The cygwin "magic" should automagically resolve the root of the path for you, chocolatey or not.)

Credit (of discovering the cause) goes to the comment here, although the approach offered there seems unnecessarily clumsy. (Well, unless you have reason to use the ssh build from Microsoft.)

EDIT: actually the explanation given in the linked correct does not seem exactly true to me. In my test, the "system" ssh would indeed use known_hosts at a different location, but it prompts me to add the server to the list as well when I try to connect with it for the first time and created its own known_hosts successfully. It didn't ask me in the later attempt either so apparently it CAN find its own one to read back. Therefore I have no idea how his suggestion helped him and specifying the option/path doesn't work for me anyway.

Improve this answer
3
  • I can't thank you enough. -e /bin/ssh has work. No one suspected the native build of OpenSSH for a long time.
    – Tokugawa Takeshi YD
    Commented Feb 26, 2023 at 3:54
  • Are the separate commands for Windows and UNIX-like systems are unearthly?
    – Tokugawa Takeshi YD
    Commented Feb 26, 2023 at 4:08
  • 1
    It's not really about UNIX-like vs Windows. It's really just about the location of the ssh executable and the PATH env var. If you prepend that location to PATH so that is before the the location of the native/system ssh, you then will not need -e /bin/ssh.
    – Tom Yan
    Commented Feb 26, 2023 at 5:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .