Edit: SOLVED thanks to r00ty !
Hello, I have this weird issue that my Debian 11 will tell me the root folder is full, while I can only find files for half of the accounted space.
df -h reports 56G while the disk analyser (sudo baobab) only finds 28G.
Anyone ever encountered this? I don’t have anything mounted twice… (Not sure what udev is). Also it does not add up to 100%, it should say 7.2G left not 4.1G
df -h /dev/sda* Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev /dev/sda1 511M 22M 490M 5% /boot/efi /dev/sda2 63G 56G 4.1G 94% / /dev/sda4 852G 386G 423G 48% /home
Edit: my mtab
Edit 2: what Gparted shows
OK, one possibility I can think of. At some point, files may have been created where there is currently a mount point which is hiding folders that are still there, on the root partition.
You can remount just the root partition elsewhere by doing something like
mkdir /mnt/rootonly mount -o bind / /mnt/rootonlyThen use du or similar to see if the numbers more closely resemble the values seen in df. I’m not sure if that graphical tool you used that views the filesystem can see those files hidden this way. So, it’s probably worth checking just to rule it out.
Anyway, if you see bigger numbers in /mnt/rootonly, then check the mount points (like /mnt/rootonly/home and /mnt/rootonly/boot/efi). They should be empty, if not those are likely files/folders that are being hidden by the mounts.
When finished you can unmount the bound folder with
umount /mnt/rootonlyJust an idea that might be worth checking.
This! Thank you, this allowed me to find the culprit! It turns out I had an external disk failure some weeks ago, and a cron rsync job was writing in /mnt/thatdrive. When the externaldrive died rsync created a folder /mnt/thatdrive. Now that I replaced the drive, /mnt was disregarded by the disk analyser, but the folder was still there and indeed hidden by the mount… It is just a coincidence that it was half the size of /
SOLVED!
du -hs /mnt/rootonly/* 0 /mnt/rootonly/bin 275M /mnt/rootonly/boot 12K /mnt/rootonly/dev 28M /mnt/rootonly/etc 4.0K /mnt/rootonly/home 0 /mnt/rootonly/initrd.img 0 /mnt/rootonly/initrd.img.old 0 /mnt/rootonly/lib 0 /mnt/rootonly/lib32 0 /mnt/rootonly/lib64 0 /mnt/rootonly/libx32 16K /mnt/rootonly/lost+found 24K /mnt/rootonly/media 30G /mnt/rootonly/mnt 773M /mnt/rootonly/opt 4.0K /mnt/rootonly/proc 113M /mnt/rootonly/root 4.0K /mnt/rootonly/run 0 /mnt/rootonly/sbin 4.0K /mnt/rootonly/srv 4.0K /mnt/rootonly/sys 272K /mnt/rootonly/tmp 12G /mnt/rootonly/usr 14G /mnt/rootonly/var 0 /mnt/rootonly/vmlinuz 0 /mnt/rootonly/vmlinuz.old
This might help in the future in case you setup a remote mount for backups in the future. Look into using systemd’s automount feature. If the mount suddenly fails then it will instead create an unwritable directory in its place. This prevents your rsync from erroneously writing data to your root partition instead.
What FS you’re on? I’m using BTRFS and have the same problem. Simply because disk analyzer doesn’t read snapshots.
I learned this the hard way when I accidentally deleted my root filesystem last month trying to free up snapshot space.
Btrfs subvolume create /.nodelete
That way, “btrfs sub del” cannot hit your root subvolume without you first removing .nodelete .
