If you're using BTRFS, check if you don't have any stray snapshots.

What's your filesystem?

If you are using something like btrfs, for example, the usage reports can be misleading, and getting the exact size can be complicated.. I'd recommend using more fs-specific tools, such as btdu.

One more puzzle piece here is that du won't report on files that have been marked for deletion but are still held on to by some process. There's an lsof incantation to list those, but I can't recall it off the top of my head.

It used to be part of sysadmin work to detect the processes that held on to large files if df reports that you're running out of space, and restart them to make them let go of the file. But I haven't done that in ages. And if you restarted the host OS that should have taken care of that.

I assume you also know how to prune container resources.

Wouldn't du -hs * only check the space used inside the folder you are in?

I'd check with sudo du -hs /* myself if I wanted. Or ved ncdu to get a visual representation.

df reports on filesystems, not drives.

If you have enough room to install the ncdu command, it's super helpful!

du -hs * won't find "hidden" (.) files and folders, you'll need a slightly sifferent regx (which I will leave as an exercise for you / I don't have that info here)

And also both du and df show different results depending on the underlying filesystem, ie btrfs (and maybe ZFS?) won't show how much deduplication is happening.

Also, you might be looking at sparse files too, and from memory, you'll need another option for du or df to report those correctly.

$ man fstrim

As @Strit wrote, use sudo, as docker keeps its container, image and volume files under /var/lib/docker, and that folder is not readable without sudo (or root).

Check for mounts hiding the underlying drive?

Sometimes du . -x will help, too. (-x doesn't cross mount points).

Docker containers can eat a lot of space over time. When's the last time you did a docker system prune? Be sure to read up on what it does before you try it.

Did du give any permission errors? It can't count the size of directories that it doesn't have permission to access.

To help you we need to understand your setup

• show us the output of ‘mount’
• show us the output of ‘lsblk’
• show us the output of ‘fdisk -l /dev/sda’
• Do you run snapshots?

I'd be curious to see du -i to see what's going on with inodes. Alternatively I did have an issue long time ago with docker containers, sparse files and dirty disk. Force-running fsck resolved my issues in the past.

Where are you running du -sh *? (I.e. what directory, are you definitely scanning the whole file system?) I'm sure it's obvious, but can never hurt to check!

What does du -sh / show? (Generally, the * glob pattern in the shell will not match hidden dot-files, so is it possible they are being excluded?)