Introduction

The error Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) usually means the client tried to connect through a Unix socket file that does not exist at that path. The key part is (2), which is the operating system error for "No such file or directory", so the first job is to determine whether MySQL is down or whether the socket path is simply different from what the client expects.

What the socket error actually means

When you run a local command such as mysql -u root -p without a host, the client often prefers a Unix socket instead of TCP. That is usually faster and avoids network configuration, but it only works if both sides agree on the same socket file path.

If the server is configured to create its socket at /var/run/mysqld/mysqld.sock while the client looks for /tmp/mysql.sock, you will get this error even though MySQL may be running perfectly. The same message also appears when the server never started, because no socket file was created at all.

Check whether the server is running

Start with service status and recent logs:

sudo systemctl status mysql
sudo journalctl -u mysql --no-pager -n 50

On systems that still use older service commands, this is equivalent:

sudo service mysql status

If MySQL is not running, start it and watch for startup failures:

sudo systemctl start mysql
sudo systemctl status mysql

If the service refuses to start, the socket path is probably not the root issue. Look for disk space problems, permission failures on the data directory, port conflicts, or configuration syntax errors in the MySQL error log.

Find the actual socket path

Once the server is up, verify the path it is really using instead of assuming /tmp/mysql.sock.

mysqladmin variables | grep socket

You can also inspect configuration files directly:

grep -R "socket" /etc/mysql /etc/my.cnf /usr/local/etc/my.cnf 2>/dev/null

A healthy result often shows something like this:

| socket | /var/run/mysqld/mysqld.sock |

Now compare that with your client configuration. Many local tools read socket settings from ~/.my.cnf, /etc/my.cnf, application environment variables, or framework-specific database config files. If the client is pinned to /tmp/mysql.sock, update it to the real path.

Fix the mismatch

If you want both client and server to use the same Unix socket, set the same value in the relevant configuration files and restart MySQL. A minimal example looks like this:

1[mysqld]
2socket=/var/run/mysqld/mysqld.sock
3
4[client]
5socket=/var/run/mysqld/mysqld.sock

After editing the config, restart the service:

sudo systemctl restart mysql
mysql -u root -p

If you are on macOS with Homebrew, the socket path is often under /tmp, /opt/homebrew/var/mysql, or /usr/local/var/mysql depending on architecture and installation age. The fix is the same: discover the real path first, then align the client settings.

Use TCP as a short-term workaround

If you just need to connect immediately and do not want to sort out socket config yet, force a TCP connection:

mysql -h 127.0.0.1 -P 3306 -u root -p

This bypasses the Unix socket entirely. It is a useful diagnostic step because it tells you whether MySQL is reachable at the network layer even when local socket config is wrong.

Application frameworks can do the same thing by using 127.0.0.1 instead of localhost. On many systems, localhost implies a socket connection, while 127.0.0.1 implies TCP.

Common Pitfalls

The most common mistake is assuming the socket path is always /tmp/mysql.sock. Different Linux distributions, container images, and macOS installs use different defaults, so always verify the actual path instead of copying a fix from another machine.

Another pitfall is restarting the client configuration without restarting the server. If you change [mysqld] settings, the server must restart before the new socket path exists.

Permissions can also block access even when the file exists. If the socket directory is unreadable to your user or the MySQL process cannot create the file, the symptom can look similar. Check ownership and directory permissions along with the file path.

Finally, do not ignore the server logs. A socket error is often only the last visible symptom of a deeper startup problem.

Summary

• '(2) means the socket file was not found at the path the client tried to use.'
• First check whether MySQL is actually running, then verify the real socket path.
• Align [mysqld] and [client] socket settings if they disagree.
• Use mysql -h 127.0.0.1 as a quick TCP workaround and diagnostic step.
• If MySQL still will not start, inspect the server logs because the socket path may be only a secondary symptom.