/usr/bin/rsync returned 255 while processing user@server on Linux. How to fix it?

Linux
, ,
1

I ran my script which depends upon rsync, but it says rsync returned 255 while processing. See

~/bin/pusfile.sh script returned error:
user@serverA:/home/ ERROR: /usr/bin/rsync returned 255 while processing user@serverA:/home/
user@serverA:/var/spool/cron/ ERROR: /usr/bin/rsync returned 255 while processing user@serverA:/var/spool/cron/
user@serverA:/usr/share/ ERROR: /usr/bin/rsync returned 255 while processing user@serverA:/usr/share/

What is the meaning of 255 code? How can I fix it? I have rsync installed on remote server.

2

I think your OpenSSH server is rejecting the connection from your client. rsync works over ssh, and that is what 255 means. Check your firewall log and make sure TCP port 22 open on the server. Also, look into OpenSSH log file such as /var/log/secure on RHEL/CentOS and /var/log/auth.log on Ubuntu/Debian.

Is TCP port 22 open?

Verify by running the following command from your client:

ssh -v user-name@server-name
nc -z -v server-name ssh

If not open tcp port 22 (or whatever port configured) using your firewall.

1 Like
3

Funny enough, Linux firewalls are down by default, so this must be loooong after the refusing machine was setup.

1 Like
4

Alright I fixed it. We have a firewall running for EC2 host and it was blocking our static IP. Two days back I made some changes and by accident i removed my static IP. Once I allowed static IP my using security group I was able to work without problem. This is the one thing i hate about command line. they never give detailed log instead we get some code like 255. what does that even mean?

5

So this happened last year. One of my clients’ CentOS 7 Linux servers stopped working for both sftp and rsync jobs. This Linux server used to keep medical records and job would pull files daily. But, rsync would return a different error as the connection refused, and rsync would give out a code number. Even I couldn’t log in using ssh. My first thought sshd process must be dead or overloaded. I used out-of-band management to get a console. Guess what? The server IP address was DDoS’d, and all sockets were used. Long story short, we had to put the IP address behind the Anti-DDoS service. After that, we hide the server behind the VPN and made it invisible. A sysadmin cannot merely predict from error codes without looking into the server console and log files. You will always find different scenarios, and we have to investigate to fix the problem.