When administering Linux systems I often find myself struggling to track down the culprit after a partition goes full. I normally use du / | sort -nr but on a large filesystem this takes a long time before any results are returned.

Also, this is usually successful in highlighting the worst offender but I've often found myself resorting to du without the sort in more subtle cases and then had to trawl through the output.

I'd prefer a command line solution which relies on standard Linux commands since I have to administer quite a few systems and installing new software is a hassle (especially when out of disk space!)

  • 1
    @Bart thanks for taking the time to improve posts here, but may I ask you to take a little more care when adding tags? Tags aren’t for visibility, they describe the question. The disk tag isn’t appropriate here (see its tag description), and the at least two of the tags you added in this suggested edit weren’t appropriate there (Kali isn’t Debian, and there are no PPAs involved). – Stephen Kitt Jun 26 '19 at 10:02
  • I am in exactly the same situation and am also looking for a commandline solution. However, I do want to point to filelight (KDE, Linux and Windows) or baobab (Gnome), which (much like DaisyDisk on macOS) give an awesome graphical radial visualization. If you do have a graphical environment, they give additional comfort! – hans_meine Jun 8 '20 at 11:06

38 Answers 38


You can use DiskReport.net to generate an online web report of all your disks.

With many runs it will show you history graph for all your folders, easy to find what has grow

  • This tool doesn't match two main points of the question "I often find myself struggling to track down the culprit after a partition goes full" and "I'd prefer a command line solution which relies on standard Linux commands" – ndemou Jun 9 '17 at 10:35
du -sk ./* | sort -nr | \
awk 'BEGIN{ pref[1]="K"; pref[2]="M"; pref[3]="G";} \
     { total = total + $1; x = $1; y = 1; \
       while( x > 1024 ) { x = (x + 1023)/1024; y++; } \
       printf("%g%s\t%s\n",int(x*10)/10,pref[y],$2); } \
    END { y = 1; while( total > 1024 ) { total = (total + 1023)/1024; y++; } \
          printf("Total: %g%s\n",int(total*10)/10,pref[y]); }'



I can't take credit for this, but I found it just yesterday:

$ find <path> -size +10000k -print0 | xargs -0 ls -l

link text


Here's the best method I've found:

cd /
find . -size +500000 -print

Identify the problematic filesystem and then use -xdev to only traverse that filesystem.


find / -xdev -size +500000 -ls

There is a nice piece of cross-platform freeware called JDiskReport which includes a GUI to explore what's taking up all that space.

Example screenshot:
JDiskReport screenshot

Of course, you'll need to clear up a little bit of space manually before you can download and install it, or download this to a different drive (like a USB thumbdrive).

(Copied here from same-author answer on duplicate question)

  • Can't run Java on Linux? – WBT Mar 7 at 23:09
  • The OP asked for a CLI version – Angel Mar 8 at 2:22
  • OP said that was preferred, not required; questions closed as duplicates of this don't have the same preference. – WBT Mar 9 at 1:24

I realise that this thread is quite old, but nonetheless, very pertinent in any setup today and beyond. While all have offered excellent options to track down the disk hogs, what caught my attention was your statement "...I often find myself struggling...". It looks like you have to battle this symptom frequently. I would take a step back and see how you can prevent this. A precautionary measure will involve two steps:

  1. Alerting
  2. Action on the filesystem

As an example, when the FS hits 90%, you can set up an alert via Email to inform users about this situation. Or, you can Email yourself about it. A cron job can check the status at 5-min intervals.

Next, when it hits, say, 98%, you can run a script to set the FS readonly. This won't hurt much as it will go ro in a short while. But the advantage of setting an FS ro before 100% is that the user(s) can delete files when write is restored. While on this, there is a bug in some older versions of Solaris that will crash the system in the event of an FS hitting 100%, but we will leave it for another day.


The simplest is to change your current directory to / and execute :

du -chs / | sort -h
  • 1
    Using du -s means this will print a total size for / and nothing else. – sourcejedi Jun 7 '17 at 7:24