MySQL-fout "Access denied for user" oplossen

"Access denied for user" is de meest gezochte foutmelding rond MySQL, en in de meeste gevallen ligt het helemaal niet aan het wachtwoord. Op Debian en Ubuntu mislukt het inloggen vooral door de socket-authenticatie, door de verwarring tussen localhost en 127.0.0.1 of door een gebruikersregel die voor de verkeerde host is aangemaakt. Dit artikel loopt de oorzaken door in de volgorde waarin ze in de praktijk voorkomen, laat de wachtwoordreset via skip-grant-tables zien inclusief de weg terug, en beschrijft waaraan u ziet dat het inloggen echt weer werkt.

Alle gegevens hebben betrekking op Debian 13 (MariaDB 11.8), Debian 12 (MariaDB 10.11), Ubuntu 24.04 (MariaDB 10.11 of MySQL 8.0) en Ubuntu 22.04 (MariaDB 10.6 of MySQL 8.0). Nog één belangrijk punt vooraf: Debian levert helemaal geen pakket mysql-server. Heeft u op een Debian-systeem "MySQL" geïnstalleerd, dan draait daar MariaDB, en dat verklaart al een deel van de verwarring.

De foutmelding nauwkeurig lezen

De precieze formulering bepaalt welke oorzaak in aanmerking komt. Deze vijf varianten komt u in de praktijk tegen:

Twee details worden stelselmatig over het hoofd gezien. Ten eerste is de hostnaam in de melding de host waarvoor de server u aanzag, niet de host die u zelf heeft ingetypt. Staat er 'app'@'localhost' terwijl u verbinding heeft gemaakt met -h 127.0.0.1, dan heeft de server een reverse lookup uitgevoerd. Ten tweede maakt 1045 geen onderscheid tussen "wachtwoord fout" en "account bestaat niet". Beide leveren dezelfde uitvoer op, en dat is met opzet zo, zodat een aanvaller niet kan uitproberen welke gebruikersnamen geldig zijn.

Het meest voorkomende geval: unix_socket bij MariaDB

Sinds MariaDB 10.4 maken de pakketten van Debian en Ubuntu het account root@localhost zo aan dat het via de Unix-socket wordt geauthenticeerd. De accountregel ziet er in grote lijnen zo uit:

CREATE USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING 'invalid'
  OR unix_socket;

Dat betekent: wie als systeemgebruiker root is ingelogd, komt zonder wachtwoord binnen. Wie wel een wachtwoord meestuurt, wordt getoetst aan de hash van de tekenreeks "invalid", en die kan niemand raden. Het deel met mysql_native_password staat er alleen omdat SET PASSWORD anders met een fout zou afbreken. Het praktische gevolg: mysql -u root -p mislukt als gewone gebruiker, ongeacht welk wachtwoord u invoert. Dit is de juiste aanroep:

sudo mariadb

Onder MySQL 8.0 op Ubuntu heet de plug-in auth_socket in plaats van unix_socket, maar het gedrag is identiek. De aanroep luidt daar sudo mysql.

Controleer met SHOW CREATE USER welke plug-in een account werkelijk gebruikt:

mariadb -e "SHOW CREATE USER 'root'@'localhost';"

De uitvoer toont de volledige keten van beide methoden:

CREATE USER `root`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket

Hier ligt een valkuil die vrijwel geen enkele handleiding noemt: sinds MariaDB 10.4 is mysql.user nog maar een view, en staan de echte gegevens als JSON in mysql.global_priv. Die view kent per account slechts één authenticatiemethode en meldt voor root@localhost daarom mysql_native_password, terwijl in werkelijkheid unix_socket het werk doet. Wie de veelgebruikte query SELECT User, Host, plugin FROM mysql.user als bewijs neemt, gaat ervan uit dat de server met een wachtwoord authenticeert en zoekt de fout op de verkeerde plek. Dezelfde blinde vlek heeft JSON_VALUE(priv,"$.plugin"), want ook dat leest alleen het eerste element. De tweede methode staat in het veld auth_or en moet apart worden uitgelezen:

mariadb -e 'SELECT CONCAT(user,"@",host) AS account, JSON_VALUE(priv,"$.plugin") AS plugin, JSON_QUERY(priv,"$.auth_or") AS auth_or FROM mysql.global_priv;'

Voor root@localhost staat er in de kolom plugin dan nog steeds mysql_native_password, maar in auth_or verschijnt [{},{"plugin":"unix_socket"}]. Pas die tweede kolom laat zien dat het inloggen via de socket actief is.

Is de plug-in eigenlijk wel geladen? Na een mislukte upgrade kan hij ontbreken, en dan meldt de server ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded:

mariadb -e "SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%socket%';"

Wilt u root bewust op een wachtwoord omzetten, bijvoorbeeld omdat een back-upscript onder een andere systeemgebruiker draait, houd de socketvariant er dan daarnaast bij. Anders werken de onderhoudsscripts van de distributie en sudo mariadb niet meer:

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

Een eigen beheeraccount is sowieso beter dan een wachtwoord voor root. Voor applicaties geldt dat des te sterker: één database, één gebruiker, alleen de rechten die echt nodig zijn.

localhost is niet 127.0.0.1

Dit onderscheid veroorzaakt meer "Access denied"-meldingen dan welk verkeerd wachtwoord ook. De clients van MySQL en MariaDB behandelen de hostnaam localhost als speciaal geval en verbinden via de Unix-socket. Pas 127.0.0.1 dwingt een TCP-verbinding af. Voor de rechtenadministratie zijn dat geen identieke hostnamen, want bij een socketverbinding noteert de server de host localhost, en bij TCP via het loopbackadres ofwel localhost (na een reverse lookup) ofwel 127.0.0.1, afhankelijk van de instelling skip_name_resolve.

Een account dat alleen als 'app'@'127.0.0.1' bestaat, is via de socket niet bereikbaar, en andersom net zomin. Precies dat gebeurt wanneer een PHP-applicatie host=localhost in de configuratie heeft staan: PHP verbindt via de socket, terwijl de rechten voor het IP-adres zijn uitgedeeld. Twee tegenproeven:

mariadb -u app -p'Wachtwoord' -e "SELECT USER(), CURRENT_USER();"
mariadb -h 127.0.0.1 -u app -p'Wachtwoord' -e "SELECT USER(), CURRENT_USER();"

Mislukt er maar één van de twee, dan heeft u de oorzaak te pakken. Let daarbij op de naamresolutie: zolang skip_name_resolve uitstaat, en dat is bij de pakketinstallaties van Debian en Ubuntu het geval, zet de server het loopbackadres via een reverse lookup om naar localhost. Bestaat er al een account 'app'@'localhost', dan lukt het inloggen daarom ook met -h 127.0.0.1, en meldt CURRENT_USER() vervolgens app@localhost in plaats van app@127.0.0.1. Een extra aangemaakt account 'app'@'127.0.0.1' blijft in dat geval zonder effect, het treedt pas in werking als het localhost-account ontbreekt. De nette oplossing is om het account aan te maken voor de route die de applicatie werkelijk neemt, en niet beide varianten "voor alle zekerheid" in te richten.

Controleer daarnaast of de naamresolutie is uitgeschakeld. Staat skip_name_resolve aan, dan werken accountregels met hostnamen zoals 'app'@'web01.intern' helemaal niet meer, en tellen alleen nog IP-adressen:

mariadb -e "SHOW VARIABLES LIKE 'skip_name_resolve';"

Nog een struikelblok is de volgorde waarin de server passende regels uitkiest. Hij sorteert van specifiek naar algemeen en pakt de eerste treffer, niet de beste. Bestaat er naast 'app'@'%' ook nog een anoniem account ''@'localhost', dan wint bij een lokale verbinding het anonieme account, en mislukt uw inlogpoging met een melding die toch uw gebruikersnaam noemt. Actuele pakketten maken geen anonieme accounts meer aan, maar op systemen die jarenlang zijn meegemigreerd komt u ze nog tegen:

mariadb -e "SELECT user, host FROM mysql.global_priv WHERE user = '';"

Wachtwoord, rechten en hoofdlettergebruik

Blijven over: de oorzaken die werkelijk met de inloggegevens te maken hebben.

De shell vreet speciale tekens op

Tussen -p en het wachtwoord mag geen spatie staan, anders leest de client het wachtwoord als databasenaam. Wachtwoorden met $, !, & of een spatie horen tussen enkele aanhalingstekens, omdat de shell ze anders vervangt of afkapt. Echt netjes is het om het wachtwoord helemaal niet op de opdrachtregel mee te geven, want daar belandt het in de proceslijst en in het geschiedenisbestand. Maak in plaats daarvan een bestand ~/.my.cnf aan met rechten 0600:

[client]
user=app
password=UwWachtwoord

Omgekeerd is een vergeten ~/.my.cnf ook een mogelijke foutoorzaak. Het bestand overschrijft stilzwijgend wat u op de opdrachtregel opgeeft, en dan krijgt u "Access denied" voor een gebruiker die u nooit heeft ingetypt.

Hoofdlettergebruik: gebruikersnaam wel, host niet

Gebruikersnamen moeten in MySQL en MariaDB teken voor teken kloppen, App en app zijn twee verschillende accounts. Hostnamen worden bij de vergelijking zonder onderscheid tussen hoofd- en kleine letters getoetst, maar precies zo opgeslagen als ze in het CREATE USER stonden. Wie per ongeluk 'app'@'LOCALHOST' heeft aangemaakt, ziet in de uitvoer van SHOW GRANTS en in scripts twee schijnbaar verschillende accounts, die allebei op dezelfde verbinding passen. Zulke duplicaten maken het zoeken onnodig taai, omdat u rechten op de ene regel uitdeelt terwijl de server de andere kiest. Zo spoort u ze op:

mariadb -e "SELECT user, host FROM mysql.global_priv WHERE host <> LOWER(host);"

Niet het inloggen ontbreekt, maar de rechten

Komt er ERROR 1044 in plaats van 1045, dan is het inloggen gelukt. Er ontbreken dan rechten op een bepaalde database. Kijk na wat het account werkelijk mag:

mariadb -e "SHOW GRANTS FOR 'app'@'localhost';"

FLUSH PRIVILEGES heeft u alleen nodig als u de rechtentabellen rechtstreeks met INSERT of UPDATE heeft aangepast. Na GRANT, CREATE USER of ALTER USER is het overbodig, en het verhult af en toe dat het eigenlijke commando helemaal geen effect heeft gehad.

De client begrijpt de plug-in niet

MySQL 8.0 gebruikt standaard caching_sha2_password. Oudere clients en bibliotheken antwoorden daarop met ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded. Dat is geen rechtenprobleem, maar een incompatibiliteit. In MySQL 8.0 is mysql_native_password nog als uitwijkmogelijkheid beschikbaar, in MySQL 8.4 is het verwijderd. Werk bij twijfel liever de client bij dan dat u de versleuteling terugdraait.

Rootwachtwoord resetten

Helpt niets meer, dan moet de server één keer zonder rechtencontrole starten. Er zijn twee wegen naar het doel. De route via --init-file is de veiligste, omdat de server daarbij onafgebroken met actieve rechtencontrole draait.

Variant 1: init-file (aanbevolen)

Het SQL-bestand moet op een plek staan die de dienst mag lezen. Onder /tmp of /root loopt dat op Ubuntu geregeld stuk op AppArmor en op PrivateTmp in de systemd-unit. Zet het bestand daarom in de datamap:

sudo systemctl stop mariadb
sudo tee /var/lib/mysql/kh-reset.sql >/dev/null <<'SQL'
ALTER USER 'root'@'localhost' IDENTIFIED VIA unix_socket
  OR mysql_native_password USING PASSWORD('NieuwRootWachtwoord');
SQL
sudo chown mysql:mysql /var/lib/mysql/kh-reset.sql
sudo systemctl set-environment MYSQLD_OPTS="--init-file=/var/lib/mysql/kh-reset.sql"
sudo systemctl start mariadb

Ruim daarna beslist alles weer op, anders draait de server bij elke start opnieuw met dat bestand:

sudo systemctl unset-environment MYSQLD_OPTS
sudo rm /var/lib/mysql/kh-reset.sql
sudo systemctl restart mariadb

Voor MySQL 8.0 op Ubuntu heet de dienst mysql en luidt de SQL-regel:

ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'NieuwRootWachtwoord';

Variant 2: skip-grant-tables

Deze variant schakelt de rechtencontrole volledig uit. Zonder --skip-networking zou in die tijd iedereen die de poort bereikt volledige toegang tot alle gegevens hebben. Die optie is dus geen keuze, maar verplicht.

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

Laad in die sessie eerst de rechtentabellen, anders weigert de server ALTER USER met een foutmelding:

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

En daarna weer terug naar de normale werking:

sudo systemctl unset-environment MYSQLD_OPTS
sudo systemctl restart mariadb

Verwerkt uw distributie de variabele MYSQLD_OPTS niet, dan werkt altijd het drop-in-bestand /etc/systemd/system/mariadb.service.d/reset.conf met de inhoud [Service] en Environment="MYSQLD_OPTS=--skip-grant-tables --skip-networking", gevolgd door sudo systemctl daemon-reload. Verwijder het bestand daarna weer en laad systemd opnieuw.

Als de reset misgaat

Precies hier houden de meeste handleidingen op. De vier meest voorkomende vervolgproblemen:

De dienst start niet meer. Meestal een typefout in het SQL-bestand. De server breekt dan bij het starten af. Debian logt MariaDB standaard naar het journal, Ubuntu met MySQL daarnaast ook naar een bestand:

sudo journalctl -u mariadb -n 50 --no-pager
sudo tail -n 50 /var/log/mysql/error.log

Waar de server naartoe schrijft, ziet u met SHOW VARIABLES LIKE 'log_error';. Verwacht daar echter geen bestandspad: bij de pakketinstallaties van Debian en Ubuntu is de waarde leeg, omdat de dienst met --skip-log-error draait. Alles gaat dan naar de standaardfoutuitvoer en belandt in het journal of in /var/log/syslog, op te vragen met journalctl -u mariadb. Voor het herstel verwijdert u de omgevingsvariabele met --init-file en start u opnieuw.

De server draait blijvend zonder rechtencontrole. Dat gebeurt wanneer het unset-environment is vergeten, en het is de gevaarlijkste variant, omdat naar buiten toe alles normaal oogt. Twee controles:

systemctl show-environment
ps -o args= -C mariadbd

Duikt skip-grant-tables in de uitvoer van een van beide commando's op, dan staat de rechtencontrole nog uit. systemctl show-environment veronderstelt daarbij dat systemd als PID 1 draait. Op een gewone server is dat zo, maar in een container of op een systeem met SysV-init bestaat het commando niet. Daar leest u de omgeving rechtstreeks uit het draaiende proces:

cat /proc/$(pgrep -n mariadbd)/environ | tr '\0' '\n'

Op de argumentenlijst alleen kunt u evenmin vertrouwen: bij een start via systemd toont ps vaak alleen /usr/sbin/mariadbd zonder ook maar één optie, terwijl bij een start via een SysV-initscript de volledige lijst verschijnt. Nog een aanwijzing: onder skip-grant-tables antwoordt SHOW GRANTS met een foutmelding in plaats van met rechten.

AppArmor blokkeert het init-bestand. Het symptoom is een server die zonder aanwijsbare reden niet opkomt. Een blik in het kernellogboek geeft uitsluitsel:

sudo dmesg | grep -i denied

U sluit uzelf volledig buiten. Dat gebeurt wanneer iemand root met ALTER USER ... IDENTIFIED BY op alleen een wachtwoord omzet, daarbij de socket-authenticatie kwijtraakt en het nieuwe wachtwoord daarna niet meer weet. De uitweg is dezelfde reset nog een keer, dit keer met de hierboven getoonde dubbele variant unix_socket OR mysql_native_password. Maak voor elke ingreep een kopie van de rechtentabellen, dat kost seconden en scheelt in het ergste geval uren:

