MySQL- und MariaDB-Root-Passwort zurücksetzen

Das Root-Passwort der Datenbank ist eines von diesen Passwörtern, die man einmal bei der Installation setzt und danach nie wieder braucht, weil alle Anwendungen mit eigenen Accounts arbeiten. Bis zu dem Tag, an dem man doch dran muss. Dann steht da:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Die Standardantwort im Netz lautet: Dienst stoppen, mit --skip-grant-tables starten, Passwort setzen, fertig. Das stimmt, ist aber nur die halbe Wahrheit. In dieser Anleitung steht auch, warum der überall kopierte Befehl auf Ubuntu mit MySQL 8 wirkungslos ist, warum Sie in vielen Fällen gar kein Passwort brauchen, und was Sie tun, wenn der Dienst danach gar nicht mehr startet.

Erst prüfen: wahrscheinlich brauchen Sie gar kein Passwort

Auf Debian und Ubuntu ist der Datenbank-Root seit Jahren nicht mehr über ein Passwort abgesichert, sondern über die Identität des Systembenutzers. MariaDB nennt das Verfahren unix_socket, MySQL nennt es auth_socket. Gemeint ist dasselbe: Wer sich über den lokalen Socket verbindet und auf Betriebssystemebene bereits root ist, kommt ohne Passwort rein. Die Begründung dahinter ist schlicht, dass ein Systembenutzer root ohnehin an alle Datendateien und an den Arbeitsspeicher des Prozesses kommt, ein zusätzliches Passwort also keine Hürde darstellt.

Der erste Versuch sollte deshalb immer der hier sein:

sudo mariadb
sudo mysql

Beachten Sie: sudo mysql -u root -p funktioniert nicht, weil das -p auf Passwortauthentifizierung umschaltet. Genau daran scheitern die meisten. Ohne -p und mit sudo landen Sie in der Regel direkt im Prompt. Von dort setzen Sie das Passwort in zwei Sekunden neu, ohne die Datenbank überhaupt anzufassen.

Der zweite Rettungsweg ist der Wartungsaccount der Distribution. Auf Ubuntu mit dem Paket mysql-server gibt es weiterhin die Datei /etc/mysql/debian.cnf, die Zugangsdaten für einen Account mit vollen Rechten enthält, lesbar nur für root:

sudo ls -l /etc/mysql/debian.cnf
sudo mysql --defaults-file=/etc/mysql/debian.cnf -e "SELECT current_user();"

Kommt hier eine Zeile zurück, sind Sie drin und können sofort weiterarbeiten. Erwarten Sie dabei nicht root@localhost: die Abfrage antwortet mit debian-sys-maint@localhost. Das ist richtig so, denn dieses Wartungskonto hat ALL PRIVILEGES und reicht für den Reset vollkommen aus, Sie sind damit aber nicht root. Dieser Weg ist außerdem rein Debian- und Ubuntu-spezifisch. Auf AlmaLinux, Rocky Linux und Oracle Linux existiert weder das Verzeichnis /etc/mysql/ noch das Konto, dort greift stattdessen der Socket-Login als root aus dem vorigen Abschnitt. Bei MariaDB ab 10.4 wird dieser Account nicht mehr neu angelegt (die Datei verweist dort meist einfach auf root über den Socket), bei bestehenden Installationen ist er aber oft noch vorhanden. Ein Blick kostet nichts und spart Ihnen im Erfolgsfall den kompletten Rest dieser Anleitung.

Welche Datenbank läuft hier eigentlich?

Das ist keine Formalie, sondern entscheidet über jeden folgenden Befehl. Auf Debian gibt es seit Jahren kein Paket mysql-server mehr im offiziellen Archiv, dort läuft praktisch immer MariaDB, auch wenn der Befehl mysql existiert. Der ist nämlich nur ein Symlink auf den MariaDB-Client. Aktuell finden Sie in den Distributionen:

Fragen Sie den Server selbst, nicht den Client:

