MySQL-fout "Can't connect through socket" oplossen

De melding duikt altijd op het slechtst denkbare moment op: na een herstart, na een update of wanneer de schijf 's nachts is volgelopen. De formulering is bijna altijd dezelfde:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Er staan twee gegevens in die veel mensen over het hoofd zien: het pad en het getal tussen haakjes. Samen vertellen ze vrij nauwkeurig waar u moet zoeken. Dit artikel loopt de vijf realistische oorzaken door (dienst draait niet, verkeerd socketpad in de configuratie, applicatie verwacht een ander pad dan de server gebruikt, rechtenprobleem, schijf vol), toont de diagnose in de volgorde die het snelst tot resultaat leidt, en legt het verschil uit tussen localhost en 127.0.0.1, dat in zijn eentje ongeveer de helft van alle gevallen oplost.

De foutmelding nauwkeurig lezen

De client heeft geprobeerd te verbinden via een Unix-domain-socket, dus via een bestand in het bestandssysteem en niet via het netwerk. Het pad tussen aanhalingstekens is het pad dat de client verwacht. Of de server hetzelfde pad gebruikt, zegt de melding niet. En daar zit vaak precies het probleem.

Het getal aan het eind is de foutcode van het besturingssysteem:

Afhankelijk van client en versie varieert de formulering. Deze varianten betekenen allemaal hetzelfde:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2)
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Vanuit PHP ziet dezelfde fout er zo uit, omdat PHP alleen de kale errno doorgeeft:

PDOException: SQLSTATE[HY000] [2002] No such file or directory
Warning: mysqli_connect(): (HY000/2002): No such file or directory

Belangrijk voor de afbakening: ERROR 2003 is iets anders. Daar staat een IP-adres en een poort in plaats van een pad, dat is de TCP-route. En ERROR 1045 (28000): Access denied for user betekent dat de verbinding er wel was en alleen het inloggen mislukte. Daarover hebben wij een apart artikel: MySQL "Access denied for user" oplossen.

localhost of 127.0.0.1: het verschil dat de helft van de gevallen verklaart

MySQL en MariaDB behandelen localhost als een speciaal geval. Staat er letterlijk localhost, dan negeert de clientbibliotheek de hostnaam volledig en verbindt hij via de Unix-socket. Staat er 127.0.0.1, dan loopt de verbinding via TCP naar poort 3306. Dat is geen detail, maar de kern van het probleem: een applicatie met localhost in de configuratie bereikt de server via een bestand waarvan zij het pad ergens anders vandaan haalt dan de server.

De snelste test of er wel een server draait, is daarom deze:

mysql --protocol=TCP -h 127.0.0.1 -P 3306 -u root -p

Krijgt u hier een wachtwoordprompt of een access denied, dan draait de dienst en heeft u zuiver een socketprobleem. Komt er ERROR 2003 ... (111), dan draait de dienst niet of luistert hij niet op TCP.

Als permanente oplossing is overschakelen naar 127.0.0.1 echter tweede keus. De socket is sneller, hij omzeilt de netwerkstack en hij is van buitenaf in principe niet bereikbaar. Belangrijker nog: in de gebruikerstabel geldt 'app'@'localhost' niet automatisch ook voor 'app'@'127.0.0.1'. Wie de host in de applicatie omzet en daarna een access denied krijgt, is precies tegen dit effect aangelopen. En zet u wel om naar TCP, controleer dan dat bind-address niet per ongeluk op 0.0.0.0 staat en de database ineens aan het internet hangt. Daarbij passen MariaDB en MySQL beveiligen en UFW-firewall instellen.

Diagnose in vijf minuten

Stap 1: draait de dienst eigenlijk wel?

systemctl status mariadb
systemctl status mysql

Op Debian en Ubuntu heet de unit bij MariaDB mariadb.service (met mysql.service als alias), bij MySQL mysql.service. Op AlmaLinux, Rocky Linux en RHEL heet hij mariadb.service respectievelijk mysqld.service. Interessant is de regel Active:. Staat daar active (running), ga dan meteen door naar stap 2. Staat er failed (Result: exit-code) of inactive (dead), dan is de oorzaak in het foutlogboek te vinden.

Stap 2: welk socketpad gebruikt de server werkelijk?

