Error 1130 is a networking error. The server cannot resolve the hostname of the client. Or the host is not allowed to connect to the MySQL server. There are basically 2 categories of possible reasons: In MySQL a user a user is specified using BOTH the user name and the host from where the user may connect. If no user has been created where the host-part (using wildcards or not) mathces the host of the client trying to connect MySQL returns this error. When upgrading to MySQL 5.7.3 from a previous version this may occur due to changes to the user table introduced in 5.7.3. There is a good blog about it, | Newtab2 |
|---|
| alias | Upgrade and Resolving ERROR 1130 Host ‘localhost’ is Not Allowed to Connect |
|---|
| url | http://www.chriscalender.com/5-7-upgrade-and-resolving-error-1130-host-localhost-is-not-allowed-to-connect/ |
|---|
|
.- Your hosts file is damaged or invalid. Various vira and spyware attack and alter the host file in various ways. For instance if the hosts file does not contain the line
127.0.0.1 localhost
'Localhost' can not be resolved as pointing to ip 127.0.0.1. On some larger corporate network it is widely used to "roll out" host files to all clients with symbolic names (like 'mysqlserver', 'mailserver' etc.) for important machines on the network and the corresponding IP's. Check with your admin that you got the right file! If you use the Windows network name as hostname, it may be a network configuration problem. Try using the ip instead. On Unix/Linux systems the hosts files sometimes reads Is a variation of number 3. With a complex server setup (involving more IP's, domains, subdomains and/or virtual hosts) a similar issue can occur. In this situation HTTP-tunneling will normally work for all users, but often/sometimes direct connection and SSH will not work with the 'root' user - everything depending on the server configuration. Try another and 'ordinary' user account. You may mirror the privileges of 'root' to a 'superadmin' user. 127.0.0.1 localhost.localdomain This causes a problem with MySQL. MySQL docs at | Newtab2 |
|---|
| alias | Access Control, Stage 1: Connection Verification |
|---|
| url | https://dev.mysql.com/doc/refman/8.0/en/connection-access.html |
|---|
|
say:A Host value may be a hostname or an IP number, or 'localhost' to indicate the local host.
No mention of 'localhost.localdomain'. This means that MySQL cannot resolve that 'automatically'! This can affect SQLyog when tunneling and SJA for Linux. Workarounds for this include: I: A workaround that has worked is to give the user access from 'localhost.%'
II: You can add localhost to ip 127.0.0.1 in host file like
a. Make sure your '/etc/hosts' file reads as follows:
127.0.0.1 localhost //localhost *MUST* be first (notice separate entries)
127.0.0.1 localhost.localdomain
127.0.0.1 . . .
b. Make sure you reference the local server in the SJA.XML file as:
127.0.0.1 or localhost.localdomain
This is known to work in some situations where the MySQL configuration file contains:
bind-address = 127.0.0.1
III: It has sometimes worked to add a 'dummy' ip to my.cnf like:
bind-address = 10.10.10.10
.. supposed that 10.10.10.x is also the ip of the local machine. Then you use this 'dummy ip' as the host specification when connecting with SQLyog and SJA.
It seems to be something special for some DEBIAN distributions to use this 'bind-address' construction with MySQL. Solution II) and III) both are solutions that users have contributed at our Forums. Both situations involved DEBIAN.
IV: You can try any host name that the host file maps to ip 127.0.0.1. There might be several! Even a SAMBA NetBIOS alias might work!
V: You can use the local ip (ie. 10.0.0.1 or whatever) of the actual machine or a name server alias for this. But in this case normal TCP-connections must be enabled in MySQL configuration - that is 'skip-networking' must be disabled/commented out and no 'bind-address' may be there. Of course then an additional DNS lookup will have to take place for the connection to be established. This is of no practical importance. Finally you could test if this connection issue is the same with 'MySQL Administrator'. It uses the same client code (the C-API) and connects exactly as SQLyog and SJA do.
|