Read-only file system

If you get "Read-only file system" as an error when sending to a rsync daemon then you probably forgot to set "read only = no" for that module.


copies every file

Some people occasionally report that rsync copies every file when they expect it to copy only a small subset. In most cases the explanation is that you forgot to include the --times (-t) option in the original copy, so rsync is forced to check every file to see if it has changed (because the modified time and size do not match).

If you think that rsync is erroneously copying every file then look at the stats produced with -v and see if rsync is really sending all the data.


is your shell clean

The "is your shell clean" message and the "protocol mismatch" message are usually caused by having some sort of program in your .cshrc, .profile, .bashrc or equivalent file that writes a message every time you connect using a remote-shell program (such as ssh or rsh). Data written in this way corrupts the rsync data stream. rsync detects this at startup and produces those error messages. However, if you are using rsync-daemon syntax (host::path or rsync://) without using a remote-shell program (no --rsh or -e option), there is not remote-shell program involved, and the problem is probably caused by an error on the daemon side (so check the daemon logs).

A good way to test if your remote-shell connection is clean is to try something like this (use ssh or rsh, as appropriate):

ssh remotemachine /bin/true > test.dat

That should create a file called test.dat with nothing in it. If test.dat is not of zero length then your shell is not clean. Look at the contents of test.dat to see what was sent. Look at all the startup files on remotemachine to try and find the problem.


memory usage

Yes, rsync uses a lot of memory. The majority of the memory is used to hold the list of files being transferred. This takes about 100 bytes per file, so if you are transferring 800,000 files then rsync will consume about 80M of memory. It will be higher if you use -H or --delete.

To fix this requires a major rewrite of rsync, which my or may not happen.


out of memory

The usual reason for "out of memory" when running rsync is that you are transferring a _very_ large number of files. The size of the files doesn't matter, only the total number of files.

As a rule of thumb you should expect rsync to consume about 100 bytes per file in the file list. This happens because rsync builds a internal file list structure containing all the vital details of each file. rsync needs to hold structure in memory because it is being constantly traversed.

A future version of rsync could be built with an improved protocol that transfers files in a more incremental fashion, which would require a lot less memory. Unfortunately, such an rsync does not yet exist.


rsync through a firewall

If you have a setup where there is no way to directly connect two machines for an rsync transfer, there are several ways to use the firewall machine to act as an intermediary in the transfer.

Method 1

Use ssh to access the intermediary system and have it ssh into the actual target machine.

To effect this extra ssh hop, you'll need to configure a authorization method that does not involve any user interaction (such as prompting for a password). The easiest way to do this is to setup an ssh key (see the ssh-key manpage). You can encrypt this key (which requires a passphrase to unlock it) as long as you have ssh-agent forwarding enabled -- this allows the ssh connection between the intermediary system and the target machine to authorize without a passphrase prompt because the authorization information is coming from your local machine via the ssh protocol (which has the benefit of not making intra-system logins password-less in general). Another solution is to configure host-based authentication, which makes all logins between authorized machines automatically authorized (which may or may not be something that you are comfortable with).

You should then test that the forwarded ssh connection works without a prompt by running a command like this:

ssh inter ssh target uptime

If you get a password/passphrase prompt to get into the intermediary system that's fine, but the extra hop need to occur without any extra user interaction.

Once that's done, you can do an rsync copy like this (one pull, one push):

rsync -av --rsync-path="ssh target rsync" inter:/source/ /dest/
rsync -av --rsync-path="ssh target rsync" /source/ inter:/dest/

These commands looks like they are copying to/from the "inter" host, but the remote-rsync command that we it to run performs the extra hop to the real target system and runs the rsync command there.

Method 2

Install and configure an rsync daemon on the target and use an ssh tunnel to reach the rsync sever.

Installing the rsync daemon is beyond the scope of this document, but see the rsyncd.conf manpage for more information. Keep in mind that you don't need to be root to run an rsync daemon as long as you don't use a protected port.

Once your rsync daemon is up and running, you build an ssh tunnel through your intermediary system like this:

ssh -fN -l userid_on_inter -L 8873:target:8873 inter

What this does is cause a connection to port 8873 on the local system to turn into a connection from the intermediary system to the target machine on port 8873. (Port 8873 was chosen instead of the normal 873 port number because it does not require root privileges--use whatever port number you like.) The -N option tells ssh not to run a command on the remote system, which works with modern ssh versions (you can run a sleep command if -N doesn't work). The -f option tells ssh to put the command in the background after any password/passphrase prompts.

Now when an rsync command is executed with a daemon-mode command-line syntax to the local machine, the conversation is directed to the target system. For example:

rsync -av --port 8873 localhost::module/source dest/
rsync -av rsync://localhost:8873/module/source dest/

rsync and cron

On some systems (notably SunOS4) cron supplies what looks like a socket to rsync, so rsync thinks that stdin is a socket. This means that if you start rsync with the --daemon switch from a cron job you end up rsync thinking it has been started from inetd. The fix is simple—just redirect stdin from /dev/null in your cron job.


rsync: Command not found

This error is produced when the remote shell is unable to locate the rsync binary in your path. There are 3 possible solutions:

  1. install rsync in a "standard" location that is in your remote path.
  2. modify your .cshrc, .bashrc etc on the remote machine to include the path that rsync is in
  3. use the --rsync-path option to explicitly specify the path on the remote machine where rsync is installed

You may echo find the command:

ssh host 'echo $PATH'

for determining what your remote path is.


spaces in filenames

Can rsync copy files with spaces in them?

Short answer: Yes, rsync can handle filenames with spaces.

Long answer:

Rsync handles spaces just like any other unix command line application. Within the code spaces are treated just like any other character so a filename with a space is no different from a filename with any other character in it.

The problem of spaces is in the argv processing done to interpret the command line. As with any other unix application you have to escape spaces in some way on the command line or they will be used to separate arguments.

It is slightly trickier in rsync (and other remote-copy programs like scp) because rsync sends a command line to the remote system to launch the peer copy of rsync (this assumes that we're not talking about daemon mode, which is not affected by this problem because no remote shell is involved in the reception of the filenames). The command line is interpreted by the remote shell and thus the spaces need to arrive on the remote system escaped so that the shell doesn't split such filenames into multiple arguments.

For example:

rsync -av host:'a long filename' /tmp/

This is usually a request for rsync to copy 3 files from the remote system, "a", "long", and "filename" (the only exception to this is for a system running a shell that does not word-split arguments in its commands, and that is exceedingly rare). If you wanted to request a single file with spaces, you need to get some kind of space-quoting characters to the remote shell that is running the remote rsync command. The following commands should all work:

rsync -av host:'"a long filename"' /tmp/
rsync -av host:'a\ long\ filename' /tmp/
rsync -av host:a\\\ long\\\ filename /tmp/

You might also like to use a '?' in place of a space as long as there are no other matching filenames than the one with spaces (since '?' matches any character):

rsync -av host:a?long?filename /tmp/

As long as you know that the remote filenames on the command line are interpreted by the remote shell then it all works fine.


HP compile

For HPUX apparently you need to add the option -Ae to the CFLAGS. Edit the Makefile and change CFLAGS to:

CFLAGS=-Ae -O