I'm using "Bash on Ubuntu on Windows", from a Windows 10 Pro PC, to backup my media library to a FreeBSD server that acts as my NAS (it runs NAS4Free). This used to work perfectly but it recently stopped to work. Since I haven't changed anything on my side I reckon the change came from one of of the Windows Updates, not sure.

In any case, here's what happens. Just after a few files got copied over, the rsync transfer just hangs. I've let it run overnight to confirm and it just hangs for hours. When I manually kill the task by sending CTRL + C to the terminal I get an error message, some time goes on (about 30 secs) and the program stops:

arnaud@CLAVAIN:~$ rsync -arv --delete --no-compress /mnt/e/Music/ arnaud@nas4free.lan:~/pool1/lolilol/music
arnaud@nas4free.lan's password:
sending incremental file list
ost/Luke Cage (Original Soundtrack Album)/
ost/Luke Cage (Original Soundtrack Album)/40. Finding Chico.m4a
ost/Luke Cage (Original Soundtrack Album)/41. I Am Carl Lucas.m4a
ost/Luke Cage (Original Soundtrack Album)/42. Crispus Attucks.m4a
ost/Luke Cage (Original Soundtrack Album)/43. Hideout.m4a
ost/Luke Cage (Original Soundtrack Album)/44. Cuban Coffee.m4a
ost/Luke Cage (Original Soundtrack Album)/45. Like a Brother.m4a
ost/Luke Cage (Original Soundtrack Album)/46. Cottonmouth's Clamp.m4a
ost/Luke Cage (Original Soundtrack Album)/47. Survival.m4a
ost/Luke Cage (Original Soundtrack Album)/48. Cottonmouth Theme.m4a
ost/Luke Cage (Original Soundtrack Album)/49. Luke Cops.m4a
ost/Luke Cage (Original Soundtrack Album)/50. Crushin' On Reva.m4a
ost/Luke Cage (Original Soundtrack Album)/51. Beloved Reva.m4a
^Crsync error: unexplained error (code 130) at rsync.c(632) [sender=3.1.0]
[sender] io timeout after 60 seconds -- exiting

You can see where the ^C is, that's when I send the kill message. This is when the "error: unexplained error" and "io timout" errors show up.

I have tried an alternate command, rsync -rltvzD --progress --delete, but that produces the same error.

Is there anyway I could troubleshoot this better to understand what the problem is? Note that if I do this on a local drive (like a USB external drive) the rsync works just fine.

  • It appears that in respect of rsync, Windows Subsystem for Linux is defective in handling lists provided by rsync. This should be reported, and I have done. Mar 19 '17 at 23:33
  • Do you have the issue # on Github for this issue? There were several other issues opened with regards to rsync, all fixed, but those didn't solve my issue.
    – Astaar
    Mar 29 '17 at 9:05
  • This looks like the issue discussed here on the WSL BashOnWindows Github Page: github.com/Microsoft/BashOnWindows/issues/2138
    – Gerald
    Sep 3 '17 at 16:59
  • interestingly for me, if i ctrl-z background it, then fg foreground it, rsync will continue until it hangs on another file. it doesn't seem to be related to large files, and -W didn't resolve this for me.
    – rev
    Jul 27 '19 at 16:17
  • same for me... any idea?
    – jlanza
    Nov 29 '19 at 15:54

I had this issue as well recently (as in yesterday), and what I found out, is that when I rsync without delta copy (using --whole-file/-W for whole file transfer), then everything works perfectly.

I know it is not the best solution, but a quick fix for now until it is patched.

  • 1
    This was the fix for me as well, works flawlessly with -W, even with -z -v etc Dec 20 '17 at 5:25
  • 1
    I can verify yet another case where this is correct. Ubuntu 18.04 under WSL on 1809. This should probably be the accepted answer/workaround. Dec 11 '18 at 0:45
  • 2
    This issue hit me today. It's still not fixed.
    – Defcronyke
    Mar 23 '20 at 19:02

I have the same problem. It only happens while rsyncing large files. I've come up with a workaround:

When a file stops transferring, I cancel it and then rsync whatever file stopped. For whatever reason, rsyncing the individual file always works. I usually have to do this for a few files before the original rsync goes through.

Super annoying, but I don't have any other solutions outside of not using the Ubuntu Bash under Windows 10, which would be disappointing.

My setup: rsyncing between Ubuntu running under Windows 10 and digitalocean's ubuntu server.

  • I've since given up on rsync under Windows Bash. I now use unison to sync the files and have had no more hangs. Oct 9 '18 at 0:07

It is quite possible that the change in behaviour is due to a Windows Update and it changing the default permissions or disabling a feature during the update and not turning on properly again. Microsoft's solution for other errors is to disable and re-enable WSL.

If you are sure you haven't changed anything, and if it still doesn't work after disabling and re-enabling WSL from "Windows Features" you might want to post it as a bug/issue on Microsoft's github, https://github.com/Microsoft/BashOnWindows/issues

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.