MySQL-Fehler "Can't connect through socket" beheben

Die Meldung taucht immer im ungünstigsten Moment auf: nach einem Neustart, nach einem Update oder wenn die Platte nachts vollgelaufen ist. Der Wortlaut ist fast immer derselbe:

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

Zwei Angaben stecken darin, die viele überlesen: der Pfad und die Zahl in Klammern. Beide sagen ziemlich genau, wo Sie suchen müssen. Dieser Artikel geht die fünf realistischen Ursachen durch (Dienst läuft nicht, falscher Socket-Pfad in der Konfiguration, Anwendung erwartet einen anderen Pfad als der Server nutzt, Rechteproblem, Platte voll), zeigt die Diagnose in der Reihenfolge, in der sie am schnellsten zum Ziel führt, und erklärt den Unterschied zwischen localhost und 127.0.0.1, der rund die Hälfte aller Fälle allein auflöst.

Die Fehlermeldung genau lesen

Der Client hat versucht, über einen Unix-Domain-Socket zu verbinden, also über eine Datei im Dateisystem, nicht über das Netzwerk. Der Pfad in Anführungszeichen ist der Pfad, den der Client erwartet. Ob der Server denselben Pfad benutzt, sagt die Meldung nicht. Genau da liegt oft das Problem.

Die Zahl am Ende ist der Fehlercode des Betriebssystems:

Je nach Client und Version variiert der Wortlaut. Diese Varianten meinen alle dasselbe:

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)

Aus PHP heraus sieht derselbe Fehler so aus, weil PHP nur den nackten errno durchreicht:

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

Wichtig für die Abgrenzung: ERROR 2003 ist etwas anderes. Dort steht eine IP-Adresse und ein Port statt eines Pfades, das ist der TCP-Weg. Und ERROR 1045 (28000): Access denied for user heißt, dass die Verbindung stand und nur die Anmeldung scheiterte. Dafür haben wir einen eigenen Beitrag: MySQL "Access denied for user" beheben.

localhost oder 127.0.0.1: der Unterschied, der die Hälfte der Fälle erklärt

MySQL und MariaDB behandeln localhost als Sonderfall. Steht dort wörtlich localhost, ignoriert die Client-Bibliothek den Hostnamen komplett und verbindet über den Unix-Socket. Steht dort 127.0.0.1, geht die Verbindung über TCP zum Port 3306. Das ist kein Detail, sondern der Kern des Problems: Eine Anwendung mit localhost in der Konfiguration erreicht den Server über eine Datei, deren Pfad sie irgendwo anders herbekommt als der Server.

Der schnellste Test, ob überhaupt ein Server läuft, ist deshalb dieser:

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

Kommt hier eine Anmeldemaske oder ein Access-denied, dann läuft der Dienst und Sie haben ein reines Socket-Problem. Kommt ERROR 2003 ... (111), läuft der Dienst nicht oder lauscht nicht auf TCP.

Als Dauerlösung ist das Umstellen auf 127.0.0.1 allerdings zweite Wahl. Der Socket ist schneller, er umgeht den Netzwerkstack, und er ist von außen prinzipiell nicht erreichbar. Vor allem aber: In der Benutzertabelle steht 'app'@'localhost' nicht automatisch auch für 'app'@'127.0.0.1'. Wer den Host in der Anwendung umstellt und danach ein Access-denied bekommt, hat genau diesen Effekt erwischt. Und wenn Sie auf TCP umstellen, prüfen Sie, dass bind-address nicht versehentlich auf 0.0.0.0 steht und die Datenbank plötzlich im Internet hängt. Dazu passt MariaDB und MySQL absichern und UFW-Firewall einrichten.

Diagnose in fünf Minuten

Schritt 1: Läuft der Dienst überhaupt?

systemctl status mariadb
systemctl status mysql

Auf Debian und Ubuntu heißt die Unit bei MariaDB mariadb.service (mit mysql.service als Alias), bei MySQL mysql.service. Auf AlmaLinux, Rocky Linux und RHEL heißt sie mariadb.service beziehungsweise mysqld.service. Interessant ist die Zeile Active:. Steht dort active (running), springen Sie direkt zu Schritt 2. Steht dort failed (Result: exit-code) oder inactive (dead), ist die Ursache im Fehlerprotokoll zu finden.

