on computer1 the log contains :
2025/02/25 20:44:27 [11665] building file list
2025/02/25 20:44:27 [11665] <f.st… rsync
2025/02/25 20:44:28 [11665] sent 590 bytes received 53 bytes 116,91 bytes/sec
2025/02/25 20:44:28 [11665] total size is 1,59K speedup is 2,47
2025/02/25 20:45:25 [11872] building file list
2025/02/25 20:45:25 [11872] <f+++++++++ log
2025/02/25 20:45:25 [11872] sent 258 bytes received 35 bytes 53,27 bytes/sec
2025/02/25 20:45:25 [11872] total size is 287 speedup is 0,98⏎
on computer2 rsync is not working , log shows :
2025/02/27 18:18:08 [28970] protocol version mismatch – is your shell clean?
2025/02/27 18:18:08 [28970] (see the rsync manpage for an explanation)
2025/02/27 18:18:08 [28970] sent 0 bytes received 0 bytes total size 0
2025/02/27 18:18:08 [28970] rsync error: protocol incompatibility (code 2) at compat.c(622) [sender=3.4.1]
❯ man rsync | grep -B 2 -A 14 mismatch
DIAGNOSTICS
Rsync occasionally produces error messages that may seem a little cryptic. The one that seems to cause the most confu‐
sion is "protocol version mismatch -- is your shell clean?".
This message is usually caused by your startup scripts or remote shell facility producing unwanted garbage on the
stream that rsync is using for its transport. The way to diagnose this problem is to run your remote shell like this:
ssh remotehost /bin/true > out.dat
then look at out.dat. If everything is working correctly then out.dat should be a zero length file. If you are get‐
ting the above error from rsync then you will probably find that out.dat contains some text or data. Look at the con‐
tents and try to work out what is producing it. The most common cause is incorrectly configured shell startup scripts
(such as .cshrc or .profile) that contain output statements for non-interactive logins.
If you are having trouble debugging filter patterns, then try specifying the -vv option. At this level of verbosity
rsync will show why each individual file is included or excluded.
What the man page is saying is check your login scripts (~/.bashrc, ~/.profile, or whatever shell-specific script may be in use) for commands that produce an output. For example, if there is an echo in there, that will do it.
If you are not sure, save these files to backup one at a time and re-try the rsync command each time.
Or, rework your scripts so they only run these commands if the the terminal is interactive as described here:
One of your login scripts (.bashrc/.cshrc/etc.) is probably outputting data to the terminal (when it shouldn’t be). This is causing ssh to error when it is connecting and getting ready to copy as it starts receiving extra data it doesn’t expect. Remove output that is generated in the startup scripts.
You can check if your terminal is interactive and only output text by using the following code in a bashrc. Something equivalent exists for other shells as well:
if shopt -q login_shell; then
[any code that outputs text here]
fi
or alternatively, like this, since the special parameter - contains i when the shell is interactive:
if echo "$-" | grep i > /dev/null; then
[any code that outputs text here]
fi
To diagnose this, make sure that the following is the output you get when you ssh in to the host:
USER@HOSTNAME's password:
Last login: Mon Nov 7 22:54:30 2011 from YOURIP
[USER@HOSTNAME ~]$
If you get any newlines or other data you know that extra output is being sent. You could rename your .bashrc/.cshrc/.profile/etc. files to something else so that they won’t output extra output. Of course there is still system files that could cause this. In that case, check with your sysadmin that the system files don’t output data.
my ~/.bashrc and /etc/bash.hashrc are the same on computer1 and also on computer2 !
it produces no output , no echo , … !
Normally i use fish shell.
If i use bash shell or sh shell i have the same problem !
if i use on computer1 ssh user@host2 : i have no problem !
If i use on computer2 ssh user@host1 : i have no problem !
Try connecting to computer2 with SSH, then run rsync --version to confirm the shell can find rsync.
Try also using a different protocol as described in the thread linked above.
However, if the test file is in fact 0 bytes, then your shell is behaving, but it is possible that you just have a very old version of rsync. You can tell the client end (assuming it is the newer end) to not advertise such a high version that the old rysnc server version doesn’t recognize it. You can do this using the --protocol= option. In my case, using --protocol=30 did the trick.