this post was submitted on 20 Jun 2024
92 points (96.0% liked)

Linux

48372 readers
1207 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
92
Disk space counted twice on root folder? (lemmy.world)
submitted 5 months ago* (last edited 5 months ago) by BeatTakeshi to c/[email protected]
31 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 29 points 5 months ago (9 children)

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.

[–] BeatTakeshi 22 points 5 months ago* (last edited 5 months ago) (8 children)

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

[–] Archr 20 points 5 months ago (1 children)

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.

[–] BeatTakeshi 4 points 5 months ago (1 children)

Thank you for sharing this tip! Very useful indeed

[–] [email protected] 6 points 5 months ago* (last edited 5 months ago) (1 children)

You can also do the following to prevent unwanted writes when something is not mounted at /mnt/thatdrive:

# 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

From man 1 chattr:

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode.
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

I do this to prevent exactly the situation you’ve encountered. Hope this helps!

[–] [email protected] 1 points 5 months ago (1 children)

I think I would have expected/preferred mount to complain that you're trying to mount to a directory that's not empty. I feel like I've run into that error before, is that not a thing?

[–] [email protected] 2 points 5 months ago (1 children)

It is with zfs, but I not with regular mount I think (at least not by default). It might depend on the filesystem though.

[–] [email protected] 2 points 5 months ago (1 children)

Ahh, that might be it. I run TrueNAS too. IMO that should be the default behavior, and you should have to explicitly pass a flag if you want mount to silently mask off part of your filesystem. That seems like almost entirely a tool to shoot yourself in the foot.

[–] [email protected] 1 points 5 months ago

Yep, it’s definitely better to have as a default

load more comments (6 replies)
load more comments (6 replies)