MySQL- en MariaDB-rootwachtwoord resetten

Het rootwachtwoord van de database is zo'n wachtwoord dat u één keer bij de installatie instelt en daarna nooit meer nodig heeft, omdat alle applicaties met eigen accounts werken. Tot de dag waarop u er toch bij moet. Dan staat er dit:

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

Het standaardantwoord op internet luidt: service stoppen, met --skip-grant-tables starten, wachtwoord instellen, klaar. Dat klopt, maar het is maar de halve waarheid. In deze handleiding leest u ook waarom het overal gekopieerde commando op Ubuntu met MySQL 8 geen enkel effect heeft, waarom u in veel gevallen helemaal geen wachtwoord nodig heeft, en wat u doet wanneer de service daarna helemaal niet meer start.

Eerst controleren: waarschijnlijk heeft u helemaal geen wachtwoord nodig

Op Debian en Ubuntu wordt de database-root al jaren niet meer met een wachtwoord beveiligd, maar via de identiteit van de systeemgebruiker. MariaDB noemt die methode unix_socket, bij MySQL heet ze auth_socket. Bedoeld wordt hetzelfde: wie via de lokale socket verbindt en op besturingssysteemniveau al root is, komt zonder wachtwoord binnen. De redenering daarachter is simpel, want een systeemgebruiker root komt sowieso bij alle databestanden en bij het werkgeheugen van het proces, een extra wachtwoord vormt dus geen drempel.

De eerste poging zou daarom altijd deze moeten zijn:

sudo mariadb
sudo mysql

Let op: sudo mysql -u root -p werkt niet, omdat de -p overschakelt naar wachtwoordauthenticatie. Precies daarop lopen de meesten vast. Zonder -p en met sudo belandt u meestal direct in de prompt. Van daaruit stelt u het wachtwoord in twee seconden opnieuw in, zonder de database ook maar aan te raken.

De tweede vluchtroute is het onderhoudsaccount van de distributie. Op Ubuntu met het pakket mysql-server bestaat nog steeds het bestand /etc/mysql/debian.cnf, dat inloggegevens bevat voor een account met volledige rechten, alleen leesbaar voor root:

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

Komt er een regel terug, dan bent u binnen en kunt u meteen verder werken. Verwacht daarbij niet root@localhost: de query antwoordt met debian-sys-maint@localhost. Dat hoort zo, want dit onderhoudsaccount heeft ALL PRIVILEGES en volstaat ruimschoots voor de reset, maar u bent er geen root mee. Deze route is bovendien puur Debian- en Ubuntu-specifiek. Op AlmaLinux, Rocky Linux en Oracle Linux bestaan noch de map /etc/mysql/ noch het account, daar geldt in plaats daarvan de socketlogin als root uit de vorige paragraaf. Bij MariaDB vanaf 10.4 wordt dit account niet meer aangemaakt (het bestand verwijst daar meestal gewoon naar root via de socket), bij bestaande installaties is het echter vaak nog aanwezig. Even kijken kost niets en bespaart u bij succes de complete rest van deze handleiding.

Welke database draait hier eigenlijk?

Dat is geen formaliteit, want het bepaalt elk volgend commando. Op Debian zit er al jaren geen pakket mysql-server meer in het officiële archief, daar draait praktisch altijd MariaDB, ook al bestaat het commando mysql. Dat is namelijk alleen een symlink naar de MariaDB-client. Op dit moment vindt u in de distributies:

Vraag het de server zelf, niet de client:

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

De --all hoort erbij, omdat list-units anders alleen geladen, actieve units toont. Juist in het geval waarin u het commando nodig heeft, namelijk bij een service die niet draait, zou de uitvoer dan leeg blijven. mysqladmin --version bestaat aan beide kanten en noemt de engine met zoveel woorden, MariaDB-systemen antwoorden met ... Distrib 11.8.6-MariaDB .... Bij mariadbd --version is command not found op een puur MySQL-systeem het verwachte resultaat en geen fout, spiegelbeeldig geldt hetzelfde voor mysqld-specifieke commando's op een puur MariaDB-systeem.