Schritt 2: Welchen Socket-Pfad benutzt der Server wirklich?

Das lässt sich ohne laufenden Server aus den Konfigurationsdateien auslesen. my_print_defaults wertet dieselbe Kette an Dateien aus wie der Server selbst, inklusive aller Includes. Geben Sie dabei alle in Frage kommenden Gruppen auf einmal an, dann funktioniert der Befehl auf jeder Distribution:

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

Die vier Gruppennamen sind kein Übereifer, sondern die Antwort auf drei Fallstricke, die einzeln jeweils eine leere Ausgabe erzeugen. my_print_defaults client liefert auf allen geprüften Distributionen gar nichts, weil in 50-client.cnf beziehungsweise /etc/my.cnf.d/client.cnf sämtliche Optionen auskommentiert sind. Der Socket steht auf Debian und Ubuntu stattdessen in der Gruppe [client-server] von /etc/mysql/mariadb.cnf und erscheint dort als --socket=/run/mysqld/mysqld.sock. Auf der Red-Hat-Familie existiert diese Gruppe nicht, dort liefert mysqld den Wert --socket=/var/lib/mysql/mysql.sock. Und ab MariaDB 11.8, also ab Debian 13, heißt die Servergruppe in 50-server.cnf nicht mehr [mysqld], sondern [mariadbd]. Wer dort nur my_print_defaults mysqld aufruft, sieht eine leere Ausgabe und hält seine Konfiguration fälschlich für leer.

Alternativ, wenn der Server läuft und Sie hineinkommen:

mysql -e "SHOW VARIABLES LIKE 'socket'"

Und ganz ohne Anmeldung, direkt am Kernel vorbei gefragt, welche Unix-Sockets belegt sind:

ss -lx | grep -i mysql

Meldet die Shell ss: command not found, fehlt schlicht das Paket. Auf Debian und Ubuntu heißt es iproute2, auf AlmaLinux, Rocky Linux und Oracle Linux iproute:

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

Damit haben Sie den Pfad, den der Server tatsächlich bereitstellt. Vergleichen Sie ihn Zeichen für Zeichen mit dem Pfad aus der Fehlermeldung. /run/mysqld/mysqld.sock und /var/run/mysqld/mysqld.sock sind auf modernen Systemen dasselbe, weil /var/run ein Symlink auf /run ist. /var/lib/mysql/mysql.sock und /tmp/mysql.sock sind es nicht.

Schritt 3: Existiert die Datei, und wem gehört sie?

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

Erwartet wird eine Datei vom Typ s (Socket), Eigentümer mysql:mysql, Rechte srwxrwxrwx. Das Verzeichnis darüber sollte drwxr-xr-x mysql mysql sein. Fehlt das Verzeichnis /run/mysqld komplett, hat der Server nie erfolgreich gestartet, denn es wird beim Start angelegt.

Schritt 4: Das Fehlerprotokoll lesen

Hier trennen sich die Distributionen deutlich, und hier steckt der häufigste Grund, warum Anleitungen im Netz nicht weiterhelfen. Auf Ubuntu mit MySQL schreibt der Server nach /var/log/mysql/error.log. Auf Debian mit MariaDB ist log_error in der Voreinstellung auskommentiert, das Verzeichnis /var/log/mysql/ existiert dort gar nicht, und alles landet im Journal. Nehmen Sie deshalb die Zeile, die zu Ihrer Kombination passt:

Eine Falle verdient dabei besondere Aufmerksamkeit, weil sie keinen Fehler produziert: Auf einem Debian-System 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. journalctl -u mysql antwortet dort mit -- No entries -- und Exit-Code 0, obwohl das Journal voll ist. Wer nur diesen Befehl probiert, hält das Protokoll für leer und sucht an der falschen Stelle weiter. Umgekehrt gilt dasselbe: Auf einem Ubuntu-System mit MySQL liefert journalctl -u mariadb ebenfalls -- No entries --. Wenn Sie nicht sicher sind, welche Unit gemeint ist, fragen Sie beide auf einmal ab:

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

Wenn Sie ein dauerhaftes Protokoll haben möchten, setzen Sie unter Debian und Ubuntu in /etc/mysql/mariadb.conf.d/50-server.cnf in der Servergruppe ein log_error = /var/log/mysql/error.log, legen das Verzeichnis mit install -d -o mysql -g mysql /var/log/mysql an und starten neu.

