Сообщение write error с пометкой abrt и текстом «отказано в доступе» (Permission denied) появляется, когда служба автоматической регистрации сбоев ABRT (Automatic Bug Reporting Tool) пытается записать дамп аварийно завершившегося процесса, но не получает права на запись в свой рабочий каталог. Чаще всего проблема связана с каталогами /var/spool/abrt или /var/tmp/abrt, владелец или права которых были изменены вручную, скриптом очистки или после переноса системы.
Ошибка не является критичной для самой системы — аварийно завершившееся приложение уже завершилось, а ABRT лишь не смог сохранить отчёт о сбое. Однако постоянные записи в журнале засоряют логи, а отсутствие crashdump-файлов мешает диагностике реальных падений программ. Ниже разберём, как проверить права, восстановить корректную конфигурацию и при необходимости полностью отключить сбор отчётов.
Что такое ABRT и почему возникает ошибка записи
ABRT — это служба в дистрибутивах семейства RHEL, CentOS, Fedora, AlmaLinux, Rocky Linux, которая перехватывает падения приложений (core dump) и сохраняет их вместе с диагностической информацией. Демон abrtd работает отдельно от обычных пользователей и пишет данные в выделенный каталог, доступ к которому строго ограничен из соображений безопасности.
Сообщение «отказано в доступе» означает, что на этапе записи файла ядро отклонило системный вызов. Возможные причины:
- 🔧 Изменён владелец или права каталога
/var/spool/abrt(например, после ручной очистки диска командойrm -rfи последующего пересоздания каталога). - 📁 Каталог удалён вовсе, и ABRT не может его создать заново из-за прав на родительский путь.
- 🛡️ Политика SELinux блокирует запись — типично после восстановления файлов из резервной копии без сохранения контекстов безопасности.
- 💾 Переполнен раздел или исчерпаны inode — в этом случае ошибка может сопровождаться сообщениями о нехватке места.
Как определить, куда именно ABRT не может записать
Первый шаг — посмотреть точный текст ошибки в журнале. Выполните в терминале:
journalctl -u abrtd -n 100 --no-pagerТакже полезно проверить общий системный журнал на наличие строк с упоминанием abrt:
grep -i abrt /var/log/messages | tail -20В выводе обычно виден путь, по которому произошёл отказ. Заодно проверьте, какой каталог задан в конфигурации службы — он указывается параметром DumpLocation в файле /etc/abrt/abrt.conf. Посмотреть значение можно командой:
grep DumpLocation /etc/abrt/abrt.confЕсли параметр закомментирован, используется значение по умолчанию, заданное при сборке пакета (в большинстве случаев это /var/spool/abrt или /var/tmp/abrt — зависит от версии дистрибутива).
Проверка и восстановление прав на каталог ABRT
Убедившись, какой каталог используется, проверьте его владельца и права:
ls -ld /var/spool/abrtВ стандартной установке каталог принадлежит пользователю и группе abrt, а права ограничены — обычно это 0751 или похожая маска (точное значение зависит от версии пакета, сверьтесь с документацией своего дистрибутива). Если вы видите владельца root:root или каталог отсутствует, восстановите структуру:
mkdir -p /var/spool/abrt
chown abrt:abrt /var/spool/abrt
chmod 0751 /var/spool/abrt
⚠️ Внимание: не назначайте каталогу ABRT права 0777 «для проверки». Дампы памяти могут содержать пароли, ключи и пользовательские данные — открытый доступ к ним создаёт реальную уязвимость.
После исправления прав перезапустите службу:
systemctl restart abrtd☑️ Восстановление прав ABRT
Ошибка из-за SELinux: диагностика и исправление
Если права и владелец корректны, а ошибка «отказано в доступе» сохраняется, вероятный виновник — SELinux. Это особенно актуально после восстановления файлов из бэкапа, переноса системы на другой диск или ручного пересоздания каталогов: стандартные права при этом сохраняются, а расширенные атрибуты безопасности теряются.
Проверить, блокирует ли SELinux запись, можно через журнал аудита:
ausearch -m avc -ts recent | grep abrtЕсли в выводе есть записи denied для процессов abrt, восстановите штатные контексты безопасности на каталоге:
restorecon -Rv /var/spool/abrt⚠️ Внимание: не переводите SELinux в режимpermissiveи не отключайте его целиком ради устранения одной ошибки записи. Это снимает защиту со всей системы. Корректный путь — восстановить контексты командойrestoreconили разобрать конкретное правило черезaudit2allow.
Что делать, если restorecon не помог
Проверьте текущий режим командой getenforce. Если SELinux в enforcing и отказы продолжаются, соберите свежие записи аудита: ausearch -m avc -ts recent. Иногда причина в нестандартном DumpLocation — для каталога вне штатных путей нужно вручную назначить контекст через semanage fcontext и затем применить restorecon. Точные типы контекстов зависят от версии политики, поэтому сверяйтесь с документацией вашего дистрибутива.
Проверка свободного места и лимитов
Менее очевидная, но встречающаяся причина — невозможность записи из-за переполнения файловой системы. Сообщение об ошибке в этом случае может отличаться, но иногда сопровождается теми же отказами при создании файлов. Проверьте раздел, на котором находится каталог ABRT:
df -h /var/spool/abrt
df -i /var/spool/abrt
Вторая команда показывает заполненность по inode — каталог с тысячами мелких дампов может исчерпать их даже при наличии свободных гигабайт. Также в /etc/abrt/abrt.conf есть параметр MaxCrashReportsSize, ограничивающий суммарный размер хранимых дампов; при его превышении старые отчёты удаляются, но при сбоях в этом механизме возможны ошибки.
Очистить накопленные отчёты можно штатной командой:
abrt-cli list
abrt-cli rm /var/spool/abrt/имя_каталога_дампа
Сравнение типичных причин и способов устранения
| Причина | Как распознать | Решение |
|---|---|---|
| Неверный владелец каталога | ls -ld показывает root вместо abrt | chown abrt:abrt на каталог дампов |
| Каталог удалён | Ошибка «No such file or directory» в журнале | Создать каталог, назначить права, перезапустить abrtd |
| Блокировка SELinux | Записи denied в ausearch -m avc | restorecon -Rv на каталог |
| Переполнение раздела или inode | df -h / df -i показывают 100% | Очистить старые дампы через abrt-cli |
| Повреждённая установка пакета | Ошибки сохраняются после всех проверок | Переустановить пакеты abrt |
Переустановка ABRT и полное отключение службы
Если ни одна из проверок не помогла, возможно, повреждены файлы самого пакета. Переустановка выполняется стандартным менеджером пакетов:
dnf reinstall abrt abrt-addon-ccpp abrt-daemonСостав пакетов отличается между версиями дистрибутивов — список установленных компонентов можно посмотреть командой rpm -qa | grep abrt.
На серверах, где сбор отчётов о сбоях не нужен (например, дампы обрабатываются через systemd-coredump или мониторинг построен иначе), допустимо полностью отключить ABRT:
systemctl stop abrtd abrt-ccpp
systemctl disable abrtd abrt-ccpp
Учтите, что после отключения отчёты о падениях приложений формироваться не будут — диагностировать причины внезапных завершений станет сложнее. На рабочих станциях с графическим окружением это также уберёт уведомления о сбоях программ.
Частые вопросы
Опасна ли ошибка «write error abrt: отказано в доступе» для системы?
Сама по себе — нет. Она означает лишь, что отчёт о падении какого-то приложения не был сохранён. Однако стоит выяснить, какое приложение падает: частые сбои одной и той же программы могут указывать на реальную проблему.
Как узнать, какая программа вызвала сбой?
Используйте abrt-cli list — для каждого сохранённого дампа показывается имя исполняемого файла и время сбоя. Если дампы не сохраняются из-за ошибки прав, смотрите журнал: journalctl -e рядом с моментом ошибки abrt обычно есть запись о завершившемся процессе.
Можно ли просто удалить пакет abrt?
Да, пакет удаляется через dnf remove abrt, но вместе с ним могут быть удалены связанные компоненты уведомлений рабочего стола. На сервере это обычно безболезненно, на десктопе — проверьте список удаляемых зависимостей перед подтверждением.
Почему ошибка появилась после очистки диска?
Типичный сценарий: каталог /var/spool/abrt удалили вместе с содержимым, а затем создали заново от root. Владелец и контекст SELinux при этом не совпадают с ожидаемыми службой. Решение — назначить владельца abrt:abrt и выполнить restorecon.
Чем ABRT отличается от systemd-coredump?
Обе службы перехватывают падения приложений, но хранят дампы по-разному: ABRT пишет их в файлы в своём каталоге, а systemd-coredump — в журнал systemd с управлением через coredumpctl. В некоторых дистрибутивах используется только один из механизмов.