Heet de unit mariadb.service, dan werkt u met MariaDB. Heet hij mysql.service, dan met MySQL. Op systemen met MariaDB bestaat daarnaast een alias mysql.service die naar mariadb.service wijst, daarom zegt de uitvoer van systemctl list-units meer dan het enkele bestaan van een naam.

De unitnamen zelf verschillen per distributiefamilie, en alle systemctl-aanroepen in deze handleiding zijn voor Debian en Ubuntu geschreven. Op de Red Hat-familie bestaat er helemaal geen unit met de naam mysql.service, daar antwoordt systemctl status mysql met Unit mysql.service could not be found. Gebruik in dat geval overal de namen uit de rechterkolom, ook in het pad van de drop-in-map:

Vooraf afschermen: waarom deze stap niet optioneel is

Met --skip-grant-tables leest de server de rechtentabellen niet in. Dat betekent niet "root mag zonder wachtwoord binnen", maar "iedereen mag alles, zonder wachtwoord, als willekeurige gebruiker". In deze toestand is er geen authenticatie en geen rechtencontrole, ook niet voor uw klantendatabases.

MySQL 8 schakelt in dit geval automatisch skip_networking mee in en accepteert dus geen TCP-verbindingen meer. Vertrouw daar toch niet op, maar zet de optie er altijd zelf bij. Bij MariaDB is dat sowieso de gedocumenteerde aanbeveling, en wie beide systemen beheert, wil niet hoeven onthouden welk van de twee meedenkt.

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

Twee punten die daarbij graag over het hoofd worden gezien. Ten eerste: skip_networking sluit alleen de netwerkpoort. De Unix-socket onder /run/mysqld/mysqld.sock blijft open, en die is op veel systemen voor alle lokale gebruikers bereikbaar. Een gecompromitteerd PHP-proces onder www-data kan in dat tijdvenster elke database op de server uitlezen. Houd het venster daarom zo kort mogelijk en voer de actie niet uit terwijl er een webserver met onbekende code draait. Ten tweede: stop vooraf alles wat automatisch verbinding maakt, dus webservers en applicatiediensten. Hun verbindingspogingen storen niet alleen, ze draaien in deze toestand met volledige rechten.

Is de server van buitenaf bereikbaar, trek dan ook de firewall dicht. Hoe u dat blijvend netjes opzet, leest u in UFW-firewall instellen.

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

De eerste regel is geen overbodige luxe: op een minimale Debian-installatie is ufw niet voorgeïnstalleerd, het commando eindigt anders met sudo: ufw: command not found. Op AlmaLinux, Rocky Linux en RHEL bestaat ufw helemaal niet, daar loopt de pakketfiltering via firewalld:

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

Op alle geteste Debian- en Ubuntu-installaties staat bind-address toch al op 127.0.0.1, bevestigd met ss -ltnp. Dan accepteert de server van buitenaf sowieso geen verbinding, en is de firewallregel het tweede vangnet, niet de eigenlijke bescherming.

MariaDB: het wachtwoord opnieuw instellen

De unit van MariaDB start de server met ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS. Die variabele is precies voor zulke gevallen bedoeld, u hoeft dus geen bestand te bewerken. Controleer het even, dan weet u dat de volgende route op uw systeem werkt:

systemctl cat mariadb | grep ExecStart

Daarna in deze volgorde:

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

In de prompt komt eerst FLUSH PRIVILEGES. Zonder die stap heeft de server de rechtentabellen nog helemaal niet in het geheugen en wijst hij elk accountbeheer af. Daarna stelt u het wachtwoord in:

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

