🚨 Linux Error Guide: 'cp: error writing: No space left on device' — Free Space and Finish the Copy

Overview

A copy that starts fine and then dies partway through is one of the most common storage failures on Linux. The classic form is cp running out of space on the destination:

cp: error writing 'dest/bigfile.img': No space left on device
cp: failed to extend 'dest/bigfile.img': No space left on device

Related mid-copy failures you will hit in the same situations include a source that vanished or is unreadable, and a hardware-level read failure part way through:

cp: cannot stat 'src/file': No such file or directory
cp: error reading 'src/file': Input/output error

All of these mean the copy did not complete: the destination now holds a truncated, corrupt file that must not be trusted.

Symptoms

• cp (or mv, tar, dd) prints No space left on device and exits non-zero after writing part of the data.
• df -h shows the destination filesystem at 100% (or df -i shows inodes at 100% even though bytes look free).
• A partial file exists at the destination but its size is smaller than the source.
• cp: error reading ... Input/output error appears with matching blk_update_request or I/O error lines in dmesg — a failing disk.
• rsync leaves behind hidden .filename.XXXXXX temp files where interrupted transfers were written.

Common Root Causes

• Destination filesystem genuinely full — the target partition ran out of free blocks mid-write.
• Inode exhaustion — copying millions of tiny files fills the inode table before the byte capacity; df -h looks fine but df -i is at 100%.
• Filesystem size limits — copying a file larger than 4 GB onto a FAT32/vfat USB stick fails regardless of free space.
• Quota limits — the user or group hit a disk quota (Disk quota exceeded) rather than a truly full disk.
• Sparse file expansion — a sparse source (e.g. a VM image) is copied without --sparse, expanding zeroes into real blocks and overflowing the target.
• Source disappeared or unreadable — a file was deleted or a mount dropped during the copy (cannot stat), or the drive is failing (Input/output error).

Diagnostic Workflow

Check bytes and inodes on the destination filesystem — inode exhaustion is the silent one:

df -h /path/to/dest
df -i /path/to/dest

Compare source size against destination free space before retrying:

du -sh /path/to/src
du -sh --apparent-size /path/to/src   # true size for sparse files

Find what is consuming the destination filesystem:

sudo du -xsh /var/* 2>/dev/null | sort -rh | head
sudo find / -xdev -type f -size +500M -printf '%s\t%p\n' 2>/dev/null | sort -rn | head

If the error was an I/O error, check the kernel ring buffer for hardware failure:

dmesg -T | grep -iE 'i/o error|blk_update_request|medium error'
sudo smartctl -a /dev/sdX | grep -iE 'reallocated|pending|health'

Check the destination filesystem type and any quota that applies to you:

stat -f -c '%T' /path/to/dest    # e.g. msdos/vfat = 4 GB file limit
quota -s 2>/dev/null; repquota -a 2>/dev/null | head

Example Root Cause Analysis

An admin copies a 6 GB database dump to a USB stick and sees cp: error writing 'db.sql': No space left on device at exactly the 4 GB mark. df -h /media/usb reports 20 GB free, so the disk is clearly not full. Running stat -f -c '%T' /media/usb returns msdos — the stick is formatted FAT32, whose maximum file size is 4 GB minus one byte. The copy stopped at the hard filesystem limit, not at a capacity limit.

The fix was to reformat the stick as exFAT (sudo mkfs.exfat /dev/sdb1), which has no practical single-file limit, then re-copy. The lesson: No space left on device is ENOSPC, and ENOSPC covers filesystem-imposed limits and inode exhaustion as well as a literally full disk. Always confirm with df -i and stat -f before assuming you simply need a bigger drive.

Prevention Best Practices

• Pre-flight large copies: compare du -sh of the source against df -h free space (and df -i inodes) on the destination.
• Use rsync -aP instead of cp for large or long-running transfers so an interruption can be resumed and progress is visible: rsync -aP src/ dest/.
• Add --sparse (rsync) or cp --sparse=always when copying VM images and other sparse files to avoid expanding zero blocks.
• Match the destination filesystem to the data: use exFAT/ext4/xfs for files over 4 GB, never FAT32.
• Monitor filesystems and alert at 85% on both bytes and inodes; inode exhaustion is invisible to byte-only alerts.
• Verify copies of critical data with sha256sum on both ends before deleting the source.

Quick Command Reference

df -h /dest && df -i /dest                 # bytes AND inodes
du -sh src/                                # size of source
stat -f -c '%T' /dest                      # destination fs type (fat limits)
rsync -aP --sparse src/ dest/              # resumable, sparse-aware copy
dmesg -T | grep -i 'i/o error'             # hardware read failures
sudo find / -xdev -size +500M 2>/dev/null  # biggest files on one fs
sha256sum src/file dest/file               # verify integrity

Conclusion

A copy that fails part way through almost always traces back to ENOSPC — and ENOSPC means more than a full disk: exhausted inodes, filesystem file-size limits, and quotas all raise it. Check df -h, df -i, and stat -f before retrying, switch to rsync -aP for anything large so you can resume, and treat any Input/output error as a possible failing drive to investigate with dmesg and smartctl. Confirm the destination has room the copy needs, and verify integrity afterwards so you never ship a truncated file.