MySQL "Can't Connect to Local Server Through Socket" — Where the Socket Went

The client looked for a unix socket file that isn't there — mysqld is down, or it uses a different socket path than the client expects. Two checks, then you know which.

What you'll see

Root causes

mysqld not running (or crashed)

The socket file only exists while the server runs. systemctl status mariadb/mysql and the error log tell you if it crashed — OOM and failed upgrades are the usual reasons.

Socket path mismatch between client and server

Client reads /etc/mysql/my.cnf (or defaults), server writes where its own config says — mariadb.sock vs mysql.sock after a distro switch. mysql --socket=/path/to/real.sock bypasses the confusion to prove it.

Fix it

  1. Check server status first
    systemctl status mysql mariadb --no-pager; sudo tail -30 /var/log/mysql/error.log 2>/dev/null || sudo journalctl -u mysql -n 30 --no-pager
  2. See the socket path the server actually uses
    sudo grep -r 'socket' /etc/mysql/ 2>/dev/null | head; ls -la /var/run/mysqld/ 2>/dev/null
  3. Align the client config with reality
    # /etc/mysql/my.cnf [client] socket = /var/run/mysqld/mysqld.sock  (match the [mysqld] value)
  4. Or connect via TCP explicitly (always works when the server is up)
    mysql -h 127.0.0.1 -P 3306 -u root -p   # -h skips socket lookup entirely

Field note

TCP to 127.0.0.1 is the universal workaround while you fix configs — it ignores sockets completely. PHP apps hardcode the socket path in php.ini (mysqli.default_socket / pdo_mysql.default_socket) — same mismatch, same fix.

Common questions

Why does mysql work for my colleague but not for me?

Different client configs: their my.cnf points at the socket path your server actually uses (or they default to TCP). Compare with mysql --print-defaults and align your [client] socket value.

What does the (2) in the error mean?

It's errno 2: 'No such file or directory' — the socket file literally isn't there. That's a down server or a wrong path, not an auth problem.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.