[SOLVED} Low disk space on “Filesystem root”, 0 bites remaining

H

hlfblnd

New Member
Joined
Mar 4, 2021
Messages
5
Reaction score
2
Credits
37
Hi everyone!
I have problems regarding my disk space. It says I have 0% free space left and I don't have any "big" files so I don't know what filled up so much space.
My laptop is Acer Aspire E 15 and Linux distro is Ubuntu 20.04

Results of df -h command show this:

1614889403773.png

I could really use some help because I really don't know what to do. Thanks in advance :)
 


You don't need large files to fill up a disk. Lots of little files will happily do it for you.

One thing I can think of is that I'm reasonably confident that 'snaps' retain the previous version as a fallback. So, if you have the snap of VLC then you also (probably) have the previous snap VLC kicking around somewhere. Still, that be pretty trivial compared to the /dev/sda2 that's a full 436 GB in size.

Anyhow, it looks like you have no space. The solution is to make space - which might entail finding out what took up all that space.
 
G'day @hlfblnd and welcome to linux.org :)

Do you use Timeshift?

Chris Turner
wizardfromoz
 
The snaps don't seem to be the problem. If you add up all of the usage shown for the snaps and other stuff, it's nowhere near the 450 some gig that is allocated to /. Is there another OS on the same hard drive? Old non-Linux data?
 
Okay, what am I missing? When I look at ALL of the entries for the snap stuff, it totals < 7gb. So where is the space being used?

1614973418186.png
 
khedger said:
Okay, what am I missing? When I look at ALL of the entries for the snap stuff, it totals < 7gb. So where is the space being used?
Click to expand...
Look at his root ( / ) on /dev/sda2.... down to 21 GB, interpreted as 100% Used by Ubuntu, although obviously it's not quite full really.
 
stan said:
Look at his root ( / ) on /dev/sda2.... down to 21 GB, interpreted as 100% Used by Ubuntu, although obviously it's not quite full really.
Click to expand...
Yeah, I get that. But the discussion earlier was that the snap data was taking the space. I see all kinds of entries with 'snap' in them and I don't see any other filesystems. So, if you take everything that's listed OTHER than the entry for '/', and add up the space taken, it doesn't amount to anymore than 6 or 7 gb, maybe a little more. So THOSE are not the entries reflecting the space being used. So what IS using the space is my question. Does the Timeshift utility create hidden data? See my point? We should see something in this command output that reflects the data used, which is why I asked if there was something else on the drive. The user says Timeshift was the problem, but it would be interesting to know in what way it was using the space.....
 
This is why I dislike snapds and flatpacks; they eat disk's space!

hlfblnd said:
Results of df -h command show this:
Click to expand...

Post the output of
Code: 
df -ih
Sometimes, the FS can run out of inodes, it happened to me once.
 
This may be solved (or nearly), folks.

hlfblnd said:
Yes, I do and this was a problem. It took up nearly 50% of my space. I managed it now and I think that solved the problem.
Click to expand...

So on /dev/sda2 you likely have a folder called timeshift under /home/hlfblnd (or whatever your username is) and the settings were not set optimally and it was performing scheduled full backups and not culling them regularly. This would account for the gobbling up of large chunks of space.

Do you think that likely to be the case?

If so, swing over to my Thread here

https://www.linux.org/threads/timeshift-similar-solutions-safeguard-recover-your-linux.15241/

and ask, and I can show you how to better set up your Timeshift for your environment.

Do note that any Timeshift snapshots deleted should be performed from within Timeshift and not from, say, your File Manager or Terminal.

If we get that sorted, you can then come back here and mark the Thread as Solved.

Let me know if I am reading this wrong.

Cheers

Wizard
 
khedger said:
But the discussion earlier was that the snap data was taking the space.
Click to expand...
Well, no, not really. In post #2 @KGIII mentioned snaps, but he also said they were trivial compared to /dev/sda2. I think that confused you. You also recognized in post #5 that snaps were not the problem. @wizardfromoz seems to have suspected Timeshift immediately in post #4, as has now been confirmed. Timeshift is simply storing the OP's backups somewhere under / ... which is why external hard drives are much better for this. :)
 
Oh, I get it now.....it was just using /. So a simple ls of / would have shown us something.....got it. Thanks for ellucidating.

keith
 
wizardfromoz said:
This may be solved (or nearly), folks.



