2

I have a situation where my root filesystem is supposed to have plenty of free space, but Debian behaves as if it had no free space left. Non-root users even refute to write anything complaining about the lack of free space. I.e. for example:

~$ echo "qwertyu" > test
-bash: echo: write error: Spazio esaurito sul device

(Sorry about the language, I didn't install the server myself. The error reads "ran out of free space on the device"). But root writes to the same directory without complaints. Also if I do df -h as root I get this:

/# df -h
File system                                             Dim. Usati Dispon. Uso% Montato su
rootfs                                                   48G   46G       0 100% /
udev                                                     10M     0     10M   0% /dev
tmpfs                                                   397M   88M    310M  23% /run
/dev/disk/by-uuid/8063903c-80ad-4f72-81b0-cd67dbd48fc7   48G   46G       0 100% /
tmpfs                                                   2,0G     0    2,0G   0% /dev/shm
tmpfs                                                   2,0G     0    2,0G   0% /sys/fs/cgroup
tmpfs                                                   5,0M     0    5,0M   0% /run/lock
tmpfs                                                   100M     0    100M   0% /run/user
/dev/sdb1                                                99G  9,6G     84G  11% /disk2

But du entries don't add up:

/# du -sh /* | sort -hr
du: impossibile accedere a "/proc/12905/task/12905/fd/4": File o directory non esistente
du: impossibile accedere a "/proc/12905/task/12905/fdinfo/4": File o directory non esistente
du: impossibile accedere a "/proc/12905/fd/4": File o directory non esistente
du: impossibile accedere a "/proc/12905/fdinfo/4": File o directory non esistente
9,4G    /disk2
3,8G    /var
3,2G    /data
1,6G    /usr
277M    /opt
130M    /root
129M    /lib
88M /run
45M /home
18M /boot
7,6M    /bin
6,0M    /sbin
5,2M    /etc
28K /tmp
16K /lost+found
8,0K    /media
4,0K    /srv
4,0K    /selinux
4,0K    /mnt
4,0K    /lib64
0   /vmlinuz
0   /sys
0   /proc
0   /initrd.img
0   /dev

(Error says "Cannot access yada yada: No such file or directory"). Be aware that /disk2 is a mount for an another partition.

Checking the filesystem didn't help either:

/# e2fsck -n /dev/sda1
e2fsck 1.42.5 (29-Jul-2012)
Warning!  /dev/sda1 is mounted.
Attenzione: essendo un controllo a sola lettura, il journal non verrà ripristinato.
/dev/sda1: clean, 86568/3145728 files, 11666588/12563712 blocks

("Being it a read-only check, the journal will not be recovered", but I guess the "clean" just below rules out this possibility).

Any idea what might be going on here? Consider the system runs on a VM somewhere and I can only access it via SSH.

  • Also note that the ext[2-4] filesystems reserve 5% of their space for the root user by default (so root can still login and fix things when the disk fills up). – n.st Apr 02 '16 at 11:12
  • 1
    Ended up being a big deleted log file was being kept open by mongoDB. Kudos to the guy from the other question. – Michele De Pascalis Apr 02 '16 at 11:21

1 Answers1

0

The only reasonable explanation would be, that the file system is mounted read-only. dmesg | grep -i "\-fs" should show some errors, if so.

If you are on a VM, the fs may not be fully accessible from within your VM, thus rendering you impossible to fix fs errors from within your VM. Consider contacting your provider to get this fixed.

moestly
  • 1,138
  • 8
  • 10
  • `/# dmesg | grep -i "\-fs"` `[ 0.942564] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)` `[ 3.872319] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro` `[ 394.339307] EXT3-fs (sdb1): using internal journal` `[ 394.339310] EXT3-fs (sdb1): mounted filesystem with ordered data mode` I don't know if this is significant to the case... – Michele De Pascalis Apr 02 '16 at 11:10
  • No, seems ok to me. I guess the underlying host/storage is to blame. – moestly Apr 02 '16 at 11:35
  • This is not true, I have rw rights on my partition and it has the same problem –  Feb 10 '20 at 01:52