psql "Connection to Server on Socket Failed: No Such File or Directory": The Fix on Amazon Linux 2023, EC2, RDS and Docker

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory means psql looked for a PostgreSQL server on the same machine, through a socket file, and the file wasn't there. Either no server is running on this machine, or the server you want is somewhere else. Fix it by starting the local server, or by telling psql where the real one is with -h. On Amazon Linux 2023 there's a twist that catches almost everyone: a freshly installed PostgreSQL server won't start at all, because the package doesn't create a database cluster; you have to run sudo postgresql-setup --initdb first. And once it runs, the first connection to -h localhost fails with "Ident authentication failed", because of a default you'll want to change. This page covers each step with the exact messages, plus RDS and PostgreSQL in Docker.

Ethan, a developer, was setting up a small PostgreSQL database on the EC2 server that runs the inventory app for his friend Jake's phone repair shop. He installed it, typed psql, and got this error. Then he started the service, and that failed too.

New to these terms? A socket here is a file that a PostgreSQL server creates on its own machine, so local programs can talk to it without the network. An EC2 server and an RDS database are two different machines, so a socket can never connect them.

What the error means, piece by piece

Here's the full message, as psql 17 prints it on Amazon Linux 2023:

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
	Is the server running locally and accepting connections on that socket?

Read it in three pieces. On socket means psql tried the local route, because you didn't give it a host. /var/run/postgresql/.s.PGSQL.5432 is the file it looked for, and the number at the end is the port: ask for port 15499, and it looks for .s.PGSQL.15499. No such file or directory means no server has created that file, which nearly always means no server is running here. Other builds use other folders; with Homebrew on a Mac, for example, you'll see /tmp/.s.PGSQL.5432, which is the same problem in a different place.

Here's what produces it, and the fix for each:

The RDS mistake: no -h means "this machine"

On an EC2 server with only the PostgreSQL client installed, this is what you get when you forget the host:

psql -U postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
	Is the server running locally and accepting connections on that socket?

Without -h, psql assumes the server is on the machine you're typing on. To reach RDS, give the endpoint from the database's page in the RDS console, and the database name:

psql -h shop-db.c1abcdexample.us-east-1.rds.amazonaws.com -U postgres -d postgres

If that fails differently, with a timeout, the client is now knocking on the right door, and the problem is the network between the two: the security group or the route. Our RDS connection guide covers that, and if the message mentions pg_hba.conf and encryption, see our fix for that one.

Jake: "So psql was checking this computer for a database that lives somewhere else?"

Ethan: "Exactly. No address, so it checked at home."

Install PostgreSQL on Amazon Linux 2023: client or server

If psql says command not found, nothing is installed yet. Amazon Linux 2023 ships several major versions side by side, each split into a client package and a server package:

dnf list --available "postgresql*" | grep -E "^postgresql[0-9]+(-server)?\."

postgresql15.x86_64                    15.19-1.amzn2023.0.1          amazonlinux
postgresql15-server.x86_64             15.19-1.amzn2023.0.1          amazonlinux
postgresql16.x86_64                    16.15-1.amzn2023.0.1          amazonlinux
postgresql16-server.x86_64             16.15-1.amzn2023.0.1          amazonlinux
postgresql17.x86_64                    17.11-1.amzn2023.0.1          amazonlinux
postgresql17-server.x86_64             17.11-1.amzn2023.0.1          amazonlinux
postgresql18.x86_64                    18.6-1.amzn2023.0.1           amazonlinux
postgresql18-server.x86_64             18.6-1.amzn2023.0.1           amazonlinux

Pick based on what you're doing:

1. Connecting to RDS only: install just the client, in the same major version as your RDS database, for example sudo dnf install -y postgresql17. A matching version keeps tools like pg_dump working against it.
2. Running the database on this server: install the server too, sudo dnf install -y postgresql17-server, which brings the client with it.
3. Check what you have: psql --version prints the client version, for example psql (PostgreSQL) 17.11.