Dat is zonder draaiende server uit de configuratiebestanden af te lezen. my_print_defaults verwerkt dezelfde keten aan bestanden als de server zelf, inclusief alle includes. Geef daarbij alle mogelijke groepen in één keer op, dan werkt het commando op elke distributie:

my_print_defaults client client-server mysqld mariadbd | grep -i socket

De vier groepsnamen zijn geen overdreven ijver, maar het antwoord op drie valkuilen die elk afzonderlijk een lege uitvoer opleveren. my_print_defaults client levert op alle geteste distributies helemaal niets op, omdat in 50-client.cnf respectievelijk /etc/my.cnf.d/client.cnf alle opties zijn uitgecommentarieerd. De socket staat op Debian en Ubuntu in plaats daarvan in de groep [client-server] van /etc/mysql/mariadb.cnf en verschijnt daar als --socket=/run/mysqld/mysqld.sock. Bij de Red Hat-familie bestaat die groep niet, daar levert mysqld de waarde --socket=/var/lib/mysql/mysql.sock. En vanaf MariaDB 11.8, dus vanaf Debian 13, heet de servergroep in 50-server.cnf niet meer [mysqld] maar [mariadbd]. Wie daar alleen my_print_defaults mysqld aanroept, ziet een lege uitvoer en houdt zijn configuratie ten onrechte voor leeg.

Als alternatief, wanneer de server draait en u erin komt:

mysql -e "SHOW VARIABLES LIKE 'socket'"

En helemaal zonder inloggen, rechtstreeks aan de kernel gevraagd welke Unix-sockets bezet zijn:

ss -lx | grep -i mysql

Meldt de shell ss: command not found, dan ontbreekt simpelweg het pakket. Op Debian en Ubuntu heet het iproute2, op AlmaLinux, Rocky Linux en Oracle Linux iproute:

apt-get install -y iproute2
dnf install -y iproute

Daarmee heeft u het pad dat de server daadwerkelijk aanbiedt. Vergelijk het teken voor teken met het pad uit de foutmelding. /run/mysqld/mysqld.sock en /var/run/mysqld/mysqld.sock zijn op moderne systemen hetzelfde, omdat /var/run een symlink naar /run is. /var/lib/mysql/mysql.sock en /tmp/mysql.sock zijn dat niet.

Stap 3: bestaat het bestand, en van wie is het?

ls -la /run/mysqld/
ls -la /var/lib/mysql/mysql.sock

Verwacht wordt een bestand van het type s (socket), eigenaar mysql:mysql, rechten srwxrwxrwx. De map erboven hoort drwxr-xr-x mysql mysql te zijn. Ontbreekt de map /run/mysqld volledig, dan is de server nooit succesvol gestart, want die map wordt bij het starten aangemaakt.

Stap 4: het foutlogboek lezen

Hier lopen de distributies duidelijk uiteen, en hier zit de meest voorkomende reden waarom handleidingen op internet niet verder helpen. Op Ubuntu met MySQL schrijft de server naar /var/log/mysql/error.log. Op Debian met MariaDB is log_error standaard uitgecommentarieerd, de map /var/log/mysql/ bestaat daar helemaal niet, en alles belandt in het journal. Neem daarom de regel die bij uw combinatie past:

Eén valkuil verdient daarbij bijzondere aandacht, omdat hij geen fout oplevert: op een Debian-systeem met MariaDB is mysql.service slechts een alias van mariadb.service. systemctl lost de alias op, maar het journal indexeert de vermeldingen onder de echte unitnaam. journalctl -u mysql antwoordt daar met -- No entries -- en exitcode 0, terwijl het journal vol staat. Wie alleen dat commando probeert, houdt het logboek voor leeg en zoekt op de verkeerde plek verder. Omgekeerd geldt hetzelfde: op een Ubuntu-systeem met MySQL levert journalctl -u mariadb eveneens -- No entries -- op. Weet u niet zeker welke unit bedoeld is, vraag ze dan allebei tegelijk op:

journalctl -u 'mysql*' -u 'mariadb*' --no-pager -n 50

Wilt u een permanent logboek, zet dan onder Debian en Ubuntu in /etc/mysql/mariadb.conf.d/50-server.cnf in de servergroep een log_error = /var/log/mysql/error.log, maak de map aan met install -d -o mysql -g mysql /var/log/mysql en herstart.

Oorzaak 1: de dienst draait niet (en waarom)

