16

It turns out rsync can't work with a remote server which has a .bashrc file?

At local client i got when run rsync:

protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(180) [sender=3.0.7]

As suggested here removing the .bashrc on server solved the problem. How to solve it without removing the .bashrc file (temporarily)?

|improve this question
  • 1
    Check if ssh is enabled for that account. – Lamy Jan 4 '13 at 9:22
  • The below answers are likely incorrect. I recently started getting this error after a routine Ubuntu upgrade, even though nothing changed in my .bashrc files. – Cerin Feb 19 '13 at 19:30
  • No - if removing the .bashrc file fixes it (as was stated in this question), then the problem is output from the .bashrc. An upgrade could certainly introduce an actual protocol incompatibility, which is an entirely different issue. – Randall Aug 1 '13 at 16:42
21

You can run into problems if the .bashrc on the remote server outputs anything to the terminal. Rsync may not expect that and may have problems as a result.

You can fix this by removing any commands in the .bashrc that output text, or by piping any output to /dev/null.

|improve this answer
  • 3
    So how to pipe any output to /dev/null if i can only modify files on client? – Computist Aug 23 '11 at 15:02
  • 1
    I suppose you could as your system administrator for assistance. You may also be able to modify files on the server in another way, such as FTP or scp. – Greg Hewgill Aug 23 '11 at 19:37
  • Yeah my .bashrc file contained an echo "*** Starting ROOT Shell ***" and echo "(Please use sudo instead of a root shell whenever possible!)". Removing those echos fixed the problem. – Kentgrav Apr 12 '16 at 14:46
  • 1
    From the rsync man page: "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 the out.dat file. If everything is working correctly then out.dat should be a zero length file. – Kentgrav Apr 12 '16 at 14:51
8

The .bashrc is really not the correct place for generating output, as it causes this kind of problem. A lot of people get away with it, though, until they try to run rsync :-)

Any desired output (and the associated logic and commands) should be moved to your .bash_profile (see, e.g., Server Fault question ".profile vs. .bash_profile vs. .bashrc" for further discussion on the differences between the files).

That way, you won't need to sacrifice getting the output when you login, nor deal with making temporary changes to your .bashrc when you want to use rsync.

|improve this answer
6

I've always had .bashrc files on my user accounts and never had this problem until I tried today to rsync something to my server using the root account. Your post helped me find the solution:

my $user/.bashrc files always start with the following section to prevent this kind of issue. I replicated it to root's .bashrc and rsync'ing now works like a charm!

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

HTH, karsten

|improve this answer
  • This does usually not work for rsync, because it is for whatever reason classified as "interactive shell". But it's a good line to add anyway, because it might screw up non-interactive shells otherwise if there is any output. – Michael Schubert Aug 18 '15 at 17:11
  • I think this is the best solution to the question. The accept answer "removing any commands in the .bashrc that output text" is not practical. – Qinsi Jul 27 '18 at 5:47
4

For complex reasons rsync/scp/sftp runs .bashrc when connecting to another host. You must have any of these commands at the top of your .bashrc:

either

[[ $- != *i* ]] && return

or

[ -z "$PS1" ] && return

Any of the above commands will only allow the execution of the rest of .bashrc commands for interactive sessions. As far as I know you don't need them for any other type of session (and indeed I have seen default bashrc from Arch and Debian using this technique in their bashrc).

If however you want to be extra paranoid about letting your bashrc commands run even for non interactive sessions you should at least wrap the commands of your bashrc that do produce output like this (reference) so that they only run in interactive sessions:

if shopt -q login_shell; then
    # this is an interactive session, we _can_ display output
    ...code that produces output goes here...
fi

Note that others suggest moving commands that output text to your bash_profile but I have my doubts about whether this is always good (for reasons explained here)

|improve this answer

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.