0

Following is the output of df -h on my system.

Filesystem      Size  Used Avail Use% Mounted on
udev             63G     0   63G   0% /dev
tmpfs            13G   18M   13G   1% /run
/dev/sdc4       822G  801G     0 100% /
tmpfs            63G   64M   63G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            63G     0   63G   0% /sys/fs/cgroup
/dev/nvme1n1p2   96M   75M   22M  79% /boot/efi
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs            13G   88K   13G   1% /run/user/1000

Using du -xsch /home, I get the following:

60G /home
60G total

Using free -m, I get the following:

total        used        free      shared  buff/cache   available
Mem:         128831        8648       16405         147      103777      118367
Swap:        130986          18      130968

I only recently moved to using Linux, so I am not aware yet of how the disk partitioning is used. It also seems weird that my system had more than 500 GB yesterday, but just today it's started to show Free space: 0 bytes at the bottom of every folder I open. This space error is causing things to hangup.

EDIT: I have deleted some files in excess of 40 GB, but it still shows Free space: 0 bytes at the bottom of each folder, and does not allow me to copy any files. I am stunned that it was showing ~550 GB yesterday as the free space and suddenly all of it vanished, although there was nothing I did to occupy that space.

  • What about /tmp ? – pLumo Sep 1 '17 at 14:43
  • Just $ /tmp gives bash: /tmp: Is a directory – user11 Sep 1 '17 at 14:44
  • Please don't use tags that make your question offtopic ;) See the "question you should avoid" here: askubuntu.com/help/on-topic And do not forget to clear the trash. And free -m is about memory, not diskspace. – Rinzwind Sep 1 '17 at 14:46
  • @Rinzwind: Sorry about that. Clearing trash was the first thing I did, because it was recommended in the error I received about the disk space. – user11 Sep 1 '17 at 14:48
  • 1
    I of course meant the disk usage of /tmp ... du -sh /tmp ... @Rinzwind Trash is part of /home which has only 60G. – pLumo Sep 1 '17 at 14:48
2

It's entirely possible that some file is bloating and eating up your space. I am remembering an old X-org bug where text files would use all your available disk space for logging errors or whatever until you disabled it.

Try running this command in the terminal:

find / -size +1G -type f -exec du -Sh {} + | sort -rh | head -n 5

You'll probably get a lot of "permission denied" errors, but that should be fine. If a file is ballooning out of control, I would suspect the file will be somewhere in space where you do have permission. That command will return the size and location of the 5 largest files on your system.

If that command does not work due to your lack of space (I think it will), you may have better success doing something like:

find / -size +1G | grep -v find | less

Which should find any file on your computer that is larger than 1 gigabyte in size, filter out any errors, and present the results for your review. You can then investigate any unfamiliar files.

If there is a file growing uncontrollably, you should then be able to delete it or conduct additional research on what it is - it may be a bug or a log you can disable.

  • 2
    You could add -size +1G for the first command too... should be faster I think. – pLumo Sep 1 '17 at 15:04
  • good point, if we're looking for like 600+ GB of something, I'll add it – drkokandy Sep 1 '17 at 16:54
  • @drkokandy: On running your 1st command, I see 631G in /var/log/cups/error_log.1, and 110G in /var/log/cups/error_log. These two files are there besides the other software files that I am aware of and don't suspect any wrong. – user11 Sep 1 '17 at 16:59
  • 1
    I am suspecting the log files contain warnings about permission to some directory. I remember changing permission to env/ and its subdirectories yesterday because I wanted to change a file name of a binary in that folder. Could it be because of that as this answer suggests? – user11 Sep 1 '17 at 17:04
  • 1
    Maybe first analyze what logs say, then delete them. ;) – Andrea Lazzarotto Sep 1 '17 at 17:11

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.