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.

Rinzwind
  • 299,756
user11
  • 123
  • What about /tmp ? – pLumo Sep 01 '17 at 14:43
  • Just $ /tmp gives bash: /tmp: Is a directory – user11 Sep 01 '17 at 14:44
  • Please don't use tags that make your question offtopic ;) See the "question you should avoid" here: https://askubuntu.com/help/on-topic And do not forget to clear the trash. And free -m is about memory, not diskspace. – Rinzwind Sep 01 '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 01 '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 01 '17 at 14:48
  • @RoVo sure but the "Free space: 0 bytes at the bottom of every folder I open." is not going to be about /tmp/ I would assume. The issue will be with /home/ ... 60Gb in there. That must be a video I'd bet. – Rinzwind Sep 01 '17 at 14:50
  • @RoVo: I get the following: $ du -sh /tmp du: cannot read directory '/tmp/systemd-private-1916acb2a3bd41e1b7d45cff70cf4d91-rtkit-daemon.service-4flEKu': Permission denied du: cannot read directory '/tmp/systemd-private-1916acb2a3bd41e1b7d45cff70cf4d91-colord.service-H2ci85': Permission denied 2.1M /tmp – user11 Sep 01 '17 at 14:50
  • Add "sudo" before the command @user11 – Rinzwind Sep 01 '17 at 14:51
  • okay, but then it's not about /tmp. sorry. – pLumo Sep 01 '17 at 14:51
  • @Rinzwind: $ sudo du -sh /tmp sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set – user11 Sep 01 '17 at 14:52
  • If 801G is used with 60G in /home, and the system takes approximately 15G, what the hell is the other 725G ?? ... run a du -sh /* to find out. It will take a while. – pLumo Sep 01 '17 at 14:54
  • @RoVo: After running your suggested command, most of the lines show 'Permission denied', but the last two lines read 758G /var 0 /vmlinuz. I have been trying to reboot, but it's not letting me. Currently, running the terminal through Alt+F2. – user11 Sep 01 '17 at 16:53
  • so it sounds like there's something gigantic in /var - I posted this as an answer, but try something like find /var -size +1G -type f -exec du -Sh {} + | sort -rh | head -n 5 to try to find out what is so big in /var – drkokandy Sep 01 '17 at 16:59
  • @drkokandy: Yes, I tried your suggestion and I posted a comment about the two files. – user11 Sep 01 '17 at 17:01

1 Answers1

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.

drkokandy
  • 1,057
  • 2
    You could add -size +1G for the first command too... should be faster I think. – pLumo Sep 01 '17 at 15:04
  • good point, if we're looking for like 600+ GB of something, I'll add it – drkokandy Sep 01 '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 01 '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 01 '17 at 17:04
  • So cups is spewing huge error logs. These logs are not necessary and can be deleted, which will free your space. Check the Log Level that cups is set to in /etc/cups/cupsd.conf via this answer - if it's not "warn" or "error" that's why it's spewing so much. If it is set to one of those, you can try to delete those log files (you may need to force it with like rm -f /var/log/cups/error_l* - make sure to enter this command carefully) and then reboot or restart cups. – drkokandy Sep 01 '17 at 17:05
  • @user11 that could be it, especially if that was a recent change just before the problem started - try changing the permissions back – drkokandy Sep 01 '17 at 17:07
  • 1
    Maybe first analyze what logs say, then delete them. ;) – Andrea Lazzarotto Sep 01 '17 at 17:11
  • I read first 20 lines of the log and it keeps repeating File \"/usr/lib/cups/notifier ... has insecure permissions ... went away, retrying! – user11 Sep 01 '17 at 17:13
  • There you go. Remove the logs and change back the permissions. Best would be to file a bug report to cups... – pLumo Sep 01 '17 at 17:21
  • @RoVo: What is the recommended way to change back the permissions? – user11 Sep 01 '17 at 17:24
  • i had this once, were something was wrong with the logging, and i found .log files exceeding 100gb. i had to delete them with sudo also. never happened afterwards though – Bas Lamerichs Dec 01 '19 at 09:46