systemctl list-units --type=service --all | grep -Ei 'mysql|mariadb'
mysqladmin --version
mariadbd --version

Das --all gehört dazu, weil list-units sonst nur geladene, aktive Units zeigt. Genau in dem Fall, in dem Sie den Befehl brauchen, nämlich bei einem Dienst, der nicht läuft, bliebe die Ausgabe sonst leer. mysqladmin --version gibt es auf beiden Seiten und es nennt die Engine im Klartext, MariaDB-Systeme antworten mit ... Distrib 11.8.6-MariaDB .... Bei mariadbd --version ist command not found auf einem reinen MySQL-System das erwartete Ergebnis und kein Fehler, spiegelbildlich gilt dasselbe für mysqld-spezifische Befehle auf einem reinen MariaDB-System.

Heißt die Unit mariadb.service, arbeiten Sie mit MariaDB. Heißt sie mysql.service, mit MySQL. Auf Systemen mit MariaDB existiert zusätzlich ein Alias mysql.service, der auf mariadb.service zeigt, deshalb ist die Ausgabe von systemctl list-units aussagekräftiger als das reine Vorhandensein eines Namens.

Die Unit-Namen selbst unterscheiden sich zwischen den Distributionsfamilien, und alle folgenden systemctl-Aufrufe dieser Anleitung sind auf Debian und Ubuntu geschrieben. Auf der Red-Hat-Familie gibt es überhaupt keine Unit namens mysql.service, dort antwortet systemctl status mysql mit Unit mysql.service could not be found. Setzen Sie in dem Fall durchgehend die Namen aus der rechten Spalte ein, auch im Pfad des Drop-in-Verzeichnisses:

Vorher abschotten: warum dieser Schritt nicht optional ist

Mit --skip-grant-tables liest der Server die Rechtetabellen nicht ein. Das bedeutet nicht "Root darf ohne Passwort rein", sondern "jeder darf alles, ohne Passwort, als beliebiger Benutzer". Es gibt in diesem Zustand keine Authentifizierung und keine Rechteprüfung, auch nicht für Ihre Kundendatenbanken.

MySQL 8 schaltet in diesem Fall automatisch skip_networking mit ein, nimmt also keine TCP-Verbindungen mehr an. Verlassen Sie sich trotzdem nicht darauf, sondern setzen Sie die Option immer selbst dazu. Bei MariaDB ist das ohnehin die dokumentierte Empfehlung, und wer beide Systeme betreut, will sich nicht merken müssen, welches davon mitdenkt.

--skip-grant-tables --skip-networking

Zwei Punkte, die dabei gern übersehen werden. Erstens: skip_networking schließt nur den Netzwerkport. Der Unix-Socket unter /run/mysqld/mysqld.sock bleibt offen, und der ist auf vielen Systemen für alle lokalen Benutzer erreichbar. Ein kompromittierter PHP-Prozess unter www-data kann in diesem Fenster jede Datenbank auf dem Server auslesen. Halten Sie das Fenster deshalb so kurz wie möglich und führen Sie die Aktion nicht durch, während ein Webserver mit unbekanntem Code läuft. Zweitens: Stoppen Sie vorher alles, was sich automatisch verbindet, also Webserver und Anwendungsdienste. Deren Verbindungsversuche stören nicht nur, sie laufen in diesem Zustand mit vollen Rechten.

Wenn der Server von außen erreichbar ist, ziehen Sie zusätzlich die Firewall zu. Wie Sie das dauerhaft sauber aufsetzen, steht in UFW-Firewall einrichten.

sudo apt-get install -y ufw
sudo ufw deny 3306/tcp
sudo ss -ltnp | grep 3306

Die erste Zeile ist kein Überfluss: Auf einer minimalen Debian-Installation ist ufw nicht vorinstalliert, der Befehl endet sonst mit sudo: ufw: command not found. Auf AlmaLinux, Rocky Linux und RHEL gibt es ufw gar nicht, dort läuft die Paketfilterung über firewalld:

