I am using Ubuntu 12.04 and can't write to any file, even as root, or do any other operation that requires writing. Neither can any process that needs to write, so they're all failing. df says I've got plenty of room:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   14G   15G  48% /
udev            984M  4.0K  984M   1% /dev
tmpfs           399M  668K  399M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            997M     0  997M   0% /run/shm

All of the results I find for "can't write to disk" are about legitimately full disks. I don't even know where to start here. The problem appeared out of nowhere this morning.

PHP's last log entry is:

failed: No space left on device (28)

Vim says:

Unable to open (file) for writing

Other applications give similar errors.

After deleting ~1gb just to be sure, the problem remains. I've also rebooted.

df -i says

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/xvda1     1966080 1966080      0  100% /
udev            251890     378 251512    1% /dev
tmpfs           255153     296 254857    1% /run
none            255153       4 255149    1% /run/lock
none            255153       1 255152    1% /run/shm
  • 14
    Please post the output of "df -i".
    – EEAA
    Commented Oct 25, 2015 at 16:27
  • 1
    @EEAA edited in. You're right, df -i says 100%. What does this mean? Why would it be different?
    – felwithe
    Commented Oct 25, 2015 at 16:29
  • 3
    IIRC, too many files in a single directory will have similar if not identical symptoms. What "too many" is will vary between file systems.
    – MSalters
    Commented Oct 26, 2015 at 9:02

2 Answers 2


You are out of inodes. It's likely that you have a directory somewhere with many very small files.

  • 9
    Just wanted to add that I didn't even know rm could fail. This has been an education.
    – felwithe
    Commented Oct 25, 2015 at 18:23
  • 2
    @felwithe, I can imagine that find . -name sess\* -exec rm {} + would have worked.
    – Carsten S
    Commented Oct 25, 2015 at 21:51
  • 3
    @felwithe What others have suggested. rm probably worked fine, but the shell expanded the * glob into far too much data, and barfed before it even got to the point of invoking rm.
    – user
    Commented Oct 26, 2015 at 8:20
  • 8
    @CarstenS: Or find . -name sess\* -delete which I find easier to remember, and is generally more efficient.
    – MSalters
    Commented Oct 26, 2015 at 9:01
  • 2
    @Kaslai the limit there is not RAM, but the system limit ARG_MAX. The POSIX standard doesn't specify precisely how command line arguments are measured against ARG_MAX unfortunately. Some implementations have no limit and so do not define ARG_MAX, but this is not a popular option as it makes too many programs fail to compile. Commented Oct 26, 2015 at 18:18

Apparently, the OP has an answer for their particular problem. However, for completeness, the OP's symptoms can also occur if the filesystem has been remounted read only. This has happened to me using a Linux VM whose storage was on a clustered disk system suffering rare intermittent faults. Occasionally, the faults would cause the filesystem(s) to be remounted read only. The eventually observable external symptom was various services becoming nonresponsive as RAM filled (with unflushable disk writes).

At the time, the only resolution was to reboot the system (losing whatever unwritten logs there were). Attempts to remount RW failed. (Unfortunately, I do not recall the error messages returned when attempting these remounts.)

So, ..., not the OP's problem, but someone else arriving on this page may benefit from this information.

  • 5
    No actually; when the filesystem has been remounted read only you get an error that states the filesystem is read only, not out of space.
    – psusi
    Commented Oct 25, 2015 at 23:18
  • 1
    @psusi : I did not. I got various errors, including "filesystem full". If that has changed in the last two or three years, that would be a good thing. Commented Oct 26, 2015 at 3:53
  • 1
    I tried to move a file into a read-only ZFS file system on Linux just the other day. The error quite clearly said "read-only file system".
    – user
    Commented Oct 26, 2015 at 8:22
  • Nope; been that way for 30+ years. A write to a read only fs returns -EROFS; a write to a full fs returns -ENOSPC.
    – psusi
    Commented Oct 26, 2015 at 17:43
  • 4
    @psusi : I see that you live in the fantasy universe where programmers always do the right thing instead of making up their own error messages. I don't seem to live there. Commented Oct 27, 2015 at 4:39

You must log in to answer this question.

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