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.

  • Is it possible that even by writing zero bytes to your file you might still be over the quota?
    – scrowler
    Sep 16, 2015 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, 2015 at 1:00
  • @JoshGribbon of course it is. Easy example that you have 5gb of data stored, your sysadmin changes your limit from 10gb to 2gb. You now have to delete 3gb of files to be at your limit again, but by the sounds of it the system won't let you delete anything because it in turns needs to write something somewhere.
    – scrowler
    Sep 16, 2015 at 1:04
  • 4
    may be your rm is aliased
    – YOU
    Sep 16, 2015 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, 2015 at 2:01

4 Answers 4


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, 2018 at 6:26
  • The idea of opening a text file and deleting the content was genius!
    – Stefano
    May 8, 2020 at 21:07

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 {} \;
  • 5
    Curious. How is that any different to the straightforward /bin/rm FILENAME that has been stated as not working? Sep 23, 2015 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. Sep 23, 2015 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, 2017 at 17:49

You must log in to answer this question.