У меня есть ситуация, когда в моей корневой файловой системе должно быть много свободного места, но Debian ведет себя так, как будто в ней не осталось свободного места. Пользователи без полномочий root даже отказываются писать что-либо с жалобами на нехватку свободного места. Т.е. например:
~$ echo "qwertyu" > test
-bash: echo: write error: Spazio esaurito sul device
(Извините за язык, я сам не устанавливал сервер. Ошибка гласит: «На устройстве закончилось свободное место»). Но root пишет в эту же директорию без нареканий. Также, если я сделаю df -h как root, я получу следующее:
/# 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
Но записи du не складываются:
/# 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
(Ошибка: «Нет доступа к yada yada: нет такого файла или каталога»). Имейте в виду, что / disk2 - это монтирование другого раздела.
Проверка файловой системы тоже не помогла:
/# 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
(«Поскольку это проверка только для чтения, журнал не будет восстановлен», но я полагаю, что приведенная ниже «чистка» исключает такую возможность).
Есть идеи, что здесь может происходить? Представьте, что система работает где-то на виртуальной машине, и я могу получить к ней доступ только через SSH.
Единственным разумным объяснением было бы то, что файловая система смонтирована только для чтения. dmesg | grep -i "\-fs" должен показать некоторые ошибки, если это так.
Если вы находитесь на виртуальной машине, fs может быть не полностью доступна из вашей виртуальной машины, что делает невозможным исправление ошибок fs внутри вашей виртуальной машины. Обратитесь к своему провайдеру, чтобы исправить это.