So I have PostgreSQL installed fine, and am trying to run the createdb 'test' command in the Terminal. I am on my normal user account. When trying to create the database, I am asked for a password twice, then I get the error message createdb: error: could not connect to database template1: FATAL: password authentication failed for user "sethmarks". Does this mean I entered the incorrect password or that I do not have permission to create databases under this user? I am getting confused and frustrated by this and would like to know what is going on. I am entering the password I use for the OS user I am currently logged into.
I am able to create a database when I do sudo su - postgres and then create it when I am doing it under the Postgres user, but that is not going to work with my program. Can anybody help me figure this out?
I included a picture of the terminal to show the process and what happens when attempting to create a new db. Thank you very much.
It depends on the privileges that have been granted to your user account and which privileges have been granted to PUBLIC.
You can query some privileges with psql \du meta command for the current user.
In your case you need at least to run as superuser:
grant connect on database template1 to sethmarks;
I don't exactly why password is requested twice: this is not caused by wrong password: I have the same behaviour but I need to give the database user password not the OS user password.
Related
I just installed Firebird for Win64, and I was trying to connect to the employee database which comes pre-packaged with ISQL.
Following the steps from the Firebird official QuickStart Documentation I opened the ISQL utility and entered:
connect localhost:employee user sysdba password masterkey;
As a result I got:
Statement failed, SQLSTATE = 28000
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
Strangest thing is that if I navigate to the employee database sample itself and issue the isql command from there I can successfully connect.
The difference is that connecting directly to a database file doesn't require a password, it will even ignore the password, and just use the provided user to know which privileges to apply.
Without a hostname, ISQL will by default use Firebird embedded mode, and not the server. To compare, try using isql employee.fdb (or isql employee), it will just login with your current OS username, while isql localhost:employee will fail with a 'Your user name and password are not defined'.
It looks like you specified a different password than the default of masterkey, or somehow the sysdba account wasn't initialized. I recall there was a problem with the installer of an earlier Firebird 3 version, but I don't think 3.0.2 should be affected by this (or at least: it worked for me).
If the SYSDBA account wasn't initialized, then follow the steps of the Firebird 3 release notes, section Initializing the Security Database:
Initialization Steps
Initialization is performed in embedded mode using the isql utility.
For an embedded connection, an authentication password is not required
and will be ignored if you provide one. An embedded connection will
work fine with no login credentials and “log you in” using your host
credentials if you omit a user name. However, even though the user
name is not subject to authentication, creating or modifying anything
in the existing security database requires that the user be SYSDBA;
otherwise, isql will throw a privilege error for the CREATE USER
request.
The SQL user management commands will work with any open database.
Because the sample database employee.fdb is present in your
installation and already aliased in databases.conf, it is convenient
to use it for the user management task.
Stop the Firebird server. Firebird 3 caches connections to the security database aggressively. The presence of server connections may
prevent isql from establishing an embedded connection.
In a suitable shell, start an isql interactive session, opening the employee database via its alias:
> isql -user sysdba employee
Create the SYSDBA user:
SQL> create user SYSDBA password 'SomethingCryptic';
SQL> commit;
SQL> quit;
To complete the initialization, start the Firebird server again. Now you will be able to perform a network login to databases,
including the security database, using the password you assigned to
SYSDBA.
Where 'SomethingCryptic', should be your password.
If a SYSDBA user was created, you will need to change its password if you no longer remember what you set. Follow the same steps, but in step 3 do:
SQL> alter user SYSDBA set password '<new password>';
SQL> commit;
SQL> quit;
If this gives an error "record not found for user: SYSDBA", make sure you are really connected as SYSDBA, otherwise retry the original step 3. Not having admin access will behave as if the user doesn't exist, so the error is the same if the user really doesn't exist, or if you are connected with an unprivileged user.
CONNECT 'employee' user 'SYSDBA' password 'masterkey';
You need make sure that your alias.conf have something like this: employee=C:/examplepath/employee.fdb
make sure that the services of firebird is on
I created an admin user with password in pgadmin4:
CREATE USER admin WITH
LOGIN
SUPERUSER
CREATEDB
CREATEROLE
INHERIT
REPLICATION
CONNECTION LIMIT -1
PASSWORD 'xxxxxx';
But I can login to the respective server with the admin user and any wrong password.
I used psql command line to check if the user has been created, and it is.
# SELECT usename FROM pg_user;
usename
------------
postgres
xxxxxxxxxxx
admin
(3 rows)
I checked if I can login with the admin user and a wrong password through psql command line, and it worked...
Am I doing something wrong?
Pgadmin4 v1.1
Postgresql v9.6
Same problem on Centos 6.8 and macOSX 19.12.1
This is speculation, but it's educated speculation, as I encountered a similar issue.
If your pg_hba.conf file, I am pretty confident you have the admin user set up as "trust." This pretty much means it can log in from anywhere you specified, without a password.
If you change this to "md5," it should resolve the issue.
# TYPE DATABASE USER ADDRESS METHOD
host all admin <whatever> trust
change to
host all admin <whatever> md5
Of course some of these fields may be different, depending on how you have the server set up, but you get the idea.
I'm getting ORA-28000: account is locked error during oracle export utility. Issuing the below command:
expdp user/password tables=MY_TABLE directory=TABLE_EXPORT dumpfile=myexport.dmp CONTENT=DATA_ONLY COMPRESSION=ALL
I changed our database user account password and oracle export utility is not working ever since this password change. It locks the user account every time we try to run it.
As all my other jobs are working good with the same username and password, it has nothing to do with wrong username and password in expdp command.
It looks like some configuration or password syncs are required in some database files. Has anyone got any idea of solution to this weird situation?
Does the new password have special characters that could cause the shell script to behave differently?
May be helpful to know the account_status:
select username,account_status from dba_users;
This would tell us if the account is getting locked due to too many failed logins or is someone running "alter user account lock".
It happens due to multiple test connection or login attempts done with wrong parameters (aka user-name or password combinations).
Failure -Test failed: ORA-28000: the account is locked
Now, how to unlock that particular user in Oracle.
A privileged user (system, sysdba, or database administrator) must logon to the standby and unlock the account there.
ALTER USER locked_user_name ACCOUNT UNLOCK;
COMMIT;
I am using C:\Bugzilla>checksetup.pl and it shows me this error message...plz tell me how i connect to mysql with bugzilla....
There was an error connecting to MySQL:
Access denied for user 'bugs'#'localhost' (using password: NO)
This might have several reasons:
MySQL is not running.
MySQL is running, but there is a problem either in the
server configuration or the database access rights. Read the Bugzilla
Guide in the doc directory. The section about database configuration
should help.
Your password for the 'bugs' user, specified in $db_pass, is
incorrect, in './localconfig'.
There is a subtle problem with Perl, DBI, or MySQL. Make
sure all settings in './localconfig' are correct. If all else fails, set
'$db_check' to 0.
You need to grant access to the user bugs from localhost to this database. Try the following, replacing the relevant parameters
GRANT ALL PRIVILEGES ON DATABASENAME.* To 'user'#'localhost' IDENTIFIED BY 'password';
More information about GRANT
I don't know how to create a database into Parallels Plesk Panel, so I tried it going to the PhpMyAdmin creating the database and modifying the admin user password from there, but now the system is showing me the next error:
ERROR: PleskFatalException
Unable to connect to database: saved admin password is incorrect.
0: common_func.php3:150
psaerror(string 'Unable to connect to database: saved admin password is incorrect.')
1: auth.php3:107
ERROR: PleskFatalException
Unable to connect to database: saved admin password is incorrect.
0: common_func.php3:150
psaerror(string 'Unable to connect to database: saved admin password is incorrect.')
1: auth.php3:107
What can I do to fix it?
Try to connect to psa database:
mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
In case you cannot connect, try to update admin user for mysql with this password. After that Plesk should be able to connect with this database.
I also add this problem, for me the above solution didnt work. it appears plesk has been evolving it's password protection (e.g. .psa.shadow is now aes-cbc encrypted)
this kb article worked for me - i'm using plesk 11.09
http://kb.parallels.com/112492
I got myself into this situation when i got a cloud vm instance where i couldnt log into mysql. so i mysqld_safe and updated the admin password to what it was supposed to be, which meant i could log in but I also broke plesk. this kb got plesk back on its feet again
One thing I found; after following these steps I am not able to login to the plesk 'admin' user on the command line, even with the password i specified in the env variable ! so before resetting the admin password as per this kb article, create another mysql user with all privileges. then use the new user so you dont have the problem of sharing a user with plesk
as to why this happens i dont know, i'm interested if someone does. what appears to be happening is that the ch_admin_passwd of psa starts mysql with security disabled, does some operation on the password (obfuscate?, encrypt?, add salt?) and sets that password for the admin user. whatever that interim operation means that while plesk can log into mysql as admin because it's consistent with itself, the cleartext version of the password specified to ch_admin_passwd does not work on the command line with mysql