sudo mariadb-dump mysql > /root/mysql-grants.sql

De verder gebruikelijke optie --single-transaction kunt u hier achterwege laten. Ze loopt weliswaar zonder fout door, maar heeft geen effect, omdat de tabellen van de database mysql op Aria of MyISAM staan en dus niet transactioneel zijn.

Bij managed webhosting heeft u geen systeemtoegang en daarmee geen van deze mogelijkheden. Daar reset u databasegebruikers en wachtwoorden via de beheerinterface. Op een KVM-rootserver of dedicated server bij KernelHost heeft u volledige roottoegang, en is de server via de netwerkverbinding niet meer bereikbaar, dan komt u via de console in het klantenpaneel alsnog bij het systeem.

Controleren of het echt is verholpen

Dat een commando zonder fout doorloopt, betekent nog niet dat het inloggen blijvend werkt. Deze vier controles leggen de typische restfouten bloot.

Ten eerste, het verschil tussen USER() en CURRENT_USER(). De eerste functie laat zien als wie u zich heeft voorgesteld, de tweede welke accountregel de server werkelijk gebruikt:

mariadb -u app -p'Wachtwoord' -e "SELECT USER(), CURRENT_USER();"

Staan daar twee verschillende waarden, bijvoorbeeld app@localhost en app@%, dan lopen uw rechten via een andere regel dan u dacht. Dat verklaart later opduikende 1044-fouten voordat ze in productie opvallen.

Ten tweede, een echte toegang tot de doeldatabase in plaats van alleen een inlogpoging, plus de controle van de exitcode:

mariadb -u app -p'Wachtwoord' mijn_db -e "SELECT 1;" ; echo "Exitcode: $?"

Ten derde, een herstart van de dienst en daarna dezelfde inlogpoging opnieuw. Zo weet u zeker dat de wijziging echt in de tabellen staat en niet alleen in het werkgeheugen, en dat er geen omgevingsvariabele uit de reset is blijven hangen:

sudo systemctl restart mariadb
sudo systemctl is-active mariadb

Ten vierde, de applicatie zelf. Een geslaagde test op de opdrachtregel zegt weinig over een PHP-applicatie die onder de gebruiker van de webserver en via de socket verbindt. Test daarom onder dezelfde systeemgebruiker:

sudo -u www-data mariadb -u app -p'Wachtwoord' mijn_db -e "SELECT CURRENT_USER();"

Verschillen tussen de distributies

Een handleiding die voor alle vier de systemen hetzelfde beweert, klopt op minstens één punt niet. Deze tabel vat de relevante afwijkingen samen:

Nog meer verschillen die in de praktijk tijd kosten: de configuratiebestanden staan bij MariaDB onder /etc/mysql/mariadb.conf.d/50-server.cnf en bij MySQL onder /etc/mysql/mysql.conf.d/mysqld.cnf. De dienstnamen luiden mariadb respectievelijk mysql, waarbij MariaDB daarnaast een alias mysql meelevert. Bij MariaDB bestaat sinds versie 10.4 geen gebruiker debian-sys-maint meer, het bestand /etc/mysql/debian.cnf verwijst daar via de socket naar root. Bij MySQL op Ubuntu bestaat die onderhoudsgebruiker nog wel, en dat is de beste noodingang wanneer het rootwachtwoord verloren is en u de server niet opnieuw wilt starten:

sudo mysql --defaults-file=/etc/mysql/debian.cnf

Houdt u deze volgorde aan, dus eerst de melding nauwkeurig lezen, dan de plug-in en de hostregel controleren, dan de verbindingsroute, en pas helemaal op het laatst het wachtwoord resetten, dan zijn verreweg de meeste gevallen binnen een paar minuten en zonder downtime opgelost. De reset via skip-grant-tables is het laatste redmiddel, niet de eerste stap.