Ошибка вида abrt: can't open ... Permission denied или сообщение «abrt: отказано в доступе» обычно появляется, когда служба ABRT (Automatic Bug Reporting Tool) не может записать дамп сбоя в свой рабочий каталог — чаще всего /var/spool/abrt или /var/tmp/abrt в зависимости от версии дистрибутива. Служба работает от отдельного системного пользователя abrt, и любое нарушение прав на каталоги, политики SELinux или запуск инструментов от неподходящей учётной записи приводит к отказу в доступе.
Проблема характерна для систем семейства RHEL, CentOS, Fedora, AlmaLinux, Rocky Linux, где ABRT установлен по умолчанию. Ниже разберём, как диагностировать источник ошибки и устранить её без риска для системы. Конкретные пути и названия сервисов могут отличаться между версиями, поэтому перед изменениями стоит свериться с документацией вашего дистрибутива.
Что означает ошибка и когда она возникает
ABRT перехватывает аварийные завершения программ, собирает core-дампы и формирует отчёты. Сообщение об отказе в доступе появляется в нескольких типичных сценариях: при попытке демона abrtd создать каталог проблемы, при запуске утилиты abrt-cli от обычного пользователя без нужных полномочий, либо когда SELinux блокирует запись даже при корректных правах файловой системы.
Типичные признаки проблемы:
- 🔴 В журнале (
journalctl -u abrtd) повторяются строки с Permission denied при обращении к каталогу дампов; - 🟡 Команда
abrt-cli listвыдаёт ошибку доступа вместо списка проблем; - 🟠 Уведомления о сбоях не появляются, хотя приложения падают;
- 🔵 Каталог
/var/spool/abrtпуст или содержит неполные каталоги проблем.
Шаг 1. Проверка состояния службы и журналов
Первое действие — убедиться, что служба вообще запущена, и посмотреть, какое именно обращение блокируется. Выполните в терминале:
systemctl status abrtd
journalctl -u abrtd -n 50 --no-pager
В выводе журнала ищите строки с указанием пути, к которому нет доступа. Именно этот путь станет объектом дальнейшей проверки. Если служба остановлена, попробуйте запустить её командой sudo systemctl start abrtd и понаблюдайте за журналом повторно.
Также полезно проверить журнал аудита SELinux — отказы могут регистрироваться там, а не в журнале самой службы:
sudo ausearch -m avc -ts recent | grep abrtШаг 2. Проверка прав на каталог дампов
Наиболее частая причина — некорректные владелец или права на рабочий каталог ABRT. Такое случается после ручной очистки каталога, восстановления из резервной копии или переноса системы. Проверьте текущее состояние:
ls -ld /var/spool/abrt /var/tmp/abrt 2>/dev/nullВ типичной конфигурации каталог должен принадлежать пользователю и группе abrt и иметь ограниченные права, поскольку дампы могут содержать чувствительные данные. Если владелец сбит, вернуть его можно так (путь уточните по выводу предыдущей команды и конфигурации вашей системы):
sudo chown -R abrt:abrt /var/spool/abrt
sudo chmod 0755 /var/spool/abrt
⚠️ Внимание: не выставляйте на каталог дампов права
777«для проверки». Core-дампы могут содержать пароли, ключи и содержимое памяти приложений — широкий доступ создаёт реальную угрозу безопасности. Если ошибка исчезает только при чрезмерно широких правах, ищите причину в SELinux или владельце, а не ослабляйте права навсегда.
☑️ Диагностика прав доступа ABRT
Шаг 3. SELinux как источник блокировки
На системах с включённым SELinux (режим enforcing) отказ в доступе может возникать даже при идеально выставленных правах файловой системы. Например, если каталог дампов был перенесён в нестандартное место, его контекст безопасности не совпадает с ожидаемым политикой.
Проверить текущий режим можно командой getenforce. Если обнаружены отказы (AVC) в аудите, связанные с abrt, возможные действия:
- 🛡️ Восстановить контекст каталога командой
sudo restorecon -Rv /var/spool/abrt; - 📋 Изучить конкретный отказ через
audit2why, чтобы понять, какая политика сработала; - ⚙️ При нестандартном расположении каталога — зарегистрировать его контекст через
semanage fcontextс последующимrestorecon.
⚠️ Внимание: не переводите SELinux в режим disabled ради устранения одной ошибки. Это снимает защиту со всей системы. Если нужно временно проверить гипотезу, используйте
sudo setenforce 0(режим permissive до перезагрузки), а после подтверждения причины настройте корректный контекст и верните enforcing.
Шаг 4. Запуск abrt-cli с нужными привилегиями
Если ошибка возникает при работе с командной утилитой, проверьте, от какого пользователя она запущена. Просмотр и обработка отчётов требуют либо прав root, либо членства в соответствующей группе — в зависимости от конфигурации дистрибутива.
Попробуйте выполнить команду с повышением привилегий:
sudo abrt-cli listЕсли с sudo список отображается, а без него — отказ в доступе, проблема не в службе, а в полномочиях вашей учётной записи. Варианты решения: работать через sudo либо добавить пользователя в группу, которой разрешён доступ к отчётам (название группы уточните в документации дистрибутива, оно различается между версиями).
Сравнение типичных причин и способов устранения
| Причина | Как распознать | Решение |
|---|---|---|
| Неверный владелец каталога дампов | ls -ld показывает root вместо abrt | chown abrt:abrt на каталог |
| Блокировка SELinux | Отказы AVC в ausearch -m avc | restorecon или настройка контекста |
| Запуск abrt-cli без привилегий | Ошибка исчезает с sudo | sudo или членство в нужной группе |
| Служба abrtd остановлена | systemctl status показывает inactive | Запуск и автозапуск службы |
| Повреждённый каталог проблемы | Ошибка на конкретном подкаталоге | Удаление битого каталога проблемы |
Если ничего не помогло
Когда права, SELinux и привилегии проверены, а ошибка сохраняется, остаются более глубокие варианты. Во-первых, проверьте, не переполнен ли раздел, на котором расположен каталог дампов: df -h /var — при заполнении файловой системы запись также становится невозможной. Во-вторых, убедитесь, что раздел не смонтирован в режиме только для чтения: это бывает после ошибок файловой системы, и признаки видны в выводе mount и dmesg.
Дополнительный вариант — переустановка пакетов ABRT с восстановлением структуры каталогов штатными средствами пакетного менеджера, например sudo dnf reinstall abrt в системах на базе RPM. Перед этим сохраните нужные отчёты о сбоях, если они представляют ценность.
Как ABRT обрабатывает сбой изнутри
При падении приложения ядро через механизм core_pattern передаёт дамп обработчику ABRT. Демон abrtd создаёт каталог проблемы в рабочем каталоге, сохраняет туда дамп и метаданные (командную строку, время, исполняемый файл), затем анализирует сбой и может сформировать backtrace. Отказ в доступе на любом из этих этапов прерывает цепочку — поэтому в журнале важно найти, на каком именно пути произошла ошибка.
Часто задаваемые вопросы
Можно ли просто удалить каталог /var/spool/abrt и создать заново?
Каталог можно пересоздать, но обязательно с правильным владельцем abrt:abrt и корректным контекстом SELinux (поможет restorecon). Учтите, что вместе с каталогом удалятся все сохранённые отчёты о сбоях.
Ошибка появляется только для одной программы — в чём дело?
Возможно, повреждён конкретный каталог проблемы внутри рабочего каталога ABRT. Найдите его по журналу и удалите именно этот подкаталог, не трогая остальные отчёты.
Безопасно ли отключить ABRT совсем?
Да, служба не критична для работы системы: sudo systemctl disable --now abrtd отключит сбор отчётов. Однако вы лишитесь удобной диагностики сбоев приложений, поэтому предпочтительнее всё же устранить проблему с доступом.
Почему после обновления системы ошибка вернулась?
Обновление пакетов или политик SELinux иногда меняет контексты безопасности или структуру каталогов. Повторите проверку владельца каталога и выполните restorecon — обычно этого достаточно.
Где посмотреть, какой путь использует ABRT в моей системе?
Загляните в конфигурационные файлы в /etc/abrt/ — там задаётся расположение рабочего каталога. Также путь фигурирует в сообщениях об ошибке в журнале службы.