I’ve been trying to do an rsync copy from a remote machine (Mac 10.6.x) to my local machine (Ubuntu 12.04.x). I’ve been doing dry runs (
-n option) using something similar to this:
rsync -ani [email protected]:/Users/username1/Dropbox/ /home/username2/Dropbox/
(I’ve changed the hostname and usernames to be generic.) For hours, I was getting errors. I don’t have the messages, but they looked like:
rsync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(342)
which I have copied from here.
So, how did it go away? All I did was put in the following basic rsyncd.conf file in /etc (the file did not exist before):
#maximum allowed connections
max connections = 2
#where to log
log file = /var/log/rsync.log
timeout = 300
Other weird things I discovered:
- Adding the rsyncd.conf file that specified a log file doesn’t actually result in that log file being written to. Maybe only error messages are written to that file, and only when you’re running rsyncd instead of rsync, but I kinda thought if creating this configuration file fixed my problem that something would be written to the log file.
- When I try to recreate the problem by removing rsyncd.conf, the problem doesn’t come back.
--log-fileoption creates a log file that doesn’t have every line that comes out of stdout. Thus, if you want the full output of
-ioption), you won’t get it. Better to go with tee:
rsync -ani [email protected]:/Users/username1/Dropbox/ /home/username2/Dropbox/ | tee logfile
which sends a copy of the output to logfile, in addition to stdout.
- You can get a:
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [generator=3.0.9]
error if the filenames are too long. This is problem on the Mac end, I think, so if you create filenames that are really long on the Linux end, if you copy it to the Mac end, you’ll have problems.