If you only installed the client, the socket error is expected forever: there's no server on this machine to create the file. Use -h.

The Amazon Linux 2023 surprise: the server won't start until you initialize it

Here's what Ethan saw next. He installed postgresql17-server and started it the way you'd start anything:

sudo systemctl start postgresql

Job for postgresql.service failed because the control process exited with error code.
See "systemctl status postgresql.service" and "journalctl -xeu postgresql.service" for details.

The journal says why, in plain words:

sudo journalctl -u postgresql -n 8 -o cat

Starting postgresql.service - PostgreSQL database server...
Directory "/var/lib/pgsql/data" is missing or empty.
Use "/usr/bin/postgresql-setup --initdb"
to initialize the database cluster.
See /usr/share/doc/postgresql17/README.rpm-dist for more information.
postgresql.service: Control process exited, code=exited, status=1/FAILURE
postgresql.service: Failed with result 'exit-code'.
Failed to start postgresql.service - PostgreSQL database server.

The package installs the programs but not the database files themselves, the "cluster" in PostgreSQL's words. Create it once, then start the service and make it start at every boot:

sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql
systemctl is-active postgresql

 * Initializing database in '/var/lib/pgsql/data'
 * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql.service → /usr/lib/systemd/system/postgresql.service.
active

Now the socket exists, in both /var/run/postgresql and /tmp, which is this build's setting for unix_socket_directories. Run --initdb only once. A second run stops with ERROR: Data directory /var/lib/pgsql/data is not empty! and changes nothing, which protects your data from an accidental wipe.

Jake: "So installing it wasn't enough?"

Ethan: "Installing gave me the kitchen. I still had to build the pantry before anyone could cook."

The next three errors, and what each one wants

With the server running, typing psql as ec2-user still fails, just with a different message. That's progress: the socket problem is gone, and these are about who you are. You'll likely see all three in a row:

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "ec2-user" does not exist

With no -U, psql signs in as your Linux user name, and a new server only knows postgres. So you try that, and get:

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "postgres"

"Peer" means the server checks your Linux identity: only the Linux user postgres may sign in as the database user postgres through the socket. So become that user for admin work, and create a role and a database for yourself:

sudo -u postgres createuser ec2-user
sudo -u postgres createdb -O ec2-user ec2-user
psql -tAc "SELECT current_user, current_database()"

ec2-user|ec2-user

The second command answers the third error, FATAL: database "ec2-user" does not exist, because psql also opens a database named after you unless you pass -d. For a one-off admin session, sudo -u postgres psql is enough.

"Ident authentication failed" on localhost: change one word

Your app won't sign in through the socket as a Linux user; it connects over the network with a name and password. On Amazon Linux 2023, that fails out of the box, even with the right password:

PGPASSWORD=App-pass-123 psql -h localhost -U app -d shop -c "SELECT 1"

psql: error: connection to server at "localhost" (::1), port 5432 failed: FATAL:  Ident authentication failed for user "app"

The rules for who may sign in, and how, live in /var/lib/pgsql/data/pg_hba.conf. On a new AL2023 cluster, network connections from this machine use ident, which asks an identity service that a standard server doesn't run, so it fails every time. These are the methods you'll meet in that file:

Change ident to scram-sha-256 on the two host all all lines, then reload, which applies the change without restarting the server:

sudo sed -i -E "s/^(host\s+all\s+all\s+\S+\s+)ident/\1scram-sha-256/" /var/lib/pgsql/data/pg_hba.conf
sudo grep -E "^host" /var/lib/pgsql/data/pg_hba.conf
sudo systemctl reload postgresql

host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256
host    replication     all             127.0.0.1/32            ident
host    replication     all             ::1/128                 ident

The same connection now works. The role needs a password set with CREATE ROLE app LOGIN PASSWORD '...' or ALTER ROLE; PostgreSQL 17 stores it as scram-sha-256 by default. If you see "password authentication failed" instead, the method is right and the password isn't: it's wrong, or the role has none set.

Jake: "Why does it ship with a lock nobody has the key for?"

Ethan: "It ships locked so nothing gets in by accident. You pick the lock you want."

A server that won't start: where the error is

If the service fails after you've changed postgresql.conf, the socket error comes back, because the server never got far enough to create the file. On Amazon Linux 2023, the reason goes to the journal, not to the log folder:

sudo journalctl -u postgresql -n 20 -o cat | grep -B1 FATAL

2026-10-14 00:07:11.107 UTC [588] LOG:  invalid value for parameter "shared_buffers": "notanumber"
2026-10-14 00:07:11.107 UTC [588] FATAL:  configuration file "/var/lib/pgsql/data/postgresql.conf" contains errors

The FATAL line says the server gave up, and the line just above it names the setting; fix it and start the service again. Once the server is running, its everyday messages go to /var/lib/pgsql/data/log/, one file per weekday, such as postgresql-Wed.log, which is where you look for slow queries and failed sign-ins later.

PostgreSQL in Docker: localhost works here

When PostgreSQL runs in a container with its port published, the socket is inside the container, so a psql on the host without -h fails. Notice the port in the file name:

psql -p 15499 -U postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.15499" failed: No such file or directory
	Is the server running locally and accepting connections on that socket?

Add a host, and psql uses the network instead:

psql -h localhost -p 15499 -U postgres -tAc "SHOW server_version"

17.11 (Debian 17.11-1.pgdg13+2)

That's a real difference from MySQL, where -h localhost still means the socket. For psql, any host name, including localhost, means TCP; only no host at all, or a folder path such as -h /tmp, means a socket.

Work through it in order

The socket error has a handful of causes, and the order you check them in saves you from fixing things that aren't broken. Most people reinstall PostgreSQL when the server was on RDS all along, or restart a service that was never initialized. Each step below rules out a whole row of the table at the top, so you can stop as soon as one matches your situation:

1. Decide where the database runs: this machine, a container, or RDS.
2. RDS or another server: add -h with the endpoint and -d with the database.
3. A container: add -h localhost and the published port.
4. This machine, new install: sudo postgresql-setup --initdb, then sudo systemctl enable --now postgresql.
5. This machine, stopped or failing: systemctl is-active postgresql, and read the journal if it fails.
6. Connected but refused: create your role and database, and switch ident to scram-sha-256 for apps.

If you're running the database on EC2 to save money, compare it with RDS before you commit; a managed database handles the backups and updates you'd otherwise do by hand. Either way, keep the app's password out of its code with AWS Secrets Manager.

Troubleshooting by symptom

Socket error on an EC2 server, database is on RDS

You left out -h. Run psql -h with the RDS endpoint, plus -U and -d.

systemctl start postgresql fails on a new install

The cluster doesn't exist yet. Run sudo postgresql-setup --initdb, then start it.

FATAL: role "ec2-user" does not exist

psql signs in as your Linux user. Run sudo -u postgres createuser ec2-user, or pass -U.

FATAL: Peer authentication failed for user "postgres"

Only the Linux user postgres may use that role over the socket. Use sudo -u postgres psql.

FATAL: Ident authentication failed for user

pg_hba.conf uses ident for localhost. Change it to scram-sha-256 and reload.

Socket file name ends in a different number

That number is the port. Check -p, or the PGPORT variable, against the server's port.

psql socket error: frequently asked questions

Ethan ran --initdb, switched the two lines to scram-sha-256, and the inventory app connected on its first try. Jake asked whether the database would survive a reboot. Ethan rebooted the server to show him, and systemctl is-active postgresql said active. Jake's summary: "So the error meant 'nobody's home', and the fix was building the home first."

Revision note. Written October 14, 2026, for PostgreSQL 15 to 18 on Amazon Linux 2023, Amazon RDS and Docker. "Well begun is half done," says the old proverb; with PostgreSQL on AL2023, the beginning is one --initdb.