Deze wat omslachtige schrijfwijze is met opzet gekozen en het belangrijkste MariaDB-specifieke punt van de hele handleiding. MariaDB kan sinds 10.4 meerdere authenticatiemethoden per account voeren, en precies zo staat root na een pakketinstallatie ingesteld: eerst de socket, bij wijze van reserve een wachtwoord. Gebruikt u in plaats daarvan het simpele ALTER USER 'root'@'localhost' IDENTIFIED BY '...', dan vervangt u de hele keten door pure wachtwoordauthenticatie. Dat werkt, maar daarna lukt sudo mariadb zonder wachtwoord niet meer, en interne onderhoudsscripts van de distributie die op de socket vertrouwen, werken niet meer. U heeft het probleem dan alleen een jaar vooruitgeschoven.

Tot slot ruimt u de uitzonderingstoestand weer op:

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

Vergeet unset-environment niet. De variabele hangt aan de systemd-manager, niet aan de service, en overleeft elke herstart van de service. Start 's nachts een pakketupdate MariaDB opnieuw, dan draait uw database vanaf dat moment verder zonder enige rechtencontrole, en niemand die het merkt. Pas een reboot van de server ruimt de variabele vanzelf op.

MySQL 8: het commando uit de meeste handleidingen doet hier niets

Voor MySQL circuleert hetzelfde recept met systemctl set-environment MYSQLD_OPTS=.... Het komt uit de documentatie van Oracle en past bij hun eigen pakketten. De unit uit het Ubuntu-archief ziet er echter anders uit, daar staat simpelweg ExecStart=/usr/sbin/mysqld, zonder variabele. Het commando loopt door, meldt geen fout, en de server start toch gewoon met actieve rechtencontrole. U zit dan tegen een Access denied aan te kijken en begrijpt er niets van. Controleer het zelf:

systemctl cat mysql | grep ExecStart

Duikt daar geen $MYSQLD_OPTS op, dan heeft u een drop-in nodig. En als u er toch een aanmaakt, kies dan meteen de betere route: --init-file. Daarmee start de server helemaal normaal met rechtencontrole en voert hij bij het opstarten een SQL-bestand met volledige rechten uit. Er is geen open tijdvenster waarin iemand zonder wachtwoord binnenkomt. Oracle beveelt deze variant uitdrukkelijk aan boven --skip-grant-tables.

sudo systemctl stop mysql
printf "ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'UwNieuweWachtwoord';\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

Het IDENTIFIED WITH caching_sha2_password is het beslissende deel en de reden waarom talloze handleidingen op dit punt stuklopen zonder ook maar een fout te tonen. Op Debian en Ubuntu gebruikt root@localhost ook bij MySQL de plug-in auth_socket. Een simpel IDENTIFIED BY 'wachtwoord' zet wel de wachtwoord-hash, maar wisselt de plug-in niet. In mysql.user staat daarna nog steeds auth_socket, de service start netjes op, er verschijnt geen enkele foutmelding, en toch eindigt elke wachtwoordlogin met ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Bijzonder verraderlijk: wie de tegenproef als systeemgebruiker root doet, wordt door auth_socket zonder wachtwoord doorgelaten en denkt dat de reset gelukt is. Test daarom vanuit een ander account of via TCP. Alleen bij zeer oude clients die caching_sha2_password niet beheersen, gebruikt u in plaats daarvan mysql_native_password, met de beperkingen uit de alinea verderop.

De map /var/lib/mysql-files is bewust gekozen: hij is eigendom van de databasegebruiker en is in het AppArmor-profiel van mysqld vrijgegeven. Zet u het bestand in /root of /tmp, dan strandt de start mogelijk op AppArmor, en de melding in het logboek helpt u weinig verder. Nu de drop-in:

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

De lege eerste ExecStart-regel is verplicht, anders plakt systemd uw commando achter het bestaande en weigert het de service met een configuratiefout. Opslaan onder /etc/systemd/system/mysql.service.d/override.conf, daarna:

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

Lukt de login, ruim dan beide weer op, het SQL-bestand en de 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

Wilt u toch de klassieke route, vervang dan in de drop-in de regel door ExecStart=/usr/sbin/mysqld --skip-grant-tables --skip-networking, verbind met sudo mysql en voer daar eerst FLUSH PRIVILEGES; uit en dan ALTER USER. Nog een opmerking over de versleuteling: MySQL 8 gebruikt standaard caching_sha2_password. Meldt een zeer oude applicatie zich daarna met "The server requested authentication method unknown to the client", dan helpt IDENTIFIED WITH mysql_native_password BY '...'. Dat is echter een doodlopende weg, want deze methode geldt sinds 8.0.34 als verouderd en is in MySQL 8.4 helemaal verdwenen. Beter is het om de client bij te werken.

De foutmeldingen woordelijk

ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement. U bent FLUSH PRIVILEGES; vergeten. Voer dat alsnog uit, daarna werkt ALTER USER.

ERROR 1288 (HY000): The target table user of the UPDATE is not updatable. U volgt een oude handleiding die UPDATE mysql.user SET password=... voorstelt. Vanaf MariaDB 10.4 staan de rechten in mysql.global_priv, en mysql.user is daar alleen nog een view op. Gebruik ALTER USER of SET PASSWORD. Terzijde: rechtstreeks in de rechtentabellen schrijven was ook vroeger al een prima manier om het account definitief te slopen.

ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Geen verkeerd wachtwoord, maar juist het tegenovergestelde: het account verwacht socketauthenticatie, en u bent niet als systeemgebruiker root onderweg of heeft -p meegegeven. Probeer het opnieuw met sudo en zonder -p.

ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded. Het account verwijst naar een plug-in die de draaiende server niet kent, typisch na een overstap van MariaDB naar MySQL of na het kopiëren van een datamap. Zet het account via de route hierboven om naar een passende methode.

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2). De server draait niet. Bekijk eerst systemctl status en het logboek, en blijf niet aan de client sleutelen.

mysqld: Can't create directory '/run/mysqld/' (Errcode: 13 - Permission denied) of een start die meteen weer afbreekt. Dat gebeurt wanneer de server met de hand in plaats van via systemd is gestart, want dan ontbreekt de runtimemap. Reparatie:

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

Job for mysql.service failed because the control process exited with error code. Deze melding zegt op zichzelf niets. De werkelijke oorzaak staat in het journal en in het foutlogboek:

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

Het patroon met beide unitnamen is bewust gekozen, want de voor de hand liggende losse opvraging is een stille valkuil. Op Debian met MariaDB is mysql.service alleen een alias op mariadb.service. systemctl lost de alias op, maar het journal indexeert de regels onder de echte unitnaam, en journalctl -u mysql antwoordt daarom met -- No entries -- en exitcode 0, hoewel het journal vol staat. Andersom levert journalctl -u mariadb op een Ubuntu-systeem met MySQL eveneens -- No entries -- op.

Met het foutbestand is het net zo. De overal geciteerde /var/log/mysql/error.log bestaat alleen op Ubuntu met MySQL. Op Debian met MariaDB bestaat de map /var/log/mysql/ helemaal niet, omdat log_error in 50-server.cnf is uitgecommentarieerd en MariaDB naar het journal schrijft. De passende regel per systeem:

Wilt u het pad niet raden, vraag het dan de server zelf: sudo mariadb -e "SHOW VARIABLES LIKE 'log_error';" respectievelijk hetzelfde met mysql.

De drie meest voorkomende oorzaken op dit punt: een typefout in de drop-in (dan noemt systemd de regel), een volle schijf (daarover Schijf vol onder Linux) of een tweede serverproces dat nog draait en de databestanden vergrendeld houdt. Dat laatste controleert u met pgrep -a mariadbd respectievelijk pgrep -a mysqld voordat u opnieuw start.