So on /dev/sda2 you likely have a folder called timeshift under /home/hlfblnd (or whatever your username is) and the settings were not set optimally and it was performing scheduled full backups and not culling them regularly. This would account for the gobbling up of large chunks of space.

Do you think that likely to be the case?

If so, swing over to my Thread here

https://www.linux.org/threads/timeshift-similar-solutions-safeguard-recover-your-linux.15241/

and ask, and I can show you how to better set up your Timeshift for your environment.

Do note that any Timeshift snapshots deleted should be performed from within Timeshift and not from, say, your File Manager or Terminal.

If we get that sorted, you can then come back here and mark the Thread as Solved.

Let me know if I am reading this wrong.

Cheers

Wizard
Click to expand...

That was the case. I deleted snapshots from within Timeshift. Thanks for your help :D

This is a new df -h output:
1615111309176.png
 
Tolkem said:
This is why I dislike snapds and flatpacks; they eat disk's space!



Post the output of
Code: 
df -ih
Sometimes, the FS can run out of inodes, it happened to me once.
Click to expand...

Here's the output of
Code: 
df -ih

1615111558373.png
 
hlfblnd said:
Here's the output of
Click to expand...
Well, it looks ok as the problematic partition /dev/sda2 has plenty of inodes free; only 4% used. I suggest that you install ncdu https://dev.yorhel.nl/ncdu/scr to investigate which files are eating disk's space. In Ubuntu just open a terminal and do
Code: 
sudo apt-get install ncdu
it's only a few kbs... oh, your disk's full... I'm not sure you can install anything, you could try in a Live USB though. With ncdu you can find those big files and remove them if needed
ncduconfirm-2.png

it runs in the terminal, to launch just type
Code: 
ncdu
you'll see something similar to the img above. By default, it scans $HOME user directory, you can scan others by adding /path/to/folder, i.e.
Code: 
ncdu /var
This tells ncdu to scan /var directory, speaking of which, if you haven't already, open the terminal and run
Code: 
sudo apt autoremove && sudo apt clean && sudo apt autoclean
this might regain you hundreds or even thousands of MBs in the disk. In case installing ncdu is not possible, you can use this
Code: 
du -Lh -d 1 --apparent-size
This way you don't need to install anything and will give you a "similar" output to that of ncdu's, though you'll have to remove the files manually either from the file manager or from the terminal. If you wnt to scan different dirs, then add them
Code: 
du -Lh -d 1 --apparent-size /var
you'll get some errors regarding permissions and that's ok.
 
Tolkem said:
Well, it looks ok as the problematic partition /dev/sda2 has plenty of inodes free; only 4% used. I suggest that you install ncdu https://dev.yorhel.nl/ncdu/scr to investigate which files are eating disk's space. In Ubuntu just open a terminal and do
Code: 
sudo apt-get install ncdu
it's only a few kbs... oh, your disk's full... I'm not sure you can install anything, you could try in a Live USB though. With ncdu you can find those big files and remove them if needed
ncduconfirm-2.png

it runs in the terminal, to launch just type
Code: 
ncdu
you'll see something similar to the img above. By default, it scans $HOME user directory, you can scan others by adding /path/to/folder, i.e.
Code: 
ncdu /var
This tells ncdu to scan /var directory, speaking of which, if you haven't already, open the terminal and run
Code: 
sudo apt autoremove && sudo apt clean && sudo apt autoclean
this might regain you hundreds or even thousands of MBs in the disk. In case installing ncdu is not possible, you can use this
Code: 
du -Lh -d 1 --apparent-size
This way you don't need to install anything and will give you a "similar" output to that of ncdu's, though you'll have to remove the files manually either from the file manager or from the terminal. If you wnt to scan different dirs, then add them
Code: 
du -Lh -d 1 --apparent-size /var
you'll get some errors regarding permissions and that's ok.
Click to expand...

I actually found out that the problem was in Timeshift so now I have plenty of space once I got rid of those snapshots. Regardless, I will install ncdu for future use. Thanks for the advice. :)
 
Tolkem said:
oh, your disk's full...
Click to expand...
Although the OP seems to have resolved the problem (post #6)... ncdu is a dandy little tool. I have not run into that before. Thanks! :)
 
You must log in or register to reply here.

Members online

Total: 753 (members: 4, guests: 749)

Latest posts

Top