Rsync error 23

Dutch Master · 01-07-2012, 10:59 PM

A few days ago I had to abort rsync the hard way, by shutting down the machine it was running on (as I was late for work...), in the middle of syncing and since then it gives me an error 23 (that is: partial transfer due to error). Doh, I knew that already. However, I can't seem to find a way to resolve this, I already re-sync'd the directory it was chewing on at the time of the interruption, but to no avail. Effectively, how do I tell rsync to stop looking for the files it wants to sync? I've tried the man-page but it doesn't seem to have anything related in it and a www search on the net showed up some threads, but no solutions (as did a search here on LQ).

Before the intervention rsync worked fine and permissions haven't changed, so I doubt that'll be a cause...

TIA!

jv2112 · 01-08-2012, 05:36 AM

I would delete the destination and then try

Code:

rsync -avzt source destination ( add e option & ssh if remote)

Not exactly clear as to the current error.

If this does not work please post more specifics as to current error when an attempt is made.

Hope this helps.

Dutch Master · 01-08-2012, 08:58 AM

Thanks for your reply. I use rsync with the -rdtvu options to a destination on my network via a trusted-key ssh connection. Deleting the destination will be a PITA to restore, given that's about 40 GB in size, with some 350,000 files, so it would take quite a while, even with the Gbit network I have... I'll give it a try though...

Skaperen · 01-08-2012, 03:54 PM

If I had an rsync operation to redo because it was previously interrupted, I would generally do this:

Code:

rsync --stats -aHPSv -B8192 /my/source/directory/. user@desthost:/my/destination/directory

I generally skip doing compression unless I have a slow network. Compression leaves me with a speed ceiling slightly less than 100mbps, so things can go faster w/o it on a local LAN, especially a gigabit one. Over the internet, compression is usually a definite plus.

I use -H to maintain original hardlinking relationships. Otherwise the target could end up using more space.

I use -S to make sparse files where lots of binary zero bits exist in the files.

I use the /. suffix on the source to ensure I don't get a duplication of the tree inside itself. Normally / alone should do this, but I've had cases where it failed to. But /. has always worked for me.

I use the --stats option for fun.

Sometimes things can get stuck when the destination has a non-empty directory where a non-directory exists in the source. It seems rsync is paranoid about deleting the directory on the destination just to move a file or symlink in its place.

Dutch Master · 01-08-2012, 05:35 PM

Thanks for chipping in

I did remove the destination folder, then re-sync'd the lot using the -ardtvuz options. Took well over 5 hrs to get everything over... The error I get is:

Code:

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7]

3.0.7 was probably a directory containing the 3.0.7 kernel (I'm now on 3.1.3, compiled from source on Debian Squeeze) but it's no longer on the source side (don't know why, can't recall compiling a 3.0.7 kernel, but I did a 3.0.0-rc7 once...) nor anywhere else on my systems...

So, it all comes down to convincing rsync to give up on the 3.0.7 directory, but I can't find anything related?

Bertical · 01-09-2012, 07:43 PM

Looking at the source code for rsync ( in log.c ) shows that the number in the square brackets at the end of the error message is the version of rsync. Error 23 is defined in errcode.h as a "partial transfer". I would rerun rsync and the log file should show which file caused the problem ( use --log-file=FILE ).

Dutch Master · 01-09-2012, 07:46 PM

Ah, I didn't know that. Thanks! I'll rerun rsync with the log-file option then

[edit: bingo, found the culprit:

Code:

rsync: readlink_stat("/home/<user>/.local/share/Trash/expunged/501191218/sessionstore.json") failed: Stale NFS file handle (116)

Unfortunately, I can't seem to remove it as it keeps getting back... I'll try via the terminal and if required as root... BRB!]
[edit2: rm can't remove it, it complains about a stale NFS file handle, even as root it won't budge! So, in effect this turns from an rsync problem into an NFS issue... Great! :-\ (NOT!!!)]

mfoley · 03-02-2014, 08:57 PM

This is a old thread, but didn't actually have a resolution and still has relevance. I have found that on large files (14G-ish or more) the z option (compress) messes up the transfer. I've had the exact symptoms as the poster happen on a few computers and removing the -z option solved the problem. Generally, I'm transferring .tgz files, so I really don't need compression. I don't know if the latest version of rsync has solved this problem, but as of 3.0.8, removing the -z option did the trick.