Ursache 1: Der Dienst läuft nicht (und warum)

Ein systemctl start mariadb ist der Reflex, aber wenn der Dienst gerade eben von selbst gestorben ist, startet er in der Regel gleich wieder in denselben Fehler. Vorher lohnt ein Blick auf drei konkrete Muster im Protokoll.

Platte voll

InnoDB verweigert den Start, sobald es keine Redo-Logs schreiben kann. Typische Zeilen:

[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")

Prüfen Sie beides, freien Platz und freie Inodes:

df -h
df -i

Ein voller Inode-Zähler bei scheinbar freier Platte kommt häufiger vor, als man denkt, meist durch Millionen kleiner Session- oder Cache-Dateien. Was Sie gefahrlos löschen dürfen und was nicht, steht in Festplatte voll unter Linux aufräumen. Löschen Sie in /var/lib/mysql auf keinen Fall irgendetwas von Hand, insbesondere keine ib_logfile-Dateien bei laufender Recovery.

Der OOM-Killer war schneller

Wenn der Dienst mitten im Betrieb ohne Fehlermeldung verschwindet, hat oft der Kernel zugeschlagen:

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

Eine Zeile wie Out of memory: Killed process 1234 (mysqld) ist eindeutig. Der Socket-Fehler ist dann nur das Symptom. Gegenmittel sind eine kleinere innodb_buffer_pool_size, weniger gleichzeitige PHP-Worker oder etwas Swap als Puffer, siehe Swap einrichten gegen Out-of-Memory.

Verwaiste Socket-Datei nach einem Absturz

Sehen Sie im Protokoll:

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

Dann liegt eine Socket-Datei herum, ohne dass ein Prozess dazu gehört. Erst sicherstellen, dass wirklich kein Server läuft, dann die Datei entfernen:

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

Wenn pgrep noch einen Prozess anzeigt, löschen Sie die Datei nicht. Sonst verlieren alle laufenden Anwendungen ihre Verbindung, und der Server legt sie beim nächsten Start neu an, während der alte Prozess weiterlebt.

Ursache 2: Server und Anwendung meinen verschiedene Pfade

Das ist der Fall, in dem alles läuft und trotzdem nichts geht: ss -lx zeigt /run/mysqld/mysqld.sock, die Anwendung sucht aber unter /tmp/mysql.sock. Typische Auslöser sind selbst kompilierte Server, Wechsel von MySQL auf MariaDB, ein Umzug von einem Panel-Server auf ein blankes System oder eine PHP-Installation aus einem Fremd-Repository mit anderen Voreinstellungen.

Der saubere Weg ist, den Pfad an genau drei Stellen gleichzuziehen. Erstens auf Serverseite. Die Datei dafür heißt auf jeder Kombination anders: unter Debian und Ubuntu mit MariaDB /etc/mysql/mariadb.conf.d/50-server.cnf, unter Debian und Ubuntu mit MySQL /etc/mysql/mysql.conf.d/mysqld.cnf, auf AlmaLinux, Rocky Linux und Oracle Linux /etc/my.cnf.d/mariadb-server.cnf beziehungsweise /etc/my.cnf.d/mysql-server.cnf. Ein Verzeichnis /etc/mysql/ existiert auf der Red-Hat-Familie überhaupt nicht, dort läuft alles über /etc/my.cnf und /etc/my.cnf.d/:

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

Zweitens für die Kommandozeilenwerkzeuge, in 50-client.cnf oder einer eigenen Datei:

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

Drittens für PHP. Die drei Einträge in der php.ini müssen denselben Pfad enthalten, sonst nützt die Serverkonfiguration nichts:

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

Welche php.ini überhaupt gilt, sagt Ihnen php --ini, sofern das Paket php-cli installiert ist, sonst antwortet die Shell nur mit php: command not found. Wichtiger ist die Einschränkung dahinter: php --ini nennt die Datei der Kommandozeile, und genau die ist bei einer Webanwendung fast nie die schuldige. Maßgeblich ist die FPM-Datei, meist /etc/php/8.3/fpm/php.ini, und was dort wirklich ankommt, zeigt php-fpm8.3 -i | grep -E 'Loaded Configuration|pdo_mysql.default_socket|mysqli.default_socket'. Nach der Änderung ist ein Neustart des FPM-Dienstes nötig, nicht nur ein Reload des Webservers. Wenn danach eine PHP-Anwendung weiterhin nichts liefert, ist der nächste Halt oft nginx 502 Bad Gateway beheben.

Bei Anwendungen, die den Pfad fest verdrahtet haben und die Sie nicht anfassen können, hilft ein Symlink als letzte Instanz:

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

Das überlebt allerdings keinen Neustart, weil /tmp auf vielen Systemen geleert wird. Dauerhaft gehört das in eine tmpfiles-Regel oder besser in die Konfiguration der Anwendung.

Ursache 3: Rechte und ein fehlendes /run/mysqld

Bekommen Sie (13) Permission denied, existiert der Socket, aber Ihr Benutzer kommt nicht heran. Der Socket selbst steht üblicherweise auf 0777, der Zugriff scheitert dann am Verzeichnis darüber:

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

Der zweite Klassiker: /run ist ein tmpfs und damit nach jedem Neustart leer. Das Unterverzeichnis /run/mysqld wird beim Start neu angelegt, entweder durch systemd-tmpfiles oder durch das Startskript. Wurde die passende Regel bei einer manuellen Installation nie mitgeliefert, startet der Server genau einmal (solange das Verzeichnis von Hand da war) und nach dem nächsten Neustart nie wieder. Legen Sie dann /etc/tmpfiles.d/mysql.conf an:

d /run/mysqld 0755 mysql mysql -

Anwenden lässt sich das ohne Neustart mit systemd-tmpfiles --create. Wer eine eigene Unit betreibt, kann stattdessen RuntimeDirectory=mysqld setzen, siehe systemd-Service erstellen.

Ursache 4: AppArmor und SELinux

Diese beiden erzeugen die verwirrendste Variante des Fehlers, weil die Rechte im Dateisystem korrekt aussehen und der Server trotzdem meldet:

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

Auf Ubuntu bringt das MySQL-Paket ein AppArmor-Profil mit. Wenn Sie den Socket-Pfad auf etwas Ungewöhnliches gelegt haben, verbietet das Profil das Anlegen der Datei. Die Denials stehen nicht im MySQL-Protokoll, sondern hier:

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

Erweitern lässt sich das Profil in /etc/apparmor.d/local/usr.sbin.mysqld, dort kommt eine Zeile wie /run/mysqld/mein.sock rw, hinein, danach systemctl reload apparmor. Auf AlmaLinux und Rocky Linux ist SELinux das Gegenstück, dort prüfen Sie mit ausearch -m avc -ts recent und setzen den Kontext mit semanage fcontext und restorecon. In beiden Fällen ist der bequemere Weg, den Socket einfach am vorgesehenen Standardort zu belassen.

Distributionsunterschiede auf einen Blick

Die meisten Anleitungen behaupten einen einzigen Pfad für alle Systeme. Das stimmt nicht, und genau daran scheitert das Kopieren fremder Lösungen. Stand Juli 2026:

Zwei Punkte daraus sind wichtig. Erstens: Debian liefert kein Paket mysql-server, dort ist MariaDB gesetzt. Ein apt install mysql-server auf Debian schlägt fehl, und die dazu passenden Anleitungen aus dem Netz führen ins Leere. Zweitens: Auf der Red-Hat-Familie liegt der Socket im Datenverzeichnis, nicht unter /run. Wer eine Anwendung von Debian nach AlmaLinux umzieht und den Pfad mitnimmt, produziert den Fehler zuverlässig.

Ein Sonderfall am Rande: In Containern gibt es weder systemd noch das gewohnte /run/mysqld des Hosts. Läuft die Datenbank im Container und die Anwendung daneben, gibt es keinen gemeinsamen Socket. Dort führt kein Weg an TCP und dem Containernamen als Host vorbei.

Woran Sie erkennen, dass es wirklich behoben ist

Ein systemctl start ohne Fehlermeldung ist kein Beweis. Prüfen Sie in dieser Reihenfolge:

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

Die Antwort mysqld is alive von mysqladmin ping ist das eigentliche Gütesiegel, denn sie kommt über denselben Socket, über den auch Ihre Anwendung geht. Danach die Gegenprobe aus der Anwendungsschicht heraus, also nicht als root, sondern als der Benutzer, unter dem der Webserver läuft:

sudo -u www-data mysql -u ihrbenutzer -p ihredatenbank -e "SELECT 1"

Und zuletzt der Neustarttest. Ein erschreckend großer Teil der Socket-Fehler kommt nach dem nächsten Reboot zurück, weil die Reparatur nur zur Laufzeit wirkte (Verzeichnis von Hand angelegt, Symlink in /tmp, Dienst nicht aktiviert). Deshalb:

systemctl enable mariadb
systemctl is-enabled mariadb

Wenn möglich, starten Sie den Server einmal komplett neu und wiederholen die vier Prüfbefehle. Auf einem KernelHost-Rootserver dauert das eine knappe Minute und erspart Ihnen die Wiederholung des Fehlers um drei Uhr nachts.

Wenn es beim Reparieren schiefgeht

Drei Situationen, in denen Leute regelmäßig hängenbleiben.

Der Server startet nach einer Konfigurationsänderung gar nicht mehr. Ein Tippfehler in der .cnf führt zu einem sofortigen Abbruch, oft mit unknown variable. Die Syntax lässt sich prüfen, ohne den Dienst zu starten, der Befehl dafür hängt allerdings am Server:

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

Die erste Zeile gilt ausschließlich für MySQL 8. --validate-config ist eine reine MySQL-Option und existiert in keiner MariaDB-Version, geprüft von 10.5 bis 11.8. MariaDB antwortet stattdessen mit [ERROR] mysqld: unknown option '--validate-config' gefolgt von [ERROR] Aborting, und auf der Red-Hat-Familie steht diese Meldung nicht einmal am Terminal, sondern nur im Fehlerprotokoll: der Befehl wirkt dort völlig stumm. Auch das --user=mysql ist Pflicht und kein Beiwerk, denn als root aufgerufen bricht MySQL 8 schon vorher mit Please consult the Knowledge Base to find out how to run mysqld as root! ab. Für MariaDB gibt es kein Gegenstück zu --validate-config. Dort zeigt die zweite Zeile, welche Optionen der Server überhaupt kennt, und my_print_defaults mysqld mariadbd zeigt, was er aus Ihren Dateien tatsächlich liest.

Bewahren Sie vor jeder Änderung eine Kopie auf, dann ist der Rückweg ein einziger cp. Achten Sie außerdem darauf, in welche Datei Sie schreiben: Unter Debian und Ubuntu werden die Dateien in conf.d alphabetisch eingelesen, ein späterer Eintrag überschreibt einen früheren.

Sie kommen als root nicht mehr hinein. Bei MariaDB auf Debian und Ubuntu ist für root@localhost die Authentifizierung über unix_socket voreingestellt. Das heißt: sudo mysql funktioniert ohne Passwort, mysql -u root -p als normaler Benutzer dagegen nicht, und zwar mit ERROR 1698 (28000): Access denied for user 'root'@'localhost'. Das ist kein Socket-Problem, sondern gewolltes Verhalten.

Sie haben die Socket-Datei gelöscht, während der Server lief. Der Prozess läuft weiter, hält den gelöschten Inode und ist über den Pfad nicht mehr erreichbar. Neu anlegen lässt sich die Datei nicht von Hand, ein Socket entsteht nur durch bind() des Prozesses. Hier hilft nur ein sauberer Neustart des Dienstes. Solange der noch aussteht, erreichen Sie den Server über TCP mit --protocol=TCP, sofern skip-networking nicht gesetzt ist. Nutzen Sie dieses Zeitfenster für einen Dump der wichtigsten Datenbanken, bevor Sie neu starten.

Ein letzter Hinweis zur Reihenfolge: Ändern Sie nie mehrere Dinge gleichzeitig. Erst Dienststatus, dann Pfadabgleich, dann Rechte. Wer parallel die my.cnf, die php.ini und die Dateirechte anfasst, weiß hinterher nicht, was geholfen hat, und hat beim nächsten Mal wieder von vorne angefangen. Wenn Sie ein System frisch aufsetzen und solche Fallstricke von Beginn an vermeiden wollen, hilft die Checkliste für einen neuen Rootserver, und für den kompletten Datenbankstack mit Weboberfläche der Beitrag Apache, PHP, MySQL und phpMyAdmin auf Debian installieren.