Почему нельзя записать файл, хотя команда df -h показывает свободное место в Linux?

Question

Почему нельзя записать файл, хотя команда df -h показывает свободное место в Linux?

Тип вопроса: Linux Вероятность: 24% Категория: Devops Инженер

Ответ

Свободное место для данных — не единственный лимит. Вот основные причины:

Исчерпаны inodes. Каждый файл, директория или символьная ссылка занимает один inode. Если их нет, создать новый объект нельзя.
- Проверка: df -i
- Решение: Удалить множество мелких файлов или увеличить количество inodes при создании ФС (опция -N в mkfs).
Дисковые квоты (quota) для пользователя/группы. Лимит может быть исчерпан, даже если в системе есть место.
- Проверка: quota -vs или repquota -a
Недостаточно места в конкретном слое OverlayFS. Частая проблема в Docker/контейнерах. Верхний writable-слой (обычно thin pool) может быть заполнен, хотя нижний read-only образ имеет свободное место.
- Проверка в Docker: docker system df -v
Права доступа. Отсутствие прав на запись (w) в целевой директории.
- Проверка: ls -ld /path/to/dir и id
Файловая система в режиме «только для чтения» (read-only). Может произойти из-за ошибок ФС или преднамеренной настройки.
- Проверка: В выводе mount или cat /proc/mounts.
Жёсткая ссылка на удалённый файл. Если на файл осталась жёсткая ссылка, место не освободится.

Алгоритм диагностики:

# 1. Проверить inodes
$ df -i /
# 2. Проверить квоты
$ quota -vs
# 3. Проверить права
$ ls -ld /target/path
# 4. Проверить, не заполнен ли отдельный слой (актуально для контейнеров)
$ docker ps -q | xargs docker inspect --format='{{.Id}} {{.GraphDriver.Data.WorkDir}}' | head -1
# 5. Проверить, не в read-only ли ФС
$ findmnt -n -o OPTIONS / | grep ro

Ответ 18+ 🔞

А, ну это классика, ёпта! Сидишь такой, вроде бы места дохуя, а система тебе выдает "No space left on device". И ты такой: "Какого хуя? Я же только что удалил гигабайты логов!" А причина, блядь, может быть не в гигабайтах, а в какой-нибудь хитрой жопе.

Вот смотри, основные причины, почему так бывает:

Кончились inodes. Это, блядь, как билетики на каждый файлик или папочку. Файлов — овердохуища, а билетиков — ноль. Создать новый файл? Ни хуя себе, нельзя.
- Как проверить: df -i
- Что делать: Удалить кучу мелкого говна (типа кэша или временных файлов) или изначально ФС создавать с запасом этих самых inodes.
Дисковые квоты (quota). Это когда тебе, как пользователю, сказали: "Вот тебе 5 гигов, и ни байтом больше". А в системе-то места ещё вагон. Но тебе — хана.
- Как проверить: quota -vs
Слой OverlayFS в контейнере накрылся медным тазом. Особенно в Docker'е прикол. У тебя базовый образ лежит себе спокойно, а вот верхний слой, куда всё пишется, забит под завязку. И всё, приехали.
- Как проверить в Docker: docker system df -v
Права доступа. Самый обидный вариант. Место есть, inodes есть, а ты — не царь. Просто нет прав писать в нужную папку. Чистая правда жизни.
- Как проверить: ls -ld /path/to/dir
Файловая система ушла в режим read-only. Обычно после какой-нибудь жёсткой ошибки система так защищается. Или админ специально так настроил. Пиши — не хочу.
- Как проверить: Глянуть в вывод mount.
Жёсткая ссылка на удалённый файл. Удалил файл, а место не освободилось? Возможно, на него где-то ещё есть жёсткая ссылка. Пока все ссылки не удалишь — место в заложниках.

Вот тебе, чувак, простой алгоритм, чтобы не бздеть и найти причину:

# 1. Первым делом — inodes. Волнение ебать, но проверяем.
$ df -i /
# 2. Глянем, не посадили ли нас на квоту.
$ quota -vs
# 3. А может, мы просто не имеем права?
$ ls -ld /target/path
# 4. Если в контейнере — смотрим на его слои (пример для Docker)
$ docker ps -q | xargs docker inspect --format='{{.Id}} {{.GraphDriver.Data.WorkDir}}' | head -1
# 5. И напоследок — не read-only ли всё?
$ findmnt -n -o OPTIONS / | grep ro

Действуй по этому списку, и причина найдётся. Удачи, не запаривайся!