In bash (and over ssh) running rm FILENAME gives the error: rm: cannot remove 'FILENAME': Disk quota exceeded. I've seen the other posts (and everyting down the first page of google) on this topic and have tried:

echo "" > FILENAME
cp /dev/null FILENAME
cat /dev/null >FILENAME

and all give the same error. This has happened to me once before and one of the things above fixed it, but for whatever reason that isn't working this time. Is there some sort of more powerful method to remove or write 0 bytes to a file?

I don't have sudo access on the system. This is on a unix system.

migrated from stackoverflow.com Sep 23 '15 at 10:15

This question came from our site for professional and enthusiast programmers.

  • Is it possible that even by writing zero bytes to your file you might still be over the quota? – Robbie Averill Sep 16 '15 at 0:58
  • This site is for questions about computer programming, not how to use your operating system. When you ask elsewhere, I strongly recommend that you indicate which operating system it is that you're using. – dfeuer Sep 16 '15 at 0:58
  • @RobbieAverill I didn't think it was possible to be that much at the limit, but that probably is a possibility – Josh Gribbon Sep 16 '15 at 1:00
  • 4
    may be your rm is aliased – YOU Sep 16 '15 at 1:06
  • 1
    also if your FILENAME is 0 bytes or less than a block in file system, then echo, cp, cat won't make it better, try finding bigger files that can delete and use those. – YOU Sep 16 '15 at 2:01

Something is trying to write to your disk. This error usually occurs with network disks.

Try opening a text file, delete contents and save it. Using this command to re-check disk space:

df -h
  • I had the same issue (huge log files on a network drive). Thanks a lot. – Guillaume Mar 29 '18 at 6:26

I had the same problem, and none of the usually suggested solutions, the ones you list, worked.

But I realized that it was possible to delete the smallest files < 1kb. I just had to find enough small files to be able again to clean up large ones with rm.


For me, I solve the problem by overwriting some exsisted small files on the disk. Specifically, python will do. Once the disk has some free space (say 1M), rm will recover.


Go into the directory with FILENAME and run the command

find . -name "FILENAME" -exec $(which rm) -rf {} \;
  • 4
    Curious. How is that any different to the straightforward /bin/rm FILENAME that has been stated as not working? – roaima Sep 23 '15 at 13:33
  • 1
    @roaima I've found that running rm through find gives me different errors when stuff like this happens (usually when I mess up environmental variables in bash by running a wild script or the like). I see the community doesn't approve of the suggested solution, but I will wait until Josh tries it and gives feedback before deleting it. – user1717828 Sep 23 '15 at 14:05
  • @user1717828 While rm may be aliased, /bin/rm is not and your command is trictly equivalent to /bin/rm as noted by roaima. – xhienne Sep 10 '17 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy