Как сбросить пароль для MySQL в 2025м году
Статья, которой по идее не должно было появиться на свет и которая ярко иллюстрирует разницу между теорией и практикой.
Да, я понимаю что это п#здец после статей про кросс-компиляцию FreeBSD→CP/M или «разработку на Java без всего» мягко говоря странно писать на столь любительскую тему — говностатей в интернете, рассказывающих как сбросить этот долбаный пароль навалом.
Но только все они.. ныне не работают.
Однако обратная совместимость ныне не в чести даже у столь известных и популярных проектов как MySQL.
Проблема
Как нетрудно догадаться, автор занимается разработкой ПО, поэтому у него регулярно на рабочих машинах появляются самые разные базы данных.
Чаще всего это PostgreSQL, но пара проектов потребовала когда-то установки MySQL, что я и сделал, развернув стандартный MySQL Server из пакетов в одной из рабочих машин на Ubuntu Linux.
И про него успешно забыл.
Прошел год, затем другой, Ubuntu все это время обновлялась, как и MySQL сервер.
Наконец появилась производственная необходимость развернуть образ базы в MySQL, из-за чего я открыл любимый DBeaver, попытался подключиться и.. получил ошибку авторизации.
Открыл консоль и попытался подключиться стандартным клиентом:
Да, я самым банальным образом забыл пароль от пользователя root, который в MySQL до сих пор отвечает за полный доступ и имеет все права.
Ресерч
Беглый поиск в интернете (на всякий случай добавлю, что это тоже самое сейчас что и запрос к ChatGPT) выдал кучу однотипных статей разных лет, не учитывающих современные реалии:
Думаю нетрудно догадаться что MySQL развивается и за 12 лет успело многое поменяться, поэтому AI-выдача также показала логически верный, технически правильный но неработающий ответ:
Решение
Итак, речь в статье пойдет про 8.4 версию оригинального MySQL, выпускаемого ныне корпорацией Oracle, не про его форк MariaDB:
Действие происходит на обычной Ubuntu:
С начала времен безопасность в MySQL была предметом шуток и анекдотов, поскольку всегда была отключаемой.
Так что вся эта проблема со сбросом пароля в MySQL — сама по себе тянет на хороший анекдот.
Собственно эта команда как раз и отвечала за запуск движка СУБД без всякой авторизации:
mysqld_safe --skip-grant-tables --skip-networking
Но только в новых версиях MySQL есть нюанс:
mysqld_safe это на самом деле шелл-скрипт, который использует каталог /var/run/mysqld, которого внезапно при обычном использовании MySQL-сервера не создается.
Без этого каталога mysqld_safe не запустится, выдав что-то типа такого:
mysqld_safe --skip-grant-tables --skip-networking 2025-09-20T15:28:00.145945Z mysqld_safe Logging to '/var/log/mysql/error.log'. 2025-09-20T15:28:00.148210Z mysqld_safe Directory '/var/run/mysqld' for UNIX socket file don't exists.
Так что каталог придется создать:
mkdir -p /var/run/mysqld
Но и это тоже еще не все, при попытке запуска mysqld_safe банально упадет:
mysqld_safe --skip-grant-tables --skip-networking 2025-09-20T15:30:10.637905Z mysqld_safe Logging to '/var/log/mysql/error.log'. 2025-09-20T15:30:10.658364Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 2025-09-20T15:30:13.317240Z mysqld_safe mysqld from pid file /var/lib/mysql/ubunchu.pid ended
Проблема в том что mysqld_safe это скрипт, который запускает настоящий бинарник (приложение) сервера MySQL и контролирует его состояние.
И запускает процесс mysqld он внезапно от пользователя mysql, у которого нет прав на этот каталог.
сhown mysql /var/run/mysqld/
Теперь наконец mysqld_safe запустится:
mysqld_safe --skip-grant-tables --skip-networking 2025-09-20T15:33:31.905740Z mysqld_safe Logging to '/var/log/mysql/error.log'. 2025-09-20T15:33:31.925688Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
И можно подключиться клиентом:
По классике пароль в MySQL сбрасывается с помощью вот такого SQL-запроса:
ALTER USER 'root'@'localhost' IDENTIFIED BY 'password';
Именно такой вариант вам подскажет любимая нейросеть:
Но только на практике оно больше не работает:
mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'password'; ERROR 1524 (HY000): Plugin 'auth_socket' is not loaded
use mysql; update user set authentication_string='' where User='root'; update user set plugin="mysql_native_password" where User='root'; FLUSH PRIVILEGES;
Теперь наконец грохаем процессы mysql, поскольку по-другому остановить mysqld_safe не выйдет:
pkill -9 mysql
И включаем эти самые native_password (хотя-бы временно):
echo mysql_native_password=ON >> /etc/mysql/mysql.conf.d/mysqld.cnf
Теперь наконец можно запустить MySQL-сервер в штатном режиме:
systemctl start mysql
Процесс mysqld должен быть виден в списке запущенных, а статус сервиса должен выглядеть как-то так:
Также теперь должно проходить подключение с помощью консольного клиента с пустым паролем:
Разумеется решение временное, поэтому дальше надо запустить скрипт mysql_secure_installation и с его помощью закончить настройку, в том числе задав новый пароль root и отключив поддержку native_password.