...Did as you suggested.
passed the obligatory hint to "reload fstab"
Result:
ncdu opens a screen where on entry level /mnt/bind I just can navigate to a single available subfolder called "ram" (that non-standard mount-point that I myself created intentionally) - There is no contents in this subforder (as it is also in the non-bind environment).
"/mnt/bind"? That's not where I suggested you mount it. Did you mean /tmp/bind/mnt ?
And, if you just used sudo mount (rather than modiyfing fstab) no reload was necessary.
What does such result tell?
Bind mounts make a directory available at a second (or third, or ...) place in the filesystem tree with one key difference: when accessing a mount point via the bind mount you access what is on the underlying file system not what's on the mounted one.
Files/directories under a mountpoint is a common cause of "missing" disc space.
As you probably know you can mount onto a non-empty directory and when you do so the contents of that directly can no longer be accessed but (obviously) still consume space. In the case of ncdu while it can get total free and used space, it can't scan under a mount point - that always scans the mounted thing. Using -x doesn't change that, it just stops it scanning deeper than the mount point..
WIth / bind mounted on /tmp/bind (example path it could be anywhere you choose within reason) you can see what is actually on the root partition that would be masked by a mount.
Try the following commands to see what's going on (assumes /tmp/bind exists and / has been bind mounted onto it):
Code:
mountpoint /devls /devmountpoint /tmp/bind/devls /tmp/bind/devSo if you then run sudo ncdu /tmp/bind you'll get a true picture of what's on your root filesystem including anything hidden by active mounts. Expect to see /tmp/bind/dev, /tmp/bind/proc, /tmp/bind/sys and any other mount points to show as empty when accessed via /tmp/bind, if they don't that's probably where your disc space has gone.
Statistics: Posted by thagrol — Sun Feb 01, 2026 12:29 am