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.
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.
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.
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
sudo grep -r 'socket' /etc/mysql/ 2>/dev/null | head; ls -la /var/run/mysqld/ 2>/dev/null
# /etc/mysql/my.cnf [client] socket = /var/run/mysqld/mysqld.sock (match the [mysqld] value)
mysql -h 127.0.0.1 -P 3306 -u root -p # -h skips socket lookup entirely
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.
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.
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.
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.