Een systemctl start mariadb is de reflex, maar als de dienst zojuist vanzelf is gestorven, loopt hij doorgaans meteen weer in dezelfde fout. Vooraf loont een blik op drie concrete patronen in het logboek.

Schijf vol

InnoDB weigert te starten zodra het geen redo logs meer kan wegschrijven. Typische regels:

[ERROR] InnoDB: Write to file ./ib_logfile0 failed at offset 0, 1048576 bytes should have been written, only 0 were written
[ERROR] InnoDB: Error number 28 means 'No space left on device'
Can't create/write to file (Errcode: 28 "No space left on device")

Controleer beide, vrije ruimte en vrije inodes:

df -h
df -i

Een volle inodeteller bij een schijnbaar lege schijf komt vaker voor dan men denkt, meestal door miljoenen kleine sessie- of cachebestanden. Wat u zonder risico mag verwijderen en wat niet, staat in Schijf vol onder Linux opruimen. Verwijder in /var/lib/mysql in geen geval iets met de hand, en zeker geen ib_logfile-bestanden terwijl er een recovery loopt.

De OOM-killer was sneller

Verdwijnt de dienst midden in bedrijf zonder foutmelding, dan heeft vaak de kernel toegeslagen:

dmesg -T | grep -i -E "oom|killed process"
journalctl -k | grep -i oom

Een regel als Out of memory: Killed process 1234 (mysqld) is ondubbelzinnig. De socketfout is dan alleen het symptoom. Tegenmaatregelen zijn een kleinere innodb_buffer_pool_size, minder gelijktijdige PHP-workers of wat swap als buffer, zie Swap instellen tegen out of memory.

Verweesd socketbestand na een crash

Ziet u in het logboek:

[ERROR] Do you already have another mysqld server running on socket: /run/mysqld/mysqld.sock ?
[ERROR] Aborting

Dan ligt er een socketbestand rond zonder bijbehorend proces. Stel eerst vast dat er echt geen server draait, verwijder daarna het bestand:

systemctl stop mariadb
pgrep -a mysqld
rm -f /run/mysqld/mysqld.sock
systemctl start mariadb

Toont pgrep nog een proces, verwijder het bestand dan niet. Anders verliezen alle draaiende applicaties hun verbinding, en de server maakt het bij de volgende start opnieuw aan terwijl het oude proces gewoon doorleeft.

Oorzaak 2: server en applicatie bedoelen verschillende paden

Dit is het geval waarin alles draait en er toch niets werkt: ss -lx toont /run/mysqld/mysqld.sock, maar de applicatie zoekt onder /tmp/mysql.sock. Typische aanleidingen zijn zelf gecompileerde servers, een overstap van MySQL naar MariaDB, een verhuizing van een paneelserver naar een kaal systeem of een PHP-installatie uit een externe repository met andere standaardwaarden.

De nette weg is om het pad op precies drie plekken gelijk te trekken. Ten eerste aan serverzijde. Het bestand daarvoor heet bij elke combinatie anders: onder Debian en Ubuntu met MariaDB /etc/mysql/mariadb.conf.d/50-server.cnf, onder Debian en Ubuntu met MySQL /etc/mysql/mysql.conf.d/mysqld.cnf, op AlmaLinux, Rocky Linux en Oracle Linux /etc/my.cnf.d/mariadb-server.cnf respectievelijk /etc/my.cnf.d/mysql-server.cnf. Een map /etc/mysql/ bestaat bij de Red Hat-familie helemaal niet, daar loopt alles via /etc/my.cnf en /etc/my.cnf.d/:

[mysqld]
socket = /run/mysqld/mysqld.sock

Ten tweede voor de commandoregelprogramma's, in 50-client.cnf of een eigen bestand:

[client]
socket = /run/mysqld/mysqld.sock

Ten derde voor PHP. De drie regels in de php.ini moeten hetzelfde pad bevatten, anders heeft de serverconfiguratie geen zin:

mysqli.default_socket = /run/mysqld/mysqld.sock
pdo_mysql.default_socket = /run/mysqld/mysqld.sock
mysql.default_socket = /run/mysqld/mysqld.sock

Welke php.ini eigenlijk geldt, vertelt php --ini u, mits het pakket php-cli geïnstalleerd is, anders antwoordt de shell alleen met php: command not found. Belangrijker is de beperking daarachter: php --ini noemt het bestand van de commandoregel, en juist dat is bij een webapplicatie bijna nooit de boosdoener. Doorslaggevend is het FPM-bestand, meestal /etc/php/8.3/fpm/php.ini, en wat daar werkelijk aankomt, laat php-fpm8.3 -i | grep -E 'Loaded Configuration|pdo_mysql.default_socket|mysqli.default_socket' zien. Na de wijziging is een herstart van de FPM-dienst nodig, niet alleen een reload van de webserver. Levert een PHP-applicatie daarna nog steeds niets op, dan is de volgende halte vaak nginx 502 Bad Gateway oplossen.

Bij applicaties die het pad hard hebben ingebakken en die u niet kunt aanpassen, helpt een symlink als laatste redmiddel:

ln -s /run/mysqld/mysqld.sock /tmp/mysql.sock

Dat overleeft echter geen herstart, omdat /tmp op veel systemen wordt geleegd. Permanent hoort dit in een tmpfiles-regel thuis, of beter nog in de configuratie van de applicatie.

Oorzaak 3: rechten en een ontbrekende /run/mysqld

Krijgt u (13) Permission denied, dan bestaat de socket wel, maar komt uw gebruiker er niet bij. De socket zelf staat doorgaans op 0777, de toegang strandt dan op de map erboven:

chown mysql:mysql /run/mysqld
chmod 755 /run/mysqld

De tweede klassieker: /run is een tmpfs en daarmee na elke herstart leeg. De submap /run/mysqld wordt bij het starten opnieuw aangemaakt, ofwel door systemd-tmpfiles ofwel door het startscript. Is de bijbehorende regel bij een handmatige installatie nooit meegeleverd, dan start de server precies één keer (zolang de map met de hand aanwezig was) en na de volgende herstart nooit meer. Maak dan /etc/tmpfiles.d/mysql.conf aan:

d /run/mysqld 0755 mysql mysql -

Toepassen kan zonder herstart met systemd-tmpfiles --create. Wie een eigen unit draait, kan in plaats daarvan RuntimeDirectory=mysqld instellen, zie systemd-service aanmaken.

Oorzaak 4: AppArmor en SELinux

Deze twee veroorzaken de meest verwarrende variant van de fout, omdat de rechten in het bestandssysteem correct ogen en de server toch meldt:

[ERROR] Can't start server: Bind on unix socket: Permission denied
[ERROR] Do you already have another mysqld server running on port: 3306 ?

Op Ubuntu levert het MySQL-pakket een AppArmor-profiel mee. Heeft u het socketpad op een ongebruikelijke plek gelegd, dan verbiedt het profiel het aanmaken van het bestand. De denials staan niet in het MySQL-logboek, maar hier:

dmesg -T | grep -i apparmor
journalctl -k | grep -i denied

Uitbreiden kunt u het profiel in /etc/apparmor.d/local/usr.sbin.mysqld, daar komt een regel als /run/mysqld/mein.sock rw, in, gevolgd door systemctl reload apparmor. Op AlmaLinux en Rocky Linux is SELinux de tegenhanger, daar controleert u met ausearch -m avc -ts recent en zet u de context met semanage fcontext en restorecon. In beide gevallen is de makkelijkste weg om de socket gewoon op de voorziene standaardlocatie te laten staan.

Distributieverschillen in één oogopslag

De meeste handleidingen beweren dat er één pad voor alle systemen is. Dat klopt niet, en juist daarop loopt het kopiëren van andermans oplossingen stuk. Stand juli 2026:

Twee punten daaruit zijn belangrijk. Ten eerste: Debian levert geen pakket mysql-server, daar is MariaDB de standaard. Een apt install mysql-server op Debian mislukt, en de bijbehorende handleidingen van internet leiden nergens heen. Ten tweede: bij de Red Hat-familie ligt de socket in de datamap, niet onder /run. Wie een applicatie van Debian naar AlmaLinux verhuist en het pad meeneemt, produceert de fout gegarandeerd.

Een bijzonder geval terzijde: in containers is er noch systemd noch de vertrouwde /run/mysqld van de host. Draait de database in de container en de applicatie ernaast, dan is er geen gedeelde socket. Daar leidt geen weg om TCP en de containernaam als host heen.

Hoe u ziet dat het echt is opgelost

Een systemctl start zonder foutmelding is geen bewijs. Controleer in deze volgorde:

systemctl is-active mariadb
ss -lx | grep mysql
mysqladmin ping
mysql -e "SELECT VERSION(), @@socket, @@datadir"

Het antwoord mysqld is alive van mysqladmin ping is het eigenlijke keurmerk, want het komt via dezelfde socket waarover ook uw applicatie loopt. Daarna de tegenproef vanuit de applicatielaag, dus niet als root, maar als de gebruiker onder wie de webserver draait:

sudo -u www-data mysql -u uwgebruiker -p uwdatabase -e "SELECT 1"

En tot slot de herstarttest. Een schrikbarend groot deel van de socketfouten komt na de volgende reboot terug, omdat de reparatie alleen tijdens de looptijd werkte (map met de hand aangemaakt, symlink in /tmp, dienst niet geactiveerd). Daarom:

systemctl enable mariadb
systemctl is-enabled mariadb

Start de server indien mogelijk één keer volledig opnieuw op en herhaal de vier controlecommando's. Op een KernelHost-rootserver duurt dat krap een minuut en bespaart het u een herhaling van de fout om drie uur 's nachts.

Als het bij het repareren misgaat

Drie situaties waarin mensen regelmatig blijven steken.

De server start na een configuratiewijziging helemaal niet meer. Een typefout in de .cnf leidt tot een onmiddellijke afbreking, vaak met unknown variable. De syntaxis is te controleren zonder de dienst te starten, al hangt het commando daarvoor af van de server:

mysqld --validate-config --user=mysql
mariadbd --help --verbose | head -40

De eerste regel geldt uitsluitend voor MySQL 8. --validate-config is een pure MySQL-optie en bestaat in geen enkele MariaDB-versie, getest van 10.5 tot en met 11.8. MariaDB antwoordt in plaats daarvan met [ERROR] mysqld: unknown option '--validate-config', gevolgd door [ERROR] Aborting, en bij de Red Hat-familie verschijnt die melding niet eens op de terminal, maar alleen in het foutlogboek: het commando lijkt daar volkomen stil te blijven. Ook de --user=mysql is verplicht en geen bijzaak, want als root aangeroepen breekt MySQL 8 al eerder af met Please consult the Knowledge Base to find out how to run mysqld as root!. Voor MariaDB bestaat er geen tegenhanger van --validate-config. Daar laat de tweede regel zien welke opties de server kent, en my_print_defaults mysqld mariadbd laat zien wat hij uit uw bestanden werkelijk inleest.

Bewaar voor elke wijziging een kopie, dan is de weg terug één enkele cp. Let er bovendien op in welk bestand u schrijft: onder Debian en Ubuntu worden de bestanden in conf.d alfabetisch ingelezen, een latere regel overschrijft een eerdere.

U komt er als root niet meer in. Bij MariaDB op Debian en Ubuntu staat voor root@localhost standaard authenticatie via unix_socket ingesteld. Dat betekent: sudo mysql werkt zonder wachtwoord, mysql -u root -p als gewone gebruiker daarentegen niet, en wel met ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Dat is geen socketprobleem, maar bedoeld gedrag.

U heeft het socketbestand verwijderd terwijl de server draaide. Het proces loopt door, houdt de verwijderde inode vast en is via het pad niet meer bereikbaar. Opnieuw aanmaken kunt u het bestand niet met de hand, een socket ontstaat alleen door een bind() van het proces. Hier helpt alleen een nette herstart van de dienst. Zolang die nog uitstaat, bereikt u de server via TCP met --protocol=TCP, mits skip-networking niet is ingesteld. Gebruik dat tijdvenster voor een dump van de belangrijkste databases voordat u herstart.

Een laatste opmerking over de volgorde: verander nooit meerdere dingen tegelijk. Eerst de dienststatus, dan de padvergelijking, dan de rechten. Wie tegelijk de my.cnf, de php.ini en de bestandsrechten aanpakt, weet achteraf niet wat geholpen heeft en begint de volgende keer weer van voren af aan. Zet u een systeem vers op en wilt u zulke valkuilen vanaf het begin vermijden, dan helpt de checklist voor een nieuwe rootserver, en voor de complete databasestack met webinterface het artikel Apache, PHP, MySQL en phpMyAdmin op Debian installeren.