Something eating up diskspace

Question

Somehow, something is eating up around 80GB of HDD space and I cannot figure out what. This is starting to become a major problem for me as I only have 100GB to play with and if I find something to delete, something else will just fill that space, until I can barely use the computer.

I have tried running ncdu -x -q to clear up as much as possible and it says that I am down to about 22G usage. I get the same with du, but I guess ncdu uses du

du -x -d1 -h /
4,0K    /srv
28K     /media
4,0K    /mnt
4,0K    /lib64
16K     /lost+found
3,3G    /home
588M    /opt
360M    /lib
23M     /build
9,7M    /bin
48M     /boot
27M     /etc
1,4G    /root
4,0K    /cdrom
6,9G    /usr
16M     /sbin
9,0G    /var
22G     /

And if I run df:

 df
Filesystem      1K-blocks       Used Available Use% Mounted on
udev              2748080          4   2748076   1% /dev
tmpfs              559400       1568    557832   1% /run
/dev/sdc2       109481872  104180864         0 100% /
none                    4          0         4   0% /sys/fs/cgroup
none                 5120          0      5120   0% /run/lock
none              2796996        688   2796308   1% /run/shm
none               102400          8    102392   1% /run/user
overflow             1024        236       788  24% /tmp
/dev/sdd2      1953382140 1874376664  79005476  96% /media/munhunger/Shaman
/dev/sda1      1953382140 1926088316  27293824  99% /media/munhunger/Holy
/dev/sdb1      2930264060 2930264060         0 100% /media/munhunger/Glory

df -aTh
Filesystem     Type             Size  Used Avail Use% Mounted on
sysfs          sysfs               0     0     0    - /sys
proc           proc                0     0     0    - /proc
udev           devtmpfs         2,7G  4,0K  2,7G   1% /dev
devpts         devpts              0     0     0    - /dev/pts
tmpfs          tmpfs            547M  1,6M  545M   1% /run
/dev/sdc2      ext4             105G  103G     0 100% /
none           tmpfs            4,0K     0  4,0K   0% /sys/fs/cgroup
none           fusectl             0     0     0    - /sys/fs/fuse/connections
none           debugfs             0     0     0    - /sys/kernel/debug
none           securityfs          0     0     0    - /sys/kernel/security
none           tmpfs            5,0M     0  5,0M   0% /run/lock
none           tmpfs            2,7G  688K  2,7G   1% /run/shm
none           tmpfs            100M  8,0K  100M   1% /run/user
none           pstore              0     0     0    - /sys/fs/pstore
overflow       tmpfs            1,0M  236K  788K  24% /tmp
binfmt_misc    binfmt_misc         0     0     0    - /proc/sys/fs/binfmt_misc
systemd        cgroup              0     0     0    - /sys/fs/cgroup/systemd
gvfsd-fuse     fuse.gvfsd-fuse  0,0K  0,0K  0,0K    - /run/user/1000/gvfs
/dev/sdd2      fuseblk          1,9T  1,8T   76G  96% /media/munhunger/Shaman
/dev/sda1      fuseblk          1,9T  1,8T   27G  99% /media/munhunger/Holy
/dev/sdb1      fuseblk          2,8T  2,8T     0 100% /media/munhunger/Glory

Running du with sh flag(and x because I do not want to scan mounted disks)

du -xsh /
22G     /

What could be causing this, and what can I do to mitigate the problem? Running on a linux mint 17 from uname -a: 3.16.0-38-generic #52~14.04.1-Ubuntu

From running lsof | grep -Fw deleted:

lsof | grep -Fw deleted
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.

Answer 1

Very similar to Jesse_b's answer, what has worked well for me over the years is simply:

df -xk / | sort -n | tail -40

The -x option to df instructs it not to traverse other mount points. Using -k keeps all the sizes in 1024 byte blocks. The output gets sorted and I tend to like looking at the last 40 lines, but this is purely arbitrary. This should point you to a directory containing the files taking up the most space. If you want files in the output, change the df command to df -axk before piping to sort and tail.

Answer 2

You can try this to find where the large file(s) may be but beware this command may be very long running depending on the number of files in your system:

du -k / | sort -nr | head -n25

Here are my results:

[root@JBCLAMP001 ~]# du -x -d1 -h /
512     /boot
512     /system
81M     /var
2.9M    /root
1.0K    /opt
512     /srv
512     /mnt
512     /media
3.0K    /tmp
20M     /home
15M     /etc
5.0K    /native
981M    /usr
1.1G    /

[root@JBCLAMP001 ~]# du -sh /
du: cannot access ‘/proc/45795/task/45795/fd/3’: No such file or directory
du: cannot access ‘/proc/45795/fd/3’: No such file or directory
du: cannot access ‘/native/proc/45795/fd/3’: No such file or directory
du: cannot access ‘/native/proc/45795/path/3’: No such file or directory
8.7G    /
[root@JBCLAMP001 ~]# du -xsh /
1.1G    /

As you can see the du -x -d1 -h / does not find all files.