How to fix Could not connect to server: No such file or directory in PostgreSQL

PostgreSQLBEGINNERHIGHUpdated Dec 25, 2025· 144 views

PostgreSQL "Could not connect to server: No such file or directory" occurs when the client cannot find the Unix domain socket file needed to connect locally. Common causes include PostgreSQL not running, mismatched socket paths between client and server, permission issues, or leftover postmaster.pid files blocking startup. Fixing requires restarting the server, verifying socket locations, and checking permissions.

Quick fix

Fixes Could not connect to server: No such file or directory

# Check for postgres processes:
pgrep -l postgres
# or:
ps aux | grep postgres

# On Linux with systemd:
sudo systemctl status postgresql

# On macOS with Homebrew:
brew services list | grep postgres

# On other systems:
sudo service postgresql status
  1. Verify PostgreSQL server is running
  2. Start the PostgreSQL server
  3. Remove stale postmaster.pid file if startup fails
  4. Check that the socket directory exists and has correct permissions
postgresql — error
# Check for postgres processes:
pgrep -l postgres
# or:
ps aux | grep postgres
# On Linux with systemd:
sudo systemctl status postgresql
# On macOS with Homebrew:
brew services list | grep postgres
# On other systems:
sudo service postgresql status
Could not connect to server: No such file or directory

What this error means

This error occurs when the PostgreSQL client (psql, libpq, application drivers) attempts to connect to a local PostgreSQL server via Unix domain socket but cannot locate the socket file. On Unix/Linux systems, PostgreSQL creates a socket file in a configured directory (default /var/run/postgresql or /tmp) with a predictable name like .s.PGSQL.5432. When the client attempts to connect without specifying a host (or with host=localhost on non-Windows systems), it looks for this socket file. If the file does not exist, you get this error. The error itself does not tell you why the file is missing—only that it cannot be found. The underlying cause is almost always one of: PostgreSQL server is not running, the server failed to start properly and never created the socket file, the client and server have different socket directory configurations, the socket file was deleted or the directory was removed, or the socket file exists but the client lacks permissions to access it.

Typical symptoms

  • psql command fails immediately with "No such file or directory" message
  • Applications using libpq or database drivers cannot establish local connections
  • Connection attempts hang or fail quickly when no hostname is specified
  • Error message shows the socket path being searched (e.g., /tmp/.s.PGSQL.5432)
  • Forced shutdown of PostgreSQL (power loss, kill -9) prevents reconnection
  • PostgreSQL logs show the server is running, but connections still fail
  • Permissions prevent the postgres user from creating socket files in the configured directory

Common causes

  1. PostgreSQL server is not running—the most common cause. The socket file only exists while the server is active.
  2. PostgreSQL failed to start cleanly, leaving a stale postmaster.pid file that blocks startup attempts
  3. Socket directory does not exist (e.g., /var/run/postgresql was deleted after a reboot)
  4. Client and server have different unix_socket_directories configuration, so they look in different locations
  5. Socket directory or postmaster.pid file has incorrect permissions, preventing the postgres user from creating the socket
  6. Forced shutdown or power loss corrupted the socket file, and it was not cleaned up
  7. Client is running in a container or chroot that cannot access the socket file on the host
  8. On macOS with Homebrew, the service is not running or the Homebrew PostgreSQL installation is incomplete

How to fix "Could not connect to server: No such file or directory"

1Verify PostgreSQL server is running

The most common cause is that the server is not running. Check if the postgres process is active.

bash
# Check for postgres processes:
pgrep -l postgres
# or:
ps aux | grep postgres

# On Linux with systemd:
sudo systemctl status postgresql

# On macOS with Homebrew:
brew services list | grep postgres

# On other systems:
sudo service postgresql status

If no postgres process is running, the server needs to be started. Proceed to the next step.

2Start the PostgreSQL server

If the server is not running, start it cleanly.

bash
# On Linux with systemd:
sudo systemctl start postgresql

# On older Linux systems:
sudo service postgresql start
# or:
sudo /etc/init.d/postgresql start

# On macOS with Homebrew:
brew services start postgresql
# or for a specific version:
brew services start postgresql@14

# On manual installations:
sudo -u postgres /usr/lib/postgresql/14/bin/pg_ctl start -D /var/lib/postgresql/14/main

Wait a few seconds for the server to fully start before attempting to connect.

3Remove stale postmaster.pid file if startup fails

If the server will not start, a stale postmaster.pid file may be blocking startup. Remove it and try again.

bash
# First, verify no postgres processes are running:
pkill postgres

# Find and remove the postmaster.pid file:
sudo find / -name "postmaster.pid" 2>/dev/null

# Common locations:
sudo rm /var/lib/postgresql/14/main/postmaster.pid
sudo rm /usr/local/var/postgres/postmaster.pid  # macOS Homebrew
sudo rm /tmp/postmaster.pid

# Then restart:
sudo systemctl start postgresql
# or on macOS:
brew services restart postgresql

Always verify that no postgres processes are running before removing postmaster.pid, as removing it while the server is running can corrupt the database.

4Check that the socket directory exists and has correct permissions

Verify the socket directory exists and the postgres user can create files in it.

bash
# Check what socket directory PostgreSQL is configured to use:
sudo -u postgres psql -c "SHOW unix_socket_directories;"

# If the above fails (because the server is not running), check the configuration file:
grep -n "unix_socket_directories" /etc/postgresql/14/main/postgresql.conf

# Default locations:
# Linux (Debian/Ubuntu): /var/run/postgresql
# Linux (manual): /tmp
# macOS (Homebrew): /tmp

# Verify the directory exists:
ls -ld /var/run/postgresql
ls -ld /tmp

# If the directory does not exist, create it:
sudo mkdir -p /var/run/postgresql
sudo chown postgres:postgres /var/run/postgresql
sudo chmod 2777 /var/run/postgresql

The directory must be owned by the postgres user and have write permissions (typically 2777 or 755).

5Verify the socket file was created after startup

After starting PostgreSQL, the socket file should be created in the configured directory.

bash
# Check for the socket file (default port 5432):
ls -l /var/run/postgresql/.s.PGSQL.5432
ls -l /tmp/.s.PGSQL.5432

# List all socket files:
ls -l /var/run/postgresql/
ls -l /tmp/.s.PGSQL*

# Check file permissions:
ls -la /var/run/postgresql/ | grep PGSQL

The socket file should be owned by postgres and world-readable/writable (permissions 0777 or similar). If it does not exist after starting the server, check the PostgreSQL error log.

6Connect using the correct socket path if server and client differ

If the server is running but the client still cannot find it, the client may be looking in the wrong socket directory. Specify the socket path explicitly.

bash
# If server uses /var/run/postgresql but client looks in /tmp:
psql -h /var/run/postgresql -U postgres

# Or set the environment variable:
export PGHOST=/var/run/postgresql
psql

# For applications, set PGHOST in the connection string or DSN:
# PostgreSQL connection string: postgresql://postgres@/var/run/postgresql/postgres

# To verify which socket PostgreSQL is using:
sudo -u postgres psql -c "SHOW unix_socket_directories;"

# To verify which socket the client is looking for:
psql --version
psql -d postgres -h /var/run/postgresql -U postgres

If you need to change the server's socket directory, edit postgresql.conf and restart the server.

7For macOS with Homebrew, reinstall if necessary

On macOS, Homebrew installations sometimes have incomplete or misaligned configurations.

bash
# Check Homebrew PostgreSQL status:
brew services list | grep postgres

# Stop the service:
brew services stop postgresql

# Verify it is stopped:
brew services list | grep postgres

# Restart with a fresh start:
brew services start postgresql

# If problems persist, reinstall:
brew uninstall postgresql
brew install postgresql

# Initialize a fresh database:
rm -rf /usr/local/var/postgres
brewpostgres-setup
brew services start postgresql

# Test the connection:
psql -U $(whoami)

Always back up your data before uninstalling.

8Check PostgreSQL logs for startup errors

If the server fails to start or acts unexpectedly, check the logs for clues.

bash
# On Linux with systemd:
sudo journalctl -u postgresql -n 50

# On systems with a separate log file:
tail -50 /var/log/postgresql/postgresql-14-main.log

# On macOS:
log stream --predicate 'eventMessage contains "postgres"' --level debug

# Or check Homebrew log:
tail -50 $(brew --prefix)/var/log/postgres.log

# To see startup messages directly, start the server in foreground:
sudo -u postgres /usr/lib/postgresql/14/bin/postgres -D /var/lib/postgresql/14/main

Common log messages include permission denied, port already in use, or failed to initialize the data directory. Fix the issue shown in the logs before attempting reconnection.

Advanced notes

In containerized environments (Docker, Kubernetes), the socket file exists only within the container. If your application and PostgreSQL are in different containers, you must connect via TCP (host:port) instead of Unix socket. Set the connection string to something like "postgresql://host:5432/dbname" instead of relying on socket defaults. The socket approach only works if your application and database are on the same container or share a volume.

For replication and cluster setups, each PostgreSQL instance has its own socket in its own unix_socket_directories. If you are connecting to a replica or cluster node, ensure you are pointing to the correct socket path for that specific instance.

On systems with AppArmor or SELinux enabled, socket file creation or access may be blocked by policy. Check apparmor logs with sudo dmesg | grep apparmor or SELinux logs with sudo ausearch -m AVC. You may need to update the security policy to allow socket access.

When migrating PostgreSQL to a different system or updating a major version, the socket directory path may change. Always verify unix_socket_directories in the new postgresql.conf and update client connection strings accordingly.

If you customized unix_socket_directories to use the abstract namespace (Linux only), the path starts with "@" but is not a real directory. For example, unix_socket_directories = "@/tmp" means the socket is at "@/tmp/.s.PGSQL.5432" in abstract namespace, and cannot be seen in the filesystem. Connect with the specified path directly: psql -h "@/tmp" -U postgres.

Frequently asked questions

What does "Could not connect to server: No such file or directory" mean?
This error occurs when the PostgreSQL client (psql, libpq, application drivers) attempts to connect to a local PostgreSQL server via Unix domain socket but cannot locate the socket file. 5432. When the client attempts to connect without specifying a host (or with host=localhost on non-Windows systems), it looks for this socket file.
How do I fix "Could not connect to server: No such file or directory"?
PostgreSQL "Could not connect to server: No such file or directory" occurs when the client cannot find the Unix domain socket file needed to connect locally. Common causes include PostgreSQL not running, mismatched socket paths between client and server, permission issues, or leftover postmaster.pid files blocking startup. Fixing requires restarting the server, verifying socket locations, and checking permissions.
What causes "Could not connect to server: No such file or directory"?
PostgreSQL server is not running—the most common cause. The socket file only exists while the server is active. PostgreSQL failed to start cleanly, leaving a stale postmaster.pid file that blocks startup attempts Socket directory does not exist (e.g., /var/run/postgresql was deleted after a reboot)
Is the "Could not connect to server: No such file or directory" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading