Low disk space on Filesystem root despite having plenty of space in `home`

Question

I just got this warning

I tried to follow this and this questions, but I fail to understand why this is happening when I still have a lot of space available in home:

df -h

Filesystem                Size  Used Avail Use% Mounted on
udev                       16G     0   16G   0% /dev
tmpfs                     3,2G  2,5M  3,1G   1% /run
/dev/mapper/vg00-lv_root   30G   26G  2,0G  93% /
tmpfs                      16G   50M   16G   1% /dev/shm
tmpfs                     5,0M  4,0K  5,0M   1% /run/lock
tmpfs                      16G     0   16G   0% /sys/fs/cgroup
/dev/loop0                128K  128K     0 100% /snap/bare/5
/dev/loop1                 62M   62M     0 100% /snap/core20/1328
/dev/loop3                130M  130M     0 100% /snap/slack/49
/dev/loop2                165M  165M     0 100% /snap/gnome-3-28-1804/161
/dev/loop5                122M  122M     0 100% /snap/vott/x1
/dev/loop4                184M  184M     0 100% /snap/digikam/53
/dev/loop6                219M  219M     0 100% /snap/gnome-3-34-1804/72
/dev/loop7                 56M   56M     0 100% /snap/core18/2253
/dev/loop8                 56M   56M     0 100% /snap/core18/2284
/dev/loop9                324M  324M     0 100% /snap/telegram-desktop/3544
/dev/loop10               219M  219M     0 100% /snap/gnome-3-34-1804/77
/dev/loop11                62M   62M     0 100% /snap/core20/1361
/dev/nvme0n1p1            511M   30M  482M   6% /boot/efi
/dev/loop12               425M  425M     0 100% /snap/kde-frameworks-5-qt-5-15-3-core20/8
/dev/loop13               184M  184M     0 100% /snap/digikam/52
/dev/mapper/vg00-lv_home  908G  292G  570G  34% /home
/dev/loop14               248M  248M     0 100% /snap/gnome-3-38-2004/87
/dev/loop15                44M   44M     0 100% /snap/snapd/14978
/dev/loop16                66M   66M     0 100% /snap/gtk-common-themes/1515
/dev/loop17               249M  249M     0 100% /snap/gnome-3-38-2004/99
/dev/loop18                66M   66M     0 100% /snap/gtk-common-themes/1519
/dev/loop19                51M   51M     0 100% /snap/snap-store/547
/dev/loop20                55M   55M     0 100% /snap/snap-store/558
tmpfs                     3,2G   16K  3,2G   1% /run/user/125
tmpfs                     3,2G   60K  3,2G   1% /run/user/648604063

I looked into /dev/mapper/vg00-lv_root with tree -LP 1 as suggested here and I see that it actually displays the same results as for tree -LP 1 /dev/mapper/vg00-lv_home:

tree -LP 1 /dev/mapper/vg00-lv_root
.
├── anaconda3
├── cvat
├── Desktop
├── Documents
├── Downloads
├── Dropbox
├── mount
├── Music
├── Nextcloud
├── Pictures
├── Public
├── R
├── snap
├── System Volume Information
├── Templates
├── Videos
└── VirtualBox VMs

I also run sudo apt-get clean as suggested here

Do you have any idea how to solve this?

The result of gparted is this:

The results of the Disks tools are:

Also, the results of lsblk are:

NAME             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0              7:0    0     4K  1 loop /snap/bare/5
loop1              7:1    0  55,5M  1 loop /snap/core18/2253
loop2              7:2    0 183,2M  1 loop /snap/digikam/52
loop3              7:3    0 248,8M  1 loop /snap/gnome-3-38-2004/99
loop4              7:4    0  65,1M  1 loop /snap/gtk-common-themes/1515
loop5              7:5    0  55,5M  1 loop /snap/core18/2284
loop6              7:6    0 424,2M  1 loop /snap/kde-frameworks-5-qt-5-15-3-core20/8
loop7              7:7    0  61,9M  1 loop /snap/core20/1361
loop8              7:8    0   219M  1 loop /snap/gnome-3-34-1804/77
loop9              7:9    0 164,8M  1 loop /snap/gnome-3-28-1804/161
loop10             7:10   0   324M  1 loop /snap/telegram-desktop/3544
loop11             7:11   0   219M  1 loop /snap/gnome-3-34-1804/72
loop12             7:12   0 121,5M  1 loop /snap/vott/x1
loop13             7:13   0 183,7M  1 loop /snap/digikam/53
loop14             7:14   0  54,2M  1 loop /snap/snap-store/558
loop15             7:15   0 247,9M  1 loop /snap/gnome-3-38-2004/87
loop16             7:16   0  61,9M  1 loop /snap/core20/1328
loop17             7:17   0  65,2M  1 loop /snap/gtk-common-themes/1519
loop18             7:18   0 129,4M  1 loop /snap/slack/49
loop19             7:19   0  43,6M  1 loop /snap/snapd/14978
loop20             7:20   0    51M  1 loop /snap/snap-store/547
nvme0n1          259:0    0 953,9G  0 disk 
├─nvme0n1p1      259:1    0   512M  0 part /boot/efi
└─nvme0n1p2      259:2    0 953,4G  0 part 
  ├─vg00-lv_root 253:0    0    30G  0 lvm  /
  └─vg00-lv_home 253:1    0 923,4G  0 lvm  /home

I am not sure if I am doing the right thing, but I tried to assign space like this:

sudo lvextend --resizefs -L +10G /dev/vg00/lv_root

# and I got this warning:
# Insufficient free space: 2560 extents needed, but only 0 available

Later edits with solution from IT

In case someone else runs into similar issues here is the solution that my IT department implemented:

Use a USB stick with a live Linux Ubuntu;
Reboot the OS and boot from the USB stick;
Get info about logical volumes with (we need to see their names & paths & get an idea of how much space is available):
- lvs or
- df -h / /home/
Decrease the size of home/ logical volume & resize the file system with 30 Gb:

sudo lvreduce --resizefs -L -30GB devmapper/vg00-lv_home

Assign the 30 Gb to the root / with:

sudo lvextend --resizefs -L +30GB devmapper/vg00-lv_root

The current status is:

df -h / /home/
#Filesystem                Size  Used Avail Use% Mounted on
#/dev/mapper/vg00-lv_root   59G   26G   31G  47% /
#/dev/mapper/vg00-lv_home  879G  292G  542G  35% /home

Hope this helps others as well. So far the OS is stable and has no data loss.

You can use ```GParted``` to solve this problem. If you can I strongly recommend backing up your files. Can you make a screenshot of ```GParted```, so I can guide you through the process. Post it in your question. — Joepie Es, Mar 09 '22 at 20:53
Hi @JoepieEs, I added a print screen in the answer. Note also that I might not have full admin rights since is my work laptop. I didn't set the OS. — Valentin_Ștefan, Mar 09 '22 at 21:04
You have volume, not partitions. Gparted will not resize. But with LVM, you can resize while booted. One advantage of LVM. But you use LVM tools not partition tools. Some info here. https://askubuntu.com/questions/262211/how-do-i-resize-an-encrypted-lvm-to-install-another-copy-of-ubuntu & https://wiki.ubuntu.com/Lvm — oldfred, Mar 09 '22 at 22:49
@ Valentin Don't use ```GParted```. You can't use for this job. Look at the comment of @oldfred. — Joepie Es, Mar 10 '22 at 08:56
can you please post the output of `sudo du -xa / | sort -n -r | head -n 15` ? — Robert Riedl, Mar 10 '22 at 11:59
@JoepieEs, I think that was the wise thing to do and luckily I could go in person (covid restrictions make access to IT solutions a bit harder). I posted their solution above. — Valentin_Ștefan, Mar 11 '22 at 12:09

score 5 · Answer 1 · answered Mar 09 '22 at 20:30

5

You put your /home on a different partition so this space cannot be used by your root file system.

Your root file system only has 30GB which is not much more than the bare minimum system requirement of 25GB for Ubuntu Desktop.

Unfortunately your chosen partition scheme has put you in a bind. You only have 30GB for root. It's definitely not a requirement to put /home on a different partition and your current predicament is exactly the reason why it's not recommended and why the default installation options do not put /home on a separate partition.

Partitions are rigid, inflexible, and hard to change. You may need to reinstall if the locations of your partitions make them unable to be resized.

answered Mar 09 '22 at 20:30

Nmath

12,105
8
25
54

I didn't do the OS installation myself and I try to understand how to fix this. I am a beginner with Linux and the IT department set it like this. It worked well for one year and now I got this out-of-space message. Not sure why it wasn't an issue so far. Is there any solution without having to reinstall the OS? – Valentin_Ștefan Mar 09 '22 at 21:20
3

If you have an IT department then you probably need to contact them first. See [How to resize partitions?](https://askubuntu.com/q/126153) In practice you may discover that a reinstall is easier or more practical. Resizing partitions can get complicated. In either case, make sure your backups are in order before proceeding. 30GB is enough to satisfy the minimum space requirements, but gives you very little room for much else. – Nmath Mar 09 '22 at 21:54
It's not about resizing partitions. It's about resizing logical volumes in a volume group `vg00`. It can be done while booted and it's relatively safe -- but even so, start by making a backup of /home before starting on reducing its size, which is what you will have to do in order to make space to extend the root lv. – nigel222 Mar 10 '22 at 10:33
That doesn't explain why Ubuntu Gnome (?) tells OP it has only 685,2 MB space free on / while a `df` shows it's actually 2GB. OP probably has the default 5% reserved for root on a ext partition, so for his user there is only 685,2 MB space "left" on / . – Robert Riedl Mar 10 '22 at 11:54

score 0 · Answer 2 · answered Oct 25 '22 at 04:01

Firstly, thanks @Valentin_Ștefan to post your solution! That is very useful.

Secondly, I think this question also could use cfdisk to solve.

A.use sudo cfdisk to enter cfdisk, then use up and down direction button to choose partition, use right and left direction button to choose operation,

Using Resize button to decrease the partition /dev/mapper/vg00-lv_home via -226G;

Also, using Resize button to increase the partition /dev/mapper/vg00-lv_root via +226G;

Then quit cfdisk via choosing Quit button.

B.Using sudo resize2fs /dev/mapper/vg00-lv_root to set all the file types of main/root partition /dev/mapper/vg00-lv_root into ext4.

C.Restart or reboot your virtual machine: sudo reboot.

Have fun!!!:)

OVER!

Hey! Thanks for your answer. when I insert the resize2fs command, I get this error: Volume group "vg00" not found. Can you help me with that? — Sara, Dec 02 '22 at 18:04

score 0 · Answer 3 · answered Mar 16 '23 at 00:33

I had the same problem and solved it by resizing and moving the partitions around root and then that let me resize root to over 100Gb. All is good now. I used GParted to achieve this. Took some time to resize the large partition but then very quick to resize root.

Low disk space on Filesystem root despite having plenty of space in `home`

Later edits with solution from IT

3 Answers3

Linked