What FS you’re on? I’m using BTRFS and have the same problem. Simply because disk analyzer doesn’t read snapshots.

Is it possible you have processes holding onto deleted files?

Wondering : Does duf do a better job than df with btrfs ?

• packages.debian.org/search?keywords=duf
• backports.debian.org/Instructions/

What does `lsblk -f say?

try ncdu?

sudo ncdu --one-file-system /

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/rootonly

Then 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/rootonly

Just an idea that might be worth checking.

# make sure it is not mounted, fails if not mounted which is fine
umount /mnt/thatdrive

# make sure the mountpoint exists
mkdir -p /mnt/thatdrive

# make the directory immutable, which disallows writing to it (i.e. creating files inside it)
chattr +i /mnt/thatdrive

# test write to unmounted dir (should fail)
touch /mnt/thatdrive/myfile

# remount the drive (assumes it’s already listed in fstab)
mount /mnt/thatdrive

# test write to mounted dir (should succeed)
touch /mnt/thatdrive/myfile

# cleanup
rm /mnt/thatdrive/myfile

Very weird, I can think of some things I might check:

• It is possible that you have files on disk that don’t have a filename anymore. This can happen when a file gets deleted while it is still opened by some process. Only the filename is gone then, but the file still exist until that process gets killed. If this were the problem, it would go away if you rebooted, since that kills all processes.

• Maybe it is file system corruption. Try running fsck.

• Maybe the files are impossible to see for baobab. Like if you had gigs of stuff under (say) /home on you root fs, then mount another partition as /home over that, those files would be hidden behind the mount point. Try booting into a live usb and checking your disk usage from there, when nothing is mounted except root.

• If you have lots and lots of tiny files, that can in theory use up a lot more disk space than the combined size of the files would, because on a lot file systems, small files always use up some minimum amount of space, and each file also has some metadata. This would show up as some discrepancy between du and df output. For me, df --inodes / shows ~300000 used, or about 10% of total. Each file, directory, symlink etc. should require one inode, I think.

• I have never heard of baobab, maybe that program is buggy or has some caveats. Does du -shx / give the same results?

Maybe setup a live USB and mount it from a live environment to see what it comes up with?

mkdir 1
sudo mount /dev/sda2 1
sudo baobab 1
...
sudo umount 1

I think it’s possible that the filesystem ran out of inodes, so even though there is space on disk, there is no space in the filesystem metadata to store new files.

Now, I don’t know off the top of my head how to check this, but I assume the answer is on the internet somewhere (am on phone and can’t help much more than this, sorry)

The large /var suggests flatpak, and that plays some hardlinking games.

(If you ever need to free up / space, shifting your flatpak usage to a --user repo will help a lot. No there is no handy command for that, it’s a matter of adding and deleting one package at a time.)

Repair inodes or try finding a truckload of dumped logs.