SystemdDoctor
служба не работает базы данных защита права

База не запускается после переноса каталога данных

Перенос каталога данных базы требует изменений в трёх местах: в настройках базы, в профиле защиты и в описании службы. Правка только настроек даёт отказ доступа, который легко принять за проблему с правами файлов.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Профиль защиты разрешает только прежний путь

    Профиль перечисляет пути, доступные службе. Новый каталог в него не входит, и доступ отклоняется.

  2. Права и владелец нового каталога не те

    После копирования владельцем остаётся root, а служба работает от своего пользователя.

  3. Служба не зависит от монтирования нового раздела

    Если данные на отдельном разделе, база может стартовать раньше его монтирования.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Сообщения базы при попытке запуска.

journalctl -u mysql -n 30 --no-pager 2>/dev/null

Отказы профиля защиты.

journalctl -k -b --no-pager | grep -i 'apparmor="DENIED"' | tail

Владелец нового каталога и пользователь службы.

sudo ls -ld /srv/mysql && systemctl show mysql -p User

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Профиль защиты разрешает только прежний путь
Почему происходит
Профиль перечисляет пути, доступные службе. Новый каталог в него не входит, и доступ отклоняется.
Как проверить
Посмотрите отказы профиля и его правила. 
journalctl -k -b --no-pager | grep -i 'apparmor="DENIED"' | grep -i mysql | tail -3
sudo grep -rn "/var/lib/mysql" /etc/apparmor.d/ 2>/dev/null | head
Как исправить
Добавьте новый путь в профиль и перезагрузите его. Отключать профиль ради переноса не стоит: он защищает базу от доступа через другие службы.
2. Права и владелец нового каталога не те
Почему происходит
После копирования владельцем остаётся root, а служба работает от своего пользователя.
Как проверить
Посмотрите владельца нового каталога. 
sudo ls -ld /srv/mysql 2>/dev/null
systemctl show mysql -p User 2>/dev/null; id mysql
Как исправить
Передайте каталог пользователю базы с сохранением прав внутри. Копировать надо с сохранением атрибутов, иначе права внутри тоже потеряются.
3. Служба не зависит от монтирования нового раздела
Почему происходит
Если данные на отдельном разделе, база может стартовать раньше его монтирования.
Как проверить
Посмотрите зависимости службы и точку монтирования. 
systemctl show mysql -p RequiresMountsFor -p After 2>/dev/null
findmnt -T /srv/mysql -o TARGET,SOURCE 2>/dev/null
Как исправить
Объявите зависимость от пути данных в описании службы. Иначе после перезагрузки база иногда будет стартовать на пустом каталоге. 
[Unit]
RequiresMountsFor=/srv/mysql

Пример вывода

Профиль защиты не разрешает новый путь. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

kernel: audit: apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/srv/mysql/ibdata1" pid=11900 comm="mysqld" requested_mask="rwc" denied_mask="rwc"
mysqld[11900]: [ERROR] [MY-012574] [InnoDB] Unable to lock /srv/mysql/ibdata1 error: 13
systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

Где встречается чаще всего

Источники

  • apparmor(7)
    Профили защиты и разрешённые пути.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено переносом каталога данных без правки профиля защиты.     собственная проверка, systemd 255
    сверено 15 сентября 2026