When trying to setup a postgresQL based database for your web development application, there can be times when the user encounters te error: fe_sendauth: no password supplied. One such instance to end up with this error is when a user forgets the root user password set for the database, and hence ends up creating a new user to solve the issue. Now, when they try to run the database, they get a fe_sendauth: no password supplied. This issue can be solved by following the given steps:
Step 1. Find the path of pg_hba.conf file
pg_hba.conf can appear in many other places depending on how postgres was installed. The standard location is pg_hba.conf within the data_directory of the database (which could be in /home, /var/lib/pgsql, /var/lib/postgresql/[version]/, /opt/postgres/, /etc/postgresql/[version]/main/, etc.) but users and packagers can put it wherever they like.
Say the version number for postgreSQL is 8.4, then the probable location of pga_hba.conf can be: /etc/postgresql/8.4/main/pg_hba.conf
here could be multiple files in all the corresponding version directory like:
/etc/postgresql/8.4/main/pg_hba.conf
/etc/postgresql/9.1/main/pg_hba.conf
Hence, to figure the path for the pg_hba.conf file: ASK YOUR DATABASE!
In your terminal, type:
$ psql postgres
# SHOW hba_file;
You will get the path for your pg_hba.conf file
Step 2. Edit the pg_hba.conf file
pg_hba.conf file will be in a format similar to the one shown:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
Host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres md5
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
Here, the first three commented lines must be trust. They are probably written to be as either md5 or peer. Change the words to trust as shown above.
Step 3: Reload the configuration file
The cluster needs to be reloaded to pick up the changes.
In the command line, run: $ sudo service postgresql reload
Now, this should work, in case it doesn’t.. Try if it solves after each step:
From the command line, run: pg_ctl reload
From within a db (as superuser), run: select pg_reload_conf();
From PGAdmin: right-click db name, select "Reload Configuration"