sudo firewall-cmd --permanent --remove-service=mysql
sudo firewall-cmd --reload

Auf allen geprüften Debian- und Ubuntu-Installationen steht bind-address ohnehin auf 127.0.0.1, per ss -ltnp bestätigt. Dann nimmt der Server von außen ohnehin keine Verbindung an, und die Firewallregel ist die zweite Sicherung, nicht der eigentliche Schutz.

MariaDB: Passwort zurücksetzen

Die Unit von MariaDB startet den Server mit ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS. Diese Variable ist genau für solche Fälle vorgesehen, Sie brauchen also keine Datei zu bearbeiten. Prüfen Sie es kurz nach, dann wissen Sie, dass der folgende Weg auf Ihrem System greift:

systemctl cat mariadb | grep ExecStart

Dann in dieser Reihenfolge:

sudo systemctl stop mariadb
sudo systemctl set-environment MYSQLD_OPTS="--skip-grant-tables --skip-networking"
sudo systemctl start mariadb
sudo mariadb -u root

Im Prompt kommt zuerst FLUSH PRIVILEGES. Ohne diesen Schritt hat der Server die Rechtetabellen noch gar nicht im Speicher und weist jede Kontoverwaltung ab. Danach setzen Sie das Passwort:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket OR mysql_native_password USING PASSWORD('IhrNeuesPasswort');

Diese etwas sperrige Schreibweise ist Absicht und der wichtigste MariaDB-spezifische Punkt der ganzen Anleitung. MariaDB kann seit 10.4 mehrere Authentifizierungsverfahren pro Konto führen, und genau so ist root nach einer Paketinstallation eingerichtet: erst Socket, ersatzweise Passwort. Wenn Sie stattdessen das schlichte ALTER USER 'root'@'localhost' IDENTIFIED BY '...' verwenden, ersetzen Sie die gesamte Kette durch reine Passwortauthentifizierung. Das funktioniert, aber danach klappt sudo mariadb ohne Passwort nicht mehr, und interne Wartungsskripte der Distribution, die sich auf den Socket verlassen, laufen ins Leere. Sie haben sich das Problem dann nur um ein Jahr verschoben.

Zum Schluss räumen Sie den Sonderzustand wieder ab:

sudo systemctl stop mariadb
sudo systemctl unset-environment MYSQLD_OPTS
sudo systemctl start mariadb

Vergessen Sie unset-environment nicht. Die Variable hängt am systemd-Manager, nicht am Dienst, und überlebt jeden Neustart des Dienstes. Wenn nachts ein Paketupdate MariaDB neu startet, läuft Ihre Datenbank ab dann ohne jede Rechteprüfung weiter, und niemand merkt es. Erst ein Reboot des Servers räumt die Variable von selbst weg.

MySQL 8: der Befehl aus den meisten Anleitungen tut hier nichts

Für MySQL kursiert dasselbe Rezept mit systemctl set-environment MYSQLD_OPTS=.... Es stammt aus der Dokumentation von Oracle und passt zu deren eigenen Paketen. Die Unit aus dem Ubuntu-Archiv sieht aber anders aus, dort steht schlicht ExecStart=/usr/sbin/mysqld, ohne Variable. Der Befehl läuft durch, meldet keinen Fehler, und der Server startet trotzdem ganz normal mit aktiver Rechteprüfung. Sie sitzen dann vor einem Access denied und wundern sich. Prüfen Sie es selbst:

systemctl cat mysql | grep ExecStart

Taucht dort kein $MYSQLD_OPTS auf, brauchen Sie ein Drop-in. Und wenn Sie schon eines anlegen, nehmen Sie gleich den besseren Weg: --init-file. Damit startet der Server ganz normal mit Rechteprüfung und führt beim Hochfahren eine SQL-Datei mit vollen Rechten aus. Es gibt kein offenes Zeitfenster, in dem irgendjemand ohne Passwort hineinkommt. Oracle empfiehlt diese Variante ausdrücklich vor --skip-grant-tables.

sudo systemctl stop mysql
printf "ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'IhrNeuesPasswort';\n" | sudo tee /var/lib/mysql-files/kh-reset.sql
sudo chown mysql:mysql /var/lib/mysql-files/kh-reset.sql
sudo chmod 600 /var/lib/mysql-files/kh-reset.sql
sudo mkdir -p /etc/systemd/system/mysql.service.d

Das IDENTIFIED WITH caching_sha2_password ist der entscheidende Teil und der Grund, warum unzählige Anleitungen an dieser Stelle scheitern, ohne einen Fehler zu zeigen. Auf Debian und Ubuntu benutzt root@localhost auch bei MySQL das Plugin auth_socket. Ein schlichtes IDENTIFIED BY 'passwort' setzt zwar den Passwort-Hash, wechselt das Plugin aber nicht. In mysql.user steht danach weiterhin auth_socket, der Dienst startet sauber, es erscheint keine einzige Fehlermeldung, und trotzdem endet jeder Passwort-Login mit ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Besonders tückisch: Wer die Gegenprobe als Systembenutzer root macht, lässt auth_socket ihn ohne Passwort durch und hält den Reset für gelungen. Testen Sie deshalb aus einem anderen Konto oder über TCP. Nur bei sehr alten Clients, die caching_sha2_password nicht beherrschen, setzen Sie stattdessen mysql_native_password ein, mit den Einschränkungen aus dem Absatz weiter unten.

Das Verzeichnis /var/lib/mysql-files ist bewusst gewählt: Es gehört dem Datenbankbenutzer und ist im AppArmor-Profil von mysqld freigegeben. Legen Sie die Datei nach /root oder /tmp, scheitert der Start unter Umständen an AppArmor, und die Meldung im Log ist wenig hilfreich. Jetzt das Drop-in:

[Service]
ExecStart=
ExecStart=/usr/sbin/mysqld --init-file=/var/lib/mysql-files/kh-reset.sql

Die leere erste ExecStart-Zeile ist zwingend, sonst hängt systemd Ihren Befehl an den vorhandenen an und verweigert den Dienst mit einem Konfigurationsfehler. Speichern unter /etc/systemd/system/mysql.service.d/override.conf, dann:

sudo systemctl daemon-reload
sudo systemctl start mysql
sudo mysql -u root -p

Wenn der Login klappt, räumen Sie beides weg, die SQL-Datei und das Drop-in:

sudo rm -f /var/lib/mysql-files/kh-reset.sql
sudo rm -f /etc/systemd/system/mysql.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart mysql

Wollen Sie trotzdem den klassischen Weg, ersetzen Sie im Drop-in die Zeile durch ExecStart=/usr/sbin/mysqld --skip-grant-tables --skip-networking, verbinden sich mit sudo mysql und setzen dort erst FLUSH PRIVILEGES;, dann ALTER USER. Ein Hinweis zur Verschlüsselung: MySQL 8 nutzt standardmäßig caching_sha2_password. Wenn eine sehr alte Anwendung sich danach mit "The server requested authentication method unknown to the client" meldet, hilft IDENTIFIED WITH mysql_native_password BY '...'. Das ist aber eine Sackgasse, denn dieses Verfahren gilt seit 8.0.34 als veraltet und ist in MySQL 8.4 nicht mehr enthalten. Besser ist es, den Client zu aktualisieren.

Fehlermeldungen im Wortlaut

ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement. Sie haben FLUSH PRIVILEGES; vergessen. Absetzen, dann funktioniert ALTER USER.