Komt u na de reset wel binnen, maar worden uw applicaties nog steeds geweigerd, dan ligt het probleem ergens anders: applicaties zoals WordPress of Nextcloud gebruiken eigen databasegebruikers, niet root. Details daarover in MySQL Access denied for user oplossen.

Waaraan u ziet dat het echt gelukt is

Een geslaagde login alleen is nog geen bewijs, want die lukt in de noodtoestand ook zonder enig wachtwoord. Controleer daarom vier dingen zodra de service weer normaal draait.

Ten eerste: er is geen speciale configuratie meer actief. De eerste uitvoer moet leeg zijn, de tweede mag geen extra opties meer tonen.

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

Ten tweede: de rechtencontrole is weer actief. Een login met een bewust verkeerd wachtwoord moet mislukken. Lukt hij toch, dan draait de server nog altijd open.

Ten derde: het nieuwe wachtwoord en de verwachte methode staan in het account. In MariaDB vraagt u dat zo op, bij MySQL zonder de JSON-kolom:

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';"

Ten vierde: de netwerkpoort gedraagt zich weer als voorheen. Een databaseserver die alleen lokaal wordt gebruikt, hoort na het opruimen weer uitsluitend op 127.0.0.1 te luisteren:

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

De -s en de drie paden zijn geen toeval. grep -r bind-address /etc/mysql/ alleen breekt op de Red Hat-familie af met No such file or directory, omdat daar geen /etc/mysql/ bestaat. Met -s gaat grep stilzwijgend voorbij aan de ontbrekende paden, en werkt de regel in beide werelden.

Opruimen, zodat het geen tweede keer gebeurt

Het wachtwoord staat nu mogelijk op plekken waar u niet aan denkt. Een commando met -e "ALTER USER ... IDENTIFIED BY '...'" belandt in ~/.bash_history, een commando uit de prompt in het historiebestand van de databaseclient. Beide horen te worden opgeschoond:

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

Beide bestandsnamen zijn nodig, omdat de client van naam is veranderd. Tot en met MariaDB 10.11, dus tot en met Debian 12, schrijft hij naar ~/.mysql_history. Vanaf MariaDB 11, dus vanaf Debian 13, schrijft hij naar ~/.mariadb_history. Wie daar alleen het oude bestand verwijdert, laat het in leesbare tekst ingetikte wachtwoord ongemerkt op de schijf staan. Nog beter is het om de historie helemaal niet te laten ontstaan: export MYSQL_HISTFILE=/dev/null respectievelijk export MARIADB_HISTFILE=/dev/null vóór de sessie, of meteen de route via --init-file uit de MySQL-paragraaf, waarbij het wachtwoord nooit door een interactieve sessie gaat.

Zinvoller dan een wachtwoord dat u over een jaar weer vergeet, is een opzet die in het dagelijks gebruik zonder wachtwoord werkt. Op Debian en Ubuntu betekent dat: root blijft bij unix_socket respectievelijk auth_socket, en voor al het andere maakt u gewone gebruikers aan met precies de rechten die de betreffende applicatie nodig heeft. Wie de toegang vanaf een andere machine nodig heeft, tunnelt die via SSH in plaats van poort 3306 open te zetten, zie Via SSH met de server verbinden.

Bent u toch al met de database bezig, neem dan de rest meteen mee: anonieme gebruikers verwijderen, de testdatabase wissen, de toegang op afstand voor root uitschakelen. Dat regelt mariadb-secure-installation respectievelijk mysql_secure_installation in een paar minuten, uitvoerig beschreven in MariaDB en MySQL beveiligen. En omdat het wachtwoord zelden het enige is dat op een net overgenomen server rammelt, loont een rondje langs de checklist voor nieuwe rootservers.

Nog een laatste gedachte over de volgorde: voordat u een draaiende productieserver in de rechtenvrije toestand zet, maakt u een back-up van de datamap of een snapshot. De reset zelf is onschuldig, maar een service die na een typefout in de unit niet meer start, is dat om drie uur 's nachts allang niet meer.