When doing a backup with rscync to a USB stick, I sometimes get for one or another file the error message

rsync: [receiver] write failed on (FILENAME) : No space left on device (28)
rsync: [sender] write error: Connection reset by peer (104)

I'm using the command

rsync -ra -T /tmp --delete FROM_DIR TO_DIR  --info=del

This is weird, because the USB stick has a reported capacity of 235 GB, of which 79 GB are available. The data being backed up has a total size of about 100 GB, and each individual file is below 300 MB, most of them about 3-5 MB. During the backup process, most of the files have not changed between the original and the backup; just a few dozen ones actually need an update, but of course it could be that rsync always writes all files in this scenario (since the backup is not done over the network).

Can this type of error messages be explained with my settings, or do I have to assume that the USB stick is faulty?


The source for the backup is on an external hard disk (i.e. rsync copies some of the directories from one external disk to the backup device).

The errors occur only when the backup device is this particular USB-stick. When I use for the backup another external hard disk (which has much more free space), there is never a write error.

Since all other parameters are the same (source disk, disk for temporary files), the only "real" difference is that the device which causes less problems, happens to be a USB device, and it has much less free space than the other backup devices (hard disks, SSD).

I would like to find out if the amount of free space in the USB-stick could be the explanation for the error (and why), or if I need to assume that the USB stick is faulty (how can I check this?).


I did the following rudimentary checks for the quality of the USB-stick:

  1. Running the Windows utility CHKDSK ... /r

  2. Running the external utility FakeFlashTest in the non-destructive mode. In this mode, it calculates the free space as reported by the USB drive (which roughly matches the one I got before), and then creates a a file of exactly this size, thereby filling up the drive.

Both tests went well without error. From this, I tend to conclude that there is something in the way rsync is operating, which makes it necessary to have much more space at the destination drive available than a single file would occupy.

1 Answer 1


From rsync : write failed - No space left on device (28) :

I had the same issue, the destination directory had enough space but I'd get "No space left on device". Turns out rsync copies the file to somewhere else first, then moves it to the destination directory. To change this behavior, use --inplace.

According to https://download.samba.org/pub/rsync/rsync.html "This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file."

 rsync --inplace source destination

A pity that the developers of rsync didn't include the partition name in the message. Many users of rsync were stymied by this very vague message.

  • I don't think this applies to my case. This would matter if a single file would be transfered whose size is larger or equal of the free space in the destination directory. However even the largest file to be copied occupies much less than 1% of the free space. Mar 29, 2023 at 6:33
  • The free space on which disk? The rsync destination?
    – harrymc
    Mar 29, 2023 at 7:37
  • Correct. The source (an external hard drive) has more than one TB available. The local disk (which is referred to by the -T option of rsync), is pretty full, but nevertheless still has more than 4 GB available, which should be sufficient for this purpose. Mar 29, 2023 at 7:39
  • 1
    There have been several posts on our site where the space on the external disk was plain wrong. Usually it's smaller than the rated capacity, but in your case it might be larger. Some cases could be fixed with updating the disk's firmware and some not. Check if the disk manufacturer has such a utility, you could also try to reformat the disk, check the SMART attributes of the disk (if it has it)), but I can't think of anything else.
    – harrymc
    Mar 29, 2023 at 8:10
  • 1
    You could try --inplace. I don't have more suggestions.
    – harrymc
    Mar 29, 2023 at 12:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .