My company has a Perl application in server with IP : 10.10.3.39
And because of the new rule implemented, I must migrate the database to MySQL DB in server with IP : 10.10.1.18
My company DB administrator has create an account and grant the access for the apps with username : 'user'#'10.10.3.39'. So the account just can be used from server with IP 10.10.3.39
I tried the connection in the server using command mysql -h 10.10.1.18 -u user -p
[hanief#dev39 project]$ mysql -h 10.10.1.18 -u user -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19484169
Server version: 10.0.15-MariaDB mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
I have a database connection script test_db.pm in Perl like this:
use DBI;
$user = "user";
$pw = 'password';
$dbh = DBI->connect("DBI:mysql:database=mysql;host=10.10.1.18;mysql_enable_utf8=1",$user, $pw, %attr) or die "Cannot connect to MySQL server\n";
And then, I tried to run it using command perl test_db.pm, I got this error
[hanief#dev39 project]$ perl test_db.pm
DBI connect('database=mysql;host=10.10.1.18;port=3306;mysql_enable_utf8=1','user',...)
failed: Access denied for user 'user'#'%' to database 'mysql' at test_db.pm line 6.
Cannot connect to MySQL server
I don't know why the account name suddenly has #'%' behind it
I have tried to change the variable $user to :
$user = "user\#10.10.3.39";
failed: Access denied for user 'user#10.10.3.39'#'10.10.3.39' (using password: YES) at test_db.pm line 6.
$user = "user\#'10.10.3.39'";
failed: Access denied for user 'user#'10.10.3.39''#'10.10.3.39' (using password: YES) at test_db.pm line 6.
$user = "'user'\#'10.10.3.39'";
failed: Access denied for user 'user'#'10.10.3.39'#'10.10.3.39' (using password: YES) at test_db.pm line 6.
But still, didn't work. The server still can't connected to DB server.
I Don't know why there's an extra #'10.10.3.39' behind the user account.
And don't know why % before, suddenly changed to 10.10.3.39
Any solution for my case?
I'm not entirely sure what's going on here, but I think I can shed a little bit of light.
MySQL (and, hence, MariaDB) has a login system that isn't just dependent on usernames and passwords. It also takes into account the host that the connection is coming from. If you look at the mysql.user table, you'll see that the first three columns are Host, User and Password.
The Host column is interesting. It can either contain an IP address or a hostname, but it can also contain the symbol '%', which means "any host".
So when the DBA told you they had:
create an account and grant the access for the apps with username : 'user'#'10.10.3.39'
I'm betting they mean they've inserted the values user and 10.10.3.39 in the mysql.user table.
That means your $user variable needs to be set to user, not user#10.10.3.39 - as MySQL will work out the IP address from your incoming connection.
So when you see errors like this:
failed: Access denied for user 'user#10.10.3.39'#'10.10.3.39'
the bit inside the first pair of quotes ("user#10.10.3.39") is the username you're trying to use and the bit inside the second pair of quotes ("10.10.3.39") is the IP address that MySQL thinks you're connecting from. Obviously, that's not going to work because that username doesn't exist in the mysql.users table.
So, we're left looking at your first example:
$dbh = DBI->connect("DBI:mysql:database=mysql;host=10.10.1.18;mysql_enable_utf8=1",$user, $pw, %attr)
or die "Cannot connect to MySQL server\n";
Which gives this error:
failed: Access denied for user 'user'#'%'
Now, the fact that this error uses "%" as your hostname, seems to imply that the MariaDB server didn't recognise the IP address that you're coming from as one of the specific IP addresses listed as allowed for your user.
So, two things I would double-check in this instance:
Are you definitely trying to connect from 10.10.3.39? This includes checking if there are any proxies between you and the DB server that might change your IP address.
Is the IP address in the mysql.user table really 10.10.3.39? Or does the value, perhaps, contain a typo?
I'm aware that this isn't a "here's the solution to your problem" post but, hopefully, it explains a bit more about what is going on and gives you a couple of avenues to investigate.
Related
I have found many posts for this error, tried everything but still getting same error.I am trying to connect to mysql on ubuntu server from my remote app and mysql client. Let me post whatever steps I have taken already :
Stop the firewall on ubuntu server : iptables -F. Also tried with sudo service ufw stop.
Commented "bind-address" in /etc/mysql/my.cnf and restarted mysql.
Added user in mysql : CREATE USER 'test'#'%' IDENTIFIED BY 'testpwd';
GRANT ALL PRIVILEGES ON . TO 'test'#'%' IDENTIFIED BY 'testpwd' WITH GRANT OPTION;
FLUSH PRIVILEGES;
I can see the entry of new user by "Select host, user from mysql.user";
restarted mysql again. Still the same error!
Now I thought maybe there is some problem still with firewall, so added :iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT
Problem still persist.
"Access denied for user 'test'#'ip'(using password: YES)" is a MySQL error.
This means that at the network level everything is working, because to be denied access as a given user, the server must have understood which user you were trying to connect as. So network, firewall, routing, and so on and so forth, must all be working; the server must be listening, etc..
The problem lies "simply" in the authentication.
Try connecting locally to the database (to override the authentication) and inspect the privilege table:
USE mysql;
SELECT User, Host, Password from user WHERE User = 'test';
and remember that the line you're interested in is the one mentioning the IP (since the error message specifies the IP, and not the host name - in which case, it could have been a DNS problem; the host name is the hostname that the server believes you are coming from, not the hostname you are really coming from).
The user/host matching goes from more specific to less specific. So if you already had:
user host password
test 1.2.3.4 foo
and ran,
GRANT... TO test#'%' ... PASSWORD bar
...this grant would work from everywhere except 1.2.3.4, where the password would remain 'foo'.
From the manual (link above):
The server uses sorting rules that order rows with the most-specific
Host values first. Literal host names and IP addresses are the most
specific. (The specificity of a literal IP address is not affected by
whether it has a netmask, so 192.168.1.13 and
192.168.1.0/255.255.255.0 are considered equally specific.) The pattern '%' means “any host” and is least specific. The empty string
'' also means “any host” but sorts after '%'. Rows with the same Host
value are ordered with the most-specific User values first (a blank
User value means “any user” and is least specific). For rows with
equally-specific Host and User values, the order is indeterminate.
You might be forced to do
USE mysql;
DELETE FROM user WHERE User = 'test';
GRANT ALL PRIVILEGES ON database.* TO 'test'#'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
to ensure that there're no spurious lines in the grant table referring to the user 'test'.
(Also, the GRANT should be, I think,
GRANT ALL PRIVILEGES ON databasename.*
)
Security doubt (unrelated to the answer)
The manual above says: The specificity of a literal IP address is not affected by whether it has a netmask, so 192.168.1.13 and 192.168.1.0/255.255.255.0 are considered equally specific.
Now at a very first glance 127.0.0.1/0.0.0.0 seems very specific (and harmless) for localhost. The netmask, if I'm not mistaken, ensures that it is equivalent to %, except that it is incredibly specific and will run first. Therefore
test bar %
test localfoo 127.0.0.1/0.0.0.0
means that the password for test from anywhere it's not "bar" at all, but it is "localfoo".
No one would insert such a grant by mistake, but there's mistake and mistake.
First let's check - it's network/firewall problem or not.
Start MySql server with --skip-grant-tables , then try to connect to it.
I had the same error on my .net core console app, when trying to connect to my MariaDb database.
I finally find that the uid in my connectionstring was not correct because it is case sensitive!
Even if I felt quite stupid, it might help...
I have installed MYSQL 5.6 stand-alone on a local windows server. Recently, I changed the local IP of my server and reconfigured it in my network, but now I am not able to access my databases. It is giving me this error:
1045 - Access denied for user 'user'#'localhost' (using Password: Yes)
The above error is coming while using localhost as the server name. Also, I am able to connect to localhost through root username, but it is not showing me the original DB's which I had before.
Also before the server IP change I was able to access the MySQL server through the old IP of the server. like host name: xx:xx:xx:xx , user: user, pass: pass .... But it is also giving me an error:
2003 - cannot connect to my sql server on 'xx:xx:xx:xx' (10038)
I have tried the solution define on following link and run following query:
https://dev.mysql.com/doc/mysql-windows-excerpt/5.6/en/resetting-permissions-windows.html
SET PASSWORD FOR 'root'#'%' = PASSWORD('test');
and this is starting giving error of access denied for the root username and password 'test'
Can any body help me to resolve this.
Connect to 127.0.0.1 as root.
Update IP address for mysql user row with old IP address.
use mysql;
update user set host='NEWIP' where host='OLDIP' and user='root';
flush privileges;
Try again to connect.
If you don't have root access, reset permissions and try again.
http://dev.mysql.com/doc/refman/5.7/en/resetting-permissions.html
This is a problem experienced by people who downloaded the recent version (i.e MySQL 5.7.10)
The problem is there is a temporary password for this version
after you typed in bin>mysql -u root -p ...
you have to type in the password which is different for every person who downloaded it. Go to your mysql directory in C (or wherever you extracted it to) , go to the file 'data'. There would be an ERR file with your computer's name on it.
Open that file using notepad
in the 6th line of commands, there would be a line as follows
[Note] A temporary password is generated for root#localhost: '(your password)'
copy that password and paste it in the command prompt ... From there on you can continue as shown in the video
I have the current setup:
SVR01:
Ubuntu Trusty, with Xen
VM01:
IP: 192.168.0.10
Ubuntu Trusty, with Apache2 + php modules
VM02:
IP: 192.168.0.11
Ubuntu Trusty, with mysql server
When I try connecting from VM01 (The apache server) to mysql on VM02, I get the "Access Denied for 'NewUser'#'192.168.0.10' (Using password: YES)" error.
I created the user using:
CREATE USER 'NewUser'#'192.168.0.10' IDENTIFIED BY 'password';
GRANT EXECUTE ON mydb.* TO 'NewUSer'#'192.168.0.10';
But, it will work if I create the user using the host wildcard:
CREATE USER 'NewUser'#'%' IDENTIFIED BY 'password';
GRANT EXECUTE ON mydb.* TO 'NewUSer'#'%';
Does anyone know why it won't work when I specify the host ip?
PS. I get the error when trying to connect either through the Mysql client, or through the PHP PDO.
Follow up questions:
Does the grant seem to work if you create a user with a 192.168.0.% wildcard host mask?
Run select user, host, password from mysql.user where user='NewUser' to ensure there's not another user#host you weren't aware of that might be getting picked up?
Does the Access denied messages in your error logs confirm the failed connection attempts are in fact coming from the IP you think it is? Some weirdness like this might pop up if you have multiple routes setup in a system that has multiple network interfaces or perhaps some VPN routes in the mix.
When attempting connections to VM02 are you using a literal IP address or a hostname? If the later are you sure this is resolving to the IP you think it is from VM01 (you can verify using ping or just the host command from the command line)
Run "show variables like 'init_connect';" on the root account you were creating the users with. If that value is not blank you will want to ensure the accounts of permissions required to execute whatever that value does hold.
Unable to set password for a user using 3.5.2.2 - phpMyAdmin for 5.5.27 - MySQL. When trying to set the password while logged onto phpMyAdmin as the user, it pops up the following error:
#1133 - Can't find any matching row in the user table
When logged on as root, following password set successfully message pops up.
SET PASSWORD FOR 'user'#'%' = PASSWORD( '***' )
In either case, password does not set and stays as it currently is, blank.
I encountered this error using MySQL in a different context (not within phpMyAdmin). GRANT and SET PASSWORD commands failed on a particular existing user, who was listed in the mysql.user table. In my case, it was fixed by running
FLUSH PRIVILEGES;
The documentation for this command says
Reloads the privileges from the grant tables in the mysql database.
The server caches information in memory as a result of GRANT and CREATE USER statements.
This memory is not released by the corresponding REVOKE and DROP USER statements, so for
a server that executes many instances of the statements that cause caching, there will be
an increase in memory use. This cached memory can be freed with FLUSH PRIVILEGES.
Apparently the user table cache had reached an inconsistent state, causing this weird error message. More information is available here.
This error can occur if trying to grant privileges for a non-existing user.
It is not clear to me what MySQL considers a non-existing user. But I suspect MySQL considers a user to exist if it can be found by a name (column User) and a host (column Host) in the user table.
If trying to grant privileges to a user that can be found with his name (column User) but not by his name and host (columns User and Host), and not provide a password, then the error occurs.
For example, the following statement triggers the error:
grant all privileges on mydb.* to myuser#'xxx.xxx.xxx.xxx';
This is because, with no password being specified, MySQL cannot create a new user, and thus tries to find an existing user. But no user with the name myuser and the host xxx.xxx.xxx.xxx can be found in the user table.
Whereas providing a password, allows the statement to be executed successfully:
grant all privileges on mydb.* to myuser#'xxx.xxx.xxx.xxx' identified by 'mypassword';
Make sure to reuse the same password of that user you consider exists, if that new "MySQL user" is the same "application user".
Complete the operation by flushing the privileges:
flush privileges;
I encountered this issue, but in my case the password for the 'phpmyadmin' user did not match the contents of /etc/phpmyadmin/config-db.php
Once I updated the password for the 'phpmyadmin' user the error went away.
These are the steps I took:
Log in to mysql as root: mysql -uroot -pYOUR_ROOT_PASS
Change to the 'mysql' db: use mysql;
Update the password for the 'phpmyadmin' user:
UPDATE mysql.user SET Password=PASSWORD('YOUR_PASS_HERE') WHERE User='phpmyadmin' AND Host='localhost';
Flush privileges: FLUSH PRIVILEGES;
DONE!! It worked for me.
It turns out, the error is very vague indeed!
1) Password was setting while logged on as root, as it was updating the user/password field in the users table under MySql.
2) When logged on as user, password was in fact not changing and even though there was one specified in the users table in MySql, config.inc.php file allowed authentication without password.
Solution:
Change following value to false in the config.inc.php.
$cfg['Servers'][$i]['AllowNoPassword'] = true;
So that it reads
$cfg['Servers'][$i]['AllowNoPassword'] = false;
Change user's host from Any or % to localhost in MySql users table. This could easily be achieved via phpMyAdmin console.
These two changes allowed me to authenticate as user with it's password and disallowed authentication without password.
It also allowed user to change its password while logged on as user.
Seems all permissions and the rest was fixed with these two changes.
To expound on Stephane's answer.
I got this error when I tried to grant remote connections privileges of a particular database to a root user on MySQL server by running the command:
USE database_name;
GRANT ALL PRIVILEGES ON *.* TO 'root'#'%';
This gave an error:
ERROR 1133 (42000): Can't find any matching row in the user table
Here's how I fixed it:
First, confirm that your MySQL server allows for remote connections. Use your preferred text editor to open the MySQL server configuration file:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Scroll down to the bind-address line and ensure that is either commented out or replaced with 0.0.0.0 (to allow all remote connections) or replaced with Ip-Addresses that you want remote connections from.
Once you make the necessary changes, save and exit the configuration file. Apply the changes made to the MySQL config file by restarting the MySQL service:
sudo systemctl restart mysql
Next, log into the MySQL server console on the server it was installed:
mysql -u root -p
Enter your mysql user password
Check the hosts that the user you want has access to already. In my case the user is root:
SELECT host FROM mysql.user WHERE user = "root";
This gave me this output:
+-----------+
| host |
+-----------+
| localhost |
+-----------+
Next, I ran the command below which is similar to the previous one that was throwing errors, but notice that I added a password to it this time:
USE database_name;
GRANT ALL PRIVILEGES ON *.* TO 'root'#'%' IDENTIFIED BY 'my-password';
Note: % grants a user remote access from all hosts on a network. You can specify the Ip-Address of the individual hosts that you want to grant the user access from using the command - GRANT ALL PRIVILEGES ON *.* TO 'root'#'Ip-Address' IDENTIFIED BY 'my-password';
Afterwhich I checked the hosts that the user now has access to. In my case the user is root:
SELECT host FROM mysql.user WHERE user = "root";
This gave me this output:
+-----------+
| host |
+-----------+
| % |
| localhost |
+-----------+
Finally, you can try connecting to the MySQL server from another server using the command:
mysql -u username -h mysql-server-ip-address -p
Where u represents user, h represents mysql-server-ip-address and p represents password. So in my case it was:
mysql -u root -h 34.69.261.158 -p
Enter your mysql user password
You should get this output depending on your MySQL server version:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.31 MySQL Community Server (GPL)
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Resources: How to Allow Remote Connections to MySQL
That's all.
I hope this helps
grant all on newdb.* to newuser#localhost identified by 'password';
For someone who is doing a mistake like me.
I was using command
SET PASSWORD FOR root = 'elephant7'
to update the password for the root user and I was getting the same error. I tried every thing mention above in all the answer but I got no success then after searching a bit I found out the ans,
MySQL account names consist of a user name and a host name. This enables creation of accounts for users with the same name who can connect from different hosts.
on https://dba.stackexchange.com/
and then I used the command
SET PASSWORD FOR 'root'#'localhost'=PASSWORD('mynewpasword');
here 'root'#'localhost' did the trick and the command worked.
Hope this be beneficial for someone.
If you're using PHPMyAdmin you have to be logged in as root to be able to change root password. in user put root than leave password blank than change your password.
In my case I had just renamed the Mysql user which was going to change his password on a gui based db tool (DbVisualizer). The terminal in which I tried to 'SET PASSWORD' did not work(MySQL Error #1133).
However this answer worked for me, even after changing the password the 'SET PASSWORD' command did not work yet.
After closing the terminal and opening new one the command worked very well.
I think the answer is here now : https://bugs.mysql.com/bug.php?id=83822
So, you should write :
GRANT ALL PRIVILEGES ON mydb.* to myuser#'xxx.xxx.xxx.xxx' IDENTIFIED BY 'mypassword';
And i think that could be work :
SET PASSWORD FOR myuser#'xxx.xxx.xxx.xxx' IDENTIFIED BY 'old_password' = PASSWORD('new_password');
I'd been making a web on localhost and when I tried to move it on host it shows me lots of errors. Seems like it can't connect to my local database. Here's the code:
$host = "myip";
$user = "root";
$pass = "";
$db = "mydatabase";
mysql_connect($host, $user, $pass);
mysql_select_db($db);
$on = mysql_fetch_row(mysql_query("SELECT COUNT(online) FROM characters WHERE online=1"));
echo "<br>Online: $on[0]<br><br>";
And here's the output:
Warning: mysql_connect() [function.mysql-connect]: Host 'myip' is not allowed to connect to this MySQL server in * on line 46
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in * on line 48
Online:
Thanks for help
It's a mysql user permission problem. Create a new user with phpmyadmin for example and set it's host to localhost if you connect from localhost, or % if you are connecting from outside.
As Alekc correctly stated, it's a permission problem:
You can do this at the MySQL prompt:
grant all privileges on mydatabase.*
to youruser#'your_ip_address'
identified by 'your_password';
Followed by a:
flush privileges;
And then try to reconnect again. Keep in mind that:
your_ip_adress: it's not the MySQL server's IP address but the IP address you are connecting from (your web server?)
your_password: is the one you must use when establishing the connection on PHP side
Also remember that, even though this solution should work, it's not recommendable granting all privileges to a user that will be used by a web application. You can do the same with fewer permissions.
You can do all this with a nice GUI frontend. I prefer command line.