ERROR 1288 (HY000): The target table user of the UPDATE is not updatable. Sie folgen einer alten Anleitung, die UPDATE mysql.user SET password=... vorschlägt. Ab MariaDB 10.4 liegen die Rechte in mysql.global_priv, und mysql.user ist nur noch eine Sicht darauf. Nehmen Sie ALTER USER oder SET PASSWORD. Nebenbei: Direktes Schreiben in die Rechtetabellen war auch früher schon eine gute Methode, sich das Konto endgültig zu zerlegen.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Kein falsches Passwort, sondern das Gegenteil: Das Konto erwartet Socket-Authentifizierung, und Sie sind nicht als Systembenutzer root unterwegs oder haben -p mitgegeben. Mit sudo und ohne -p erneut versuchen.

ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded. Das Konto verweist auf ein Plugin, das der laufende Server nicht kennt, typisch nach einem Wechsel von MariaDB zu MySQL oder nach dem Kopieren eines Datenverzeichnisses. Setzen Sie das Konto über den Weg oben auf ein passendes Verfahren um.

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2). Der Server läuft nicht. Erst systemctl status und Log ansehen, nicht am Client weiterprobieren.

mysqld: Can't create directory '/run/mysqld/' (Errcode: 13 - Permission denied) oder ein Start, der sofort wieder abbricht. Das passiert, wenn der Server per Hand statt über systemd gestartet wurde, weil dann das Laufzeitverzeichnis fehlt. Reparatur:

sudo mkdir -p /run/mysqld
sudo chown mysql:mysql /run/mysqld

Job for mysql.service failed because the control process exited with error code. Diese Meldung sagt für sich genommen nichts. Die eigentliche Ursache steht im Journal und im Fehlerlog:

sudo journalctl -u 'mysql*' -u 'mariadb*' -n 60 --no-pager

Das Muster mit beiden Unit-Namen ist bewusst gewählt, denn die naheliegende Einzelabfrage führt in eine stille Falle. Auf Debian mit MariaDB ist mysql.service nur ein Alias auf mariadb.service. systemctl löst den Alias auf, das Journal indiziert die Einträge aber unter dem echten Unit-Namen, und journalctl -u mysql antwortet deshalb mit -- No entries -- und Exit-Code 0, obwohl das Journal voll ist. Umgekehrt liefert journalctl -u mariadb auf einem Ubuntu-System mit MySQL ebenfalls -- No entries --.

Ähnlich verhält es sich mit der Fehlerdatei. Die überall zitierte /var/log/mysql/error.log existiert nur auf Ubuntu mit MySQL. Auf Debian mit MariaDB gibt es das Verzeichnis /var/log/mysql/ überhaupt nicht, weil log_error in 50-server.cnf auskommentiert ist und MariaDB ins Journal schreibt. Die passende Zeile je nach System:

Wenn Sie den Pfad nicht raten wollen, fragen Sie den Server selbst: sudo mariadb -e "SHOW VARIABLES LIKE 'log_error';" beziehungsweise dasselbe mit mysql.

Die drei häufigsten Ursachen an dieser Stelle: ein Tippfehler im Drop-in (dann meldet systemd die Zeile), eine volle Festplatte (dazu Festplatte voll unter Linux) oder ein zweiter Serverprozess, der noch läuft und die Datendateien gesperrt hält. Letzteres prüfen Sie mit pgrep -a mariadbd beziehungsweise pgrep -a mysqld, bevor Sie neu starten.

Wenn Sie nach dem Reset zwar hineinkommen, aber Ihre Anwendungen weiterhin abgewiesen werden, liegt das Problem woanders: Anwendungen wie WordPress oder Nextcloud benutzen eigene Datenbankbenutzer, nicht root. Details dazu in MySQL Access denied for user beheben.

Woran Sie erkennen, dass es wirklich funktioniert hat

Ein erfolgreicher Login allein reicht als Beweis nicht, denn der klappt im Notzustand auch ohne jedes Passwort. Prüfen Sie deshalb vier Dinge, nachdem der Dienst wieder normal läuft.

Erstens: Es liegt keine Sonderkonfiguration mehr an. Die erste Ausgabe muss leer sein, die zweite darf keine Zusatzoptionen mehr zeigen.

systemctl show-environment | grep MYSQLD_OPTS
systemctl cat mariadb | grep ExecStart

