Почему при доступном месте файлы не создаются

Что проверяют

Умеете ли вы диагностировать по коду ошибки, а не по догадкам. «Место есть» это вывод df -h, а ядро отказало по конкретному errno, и от него зависит вообще всё. Ценят порядок действий, а не список причин наугад.

Как отвечать

Первым делом получить настоящую ошибку: посмотреть, что пишет приложение, или снять strace -f -e trace=openat,write с процесса. ENOSPC, EDQUOT, EROFS, EACCES, EMLINK и EMFILE лечатся по-разному, без errno дальше идёт гадание.

Дальше типовые причины при живом свободном месте:

• кончились иноды, а блоки остались: df -i, обычное дело для каталогов с миллионами мелких файлов и для кешей;
• превышена квота пользователя или проекта: repquota, quota -u;
• сработал резерв для суперпользователя, у ext4 это несколько процентов тома: обычный процесс уже получает отказ, резерв виден в tune2fs -l;
• файловая система ушла в режим только для чтения после ошибки ввода-вывода, ровно для этого существует опция монтирования errors=remount-ro. Смотреть dmesg и вывод mount;
• место держат удалённые, но ещё открытые файлы: du показывает мало, df показывает полный том, виновника находит lsof +L1;
• пишут не туда, куда смотрят: нужный каталог оказался другим монтированием, tmpfs с лимитом или слоем overlay внутри контейнера.

Хороший финал ответа: df -h и df -i всегда вместе, а состояние диска по dmesg и SMART.

Где спотыкаются

Останавливаются на первой строке df -h и не проверяют иноды. Это самый частый вариант вопроса, и на нём же обычно и заканчивается разбор.

Советуют запустить fsck на смонтированной боевой файловой системе. Так её можно доломать окончательно: проверка идёт на размонтированном томе или через перезагрузку с флагом принудительной проверки.

Удаляют распухший лог через rm, пока его держит открытым демон. Место не вернётся до закрытия дескриптора, поэтому нужен truncate -s 0 или штатная ротация с сигналом процессу.