Rsync creates error message unexplained error (code 255) at io.c(837)

Question

When I try to rsync -qaPH source/ 192.168.1.21:/var/backups I get

rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(837) [sender=3.1.0]

Whats wrong with my command?

Answer 1

To investigate, add one or more -v options to the rsync command. Also, try to use plain ssh:

ssh -v 192.168.1.21 /bin/true

to find out whether it is rsync or the underlying ssh connection that is causing the trouble.

Answer 2

Broken pipe error most likely means that you've hit the timeout. For example the remote rsync command started to calculate the file differences, but it didn't replied to the client on time.

If this happens very often, add these settings to your local ~/.ssh/config:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 6

and on the remote server (if you've got the access), setup these in your /etc/ssh/sshd_config:

ClientAliveInterval 30
ClientAliveCountMax 6

See: What the options ServerAliveInterval and ClientAliveInterval mean?

Answer 3

255 is actually not a "native" rsync return code. rsync scrapes the 255 error code from SSH and returns it. It looks to me like something on the destination server is blocking SSH or breaking it once it's connected, hence, "broken pipe". I disagree with @kenorb because if it were a timeout issue you would probably be seeing rsync exit codes 30 or 35.

Answer 4

I got the 255 error when rsnapshot using rsync encountered the situation "The ECDSA host key for foobar has changed". The rest of the error message included "POSSIBLE DNS SPOOFING DETECTED" and "REMOTE HOST IDENTIFICATION HAS CHANGED".

I had recreated my server and so the fingerprint had changed. I removed the ECDSA key (ssh-keygen -f "/home/bruce/.ssh/known_hosts" -R "foobar") and agreed to the new one when I sshed into foobar again.

ssh -vvv foobar gave me the info I needed to see this issue.

Answer 5

Anyone who comes across this error suddenly, it possibly could be because of your UFW (firewall).

I used a setup that adds ufw limit ssh and that limits only 6 connections within a 30 second time (standard).

I noticed this because our deploy scripts were constantly hitting the server with a series of commands + with rsync's and reaching the limit.

To avoid the SSH limit, insert a rule BEFORE the ssh limit with your server IP. This will stop it refusing the connection and allowed it to connect as normal. You can do this with:

ufw insert 1 allow from 10.10.10.10 to any port 22 proto tcp

Obviously change 10.10.10.10 for your server IP.

This will insert the rule before the rate limit and wont refuse the connection anymore.

Repeat the same rules for as many IPs you need.

ufw status will show the rules in order of priority, so hopefully now your server rule is before the ssh limit and will connect as normal with no issues.

Answer 6

I had the same issue. Here are my outputs.

[host2]$ rsync --delete -ahlxvzKHS --stats <host1>:/<folder_name>/* /<folder_name>/
Host key verification failed.
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(228) [Receiver=3.2.3]

Root cause: the handshake between host1 and host2 hasn't been done. This can be solved by attempting a ssh session manually as follows.

[host2]$ ssh host1
The authenticity of host 'host1 (XX.XX.XX.XX)' can't be established.
ED25519 key fingerprint is SHA256:**************************************.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'host1' (ED25519) to the list of known hosts.
root@host1's password: 
Last login: Tue Jan 16 11:16:33 2024 from 172.22.102.203
[host1]#

After this you can run your rsync using keys or password.

[host2]$ rsync --delete -ahlxvzKHS --stats <host1>:/<folder_name>/* /<folder_name>/
Number of files: 89,770 (reg: 61,076, dir: 28,694)
Number of created files: 50 (reg: 50)
Number of deleted files: 0
Number of regular files transferred: 50
Total file size: 292.13G bytes
Total transferred file size: 8.95M bytes
Literal data: 8.95M bytes
Matched data: 0 bytes
File list size: 855.26K
File list generation time: 0.035 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 30.42K
Total bytes received: 12.64M
sent 30.42K bytes  received 12.64M bytes  5.07M bytes/sec
total size is 292.13G  speedup is 23,062.83
[host2]$

Answer 7

I know this issue is old, but maybe someone (like me) still have the error.

a) Check if the ssh service is running:

sudo service ssh status

b) Check the connection with triple verbose command:

ssh -vvv <hostname>

c) Maybe you use the wrong ssh-key or the key is broken in some way.

Vine

Answer 8

I had a similar error using rsync via my deploy for an Ember app (ember-cli-deploy). I had to configure correctly my ssh (add private keys to my ~/.ssh/)