Zweitens: Die Rechteprüfung ist wieder aktiv. Ein Login mit absichtlich falschem Passwort muss scheitern. Wenn er durchgeht, läuft der Server immer noch offen.

Drittens: Das neue Passwort und das erwartete Verfahren stehen im Konto. In MariaDB fragen Sie das so ab, bei MySQL ohne die JSON-Spalte:

sudo mariadb -e "SELECT user, host, plugin FROM mysql.user WHERE user='root';"
sudo mysql -e "SELECT user, host, plugin FROM mysql.user WHERE user='root';"

Viertens: Der Netzwerkport verhält sich wieder wie vorher. Ein Datenbankserver, der nur lokal genutzt wird, sollte nach dem Aufräumen wieder ausschließlich auf 127.0.0.1 lauschen:

sudo ss -ltnp | grep 3306
grep -rs bind-address /etc/mysql/ /etc/my.cnf /etc/my.cnf.d/

Das -s und die drei Pfade sind Absicht. grep -r bind-address /etc/mysql/ allein bricht auf der Red-Hat-Familie mit No such file or directory ab, weil es dort kein /etc/mysql/ gibt. Mit -s übergeht grep die nicht vorhandenen Pfade stillschweigend, und die Zeile passt auf beide Welten.

Aufräumen, damit es kein zweites Mal passiert

Das Passwort steht jetzt möglicherweise an Stellen, an die Sie nicht denken. Ein Befehl mit -e "ALTER USER ... IDENTIFIED BY '...'" landet in ~/.bash_history, ein Prompt-Kommando in der History-Datei des Datenbankclients. Beides gehört bereinigt:

history -c
rm -f ~/.mysql_history ~/.mariadb_history

Beide Dateinamen sind nötig, weil der Client den Namen gewechselt hat. Bis MariaDB 10.11, also bis einschließlich Debian 12, schreibt er nach ~/.mysql_history. Ab MariaDB 11, also ab Debian 13, schreibt er nach ~/.mariadb_history. Wer dort nur die alte Datei löscht, lässt das im Klartext eingetippte Passwort auf der Platte liegen, ohne es zu merken. Noch besser ist es, die History gar nicht erst entstehen zu lassen: export MYSQL_HISTFILE=/dev/null beziehungsweise export MARIADB_HISTFILE=/dev/null vor der Sitzung, oder gleich der Weg über --init-file aus dem MySQL-Abschnitt, bei dem das Passwort nie durch eine interaktive Sitzung geht.

Sinnvoller als ein Passwort, das Sie in einem Jahr wieder vergessen, ist ein Setup ohne Passwort im Alltag. Auf Debian und Ubuntu heißt das: root bleibt bei unix_socket beziehungsweise auth_socket, und für alles andere legen Sie normale Benutzer mit genau den Rechten an, die die jeweilige Anwendung braucht. Wer den Zugang von einem anderen Rechner aus benötigt, tunnelt ihn über SSH statt Port 3306 zu öffnen, siehe Per SSH mit dem Server verbinden.

Wenn Sie ohnehin gerade an der Datenbank arbeiten, nehmen Sie den Rest gleich mit: anonyme Benutzer entfernen, die Testdatenbank löschen, den Fernzugriff für root abschalten. Das erledigt mariadb-secure-installation beziehungsweise mysql_secure_installation in wenigen Minuten, ausführlich beschrieben in MariaDB und MySQL absichern. Und weil das Passwort selten das einzige ist, was auf einem frisch übernommenen Server im Argen liegt, lohnt ein Durchgang durch die Checkliste für neue Rootserver.

Ein letzter Gedanke zur Reihenfolge: Bevor Sie einen laufenden Produktionsserver in den rechtefreien Zustand versetzen, machen Sie ein Backup des Datenverzeichnisses oder einen Snapshot. Der Reset selbst ist harmlos, aber ein Dienst, der nach einem Tippfehler in der Unit nicht mehr startet, ist es um drei Uhr morgens nicht mehr.