What it means
A MySQL or MariaDB account is a user name and a host: 'app'@'localhost', 'app'@'10.0.0.%',
'app'@'%'. When a client connects, the server first looks for any account whose host part
matches the client’s address. Error 1130 means there isn’t one, for any user name, so it closes the
connection straight away. Your user name and password haven’t been looked at yet.
The address in the message is the one the server saw. With skip_name_resolve on (the official
Docker images turn it on) it’s an IP address; otherwise it can be a host name. From your Mac to a
server in Docker, it’s the Docker network’s gateway (192.168.215.1 here), not 127.0.0.1.
As soon as some account matches your address, a wrong user or password gets error 1045, access denied instead.
Common causes
- A fresh install where only local accounts exist. Package installs on Linux and macOS create
root@localhost; connecting from another machine, or from your Mac to a VM, has no account to match. - A Docker container started with
MYSQL_ROOT_HOST=localhost(orMARIADB_ROOT_HOST), or a compose file that sets it, so root can only sign in from inside the container. - The application’s account is for a different address: created for
localhostor one IP, and the application now runs on another host, container or network. - The client’s address changed: a new office IP, a VPN, a cloud NAT, or Docker giving containers new addresses.
How to fix it
See which hosts the server has accounts for
Connect locally on the server (through the socket, or docker exec into the container):
SELECT user, host, plugin FROM mysql.user ORDER BY user, host;
user host plugin
mysql.infoschema localhost caching_sha2_password
mysql.session localhost caching_sha2_password
mysql.sys localhost caching_sha2_password
root localhost caching_sha2_password
Here every account is localhost, so any TCP connection from elsewhere gets 1130.
Create an account for the client’s address
Use a dedicated account with only the privileges the application needs, and the narrowest host pattern that works:
CREATE USER 'app'@'192.168.215.%' IDENTIFIED BY '<password>';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app'@'192.168.215.%';
% matches any address, and 192.168.215.% any address starting with those numbers. Opening
root to '%' works too, but it exposes the account with every privilege to the whole network.
Docker
The official images create root@'%' unless MYSQL_ROOT_HOST (or MARIADB_ROOT_HOST) says
otherwise, and create MYSQL_USER for '%'. Those variables are read only when the data volume is
empty, so on an existing volume, create the account with SQL as above:
docker exec -it <container> mysql -uroot -p
Then check the network side
An account is only half of it. If you then get
“Can’t connect to MySQL server”, the server listens
only on 127.0.0.1 (bind_address) or a firewall is in the way.
Reproduce it
In a temporary MySQL 8.4.11 container started with MYSQL_ROOT_HOST=localhost, so root@localhost
was the only account, connecting from another container through the published port:
mysql -h host.docker.internal -P33991 -uroot -p -e 'select 1'
ERROR 1130 (HY000): Host '192.168.215.1' is not allowed to connect to this MySQL server
Any user name gave the same error. Connecting over TCP from inside the container itself gave
Host '127.0.0.1' is not allowed, because with skip_name_resolve on, localhost matches only the
Unix socket. After CREATE USER 'seo_app'@'192.168.215.%', that account signed in
(current_user() was seo_app@192.168.215.%), and root from the same address now got 1045:
ERROR 1045 (28000): Access denied for user 'root'@'192.168.215.1' (using password: YES)
A temporary MariaDB 11.4.13 container with MARIADB_ROOT_HOST=localhost gave the same error, naming
MariaDB:
ERROR 1130 (HY000): Host '192.168.215.1' is not allowed to connect to this MariaDB server
The MariaDB 11.4 client, which tries TLS by default, wrapped it in another error, since the server refused before TLS was set up:
ERROR 2002 (HY000): Received error packet before completion of TLS handshake. The authenticity of the following error cannot be verified: 1130 - Host '192.168.215.1' is not allowed to connect to this MariaDB server
From MariaDB’s own container, a TCP connection to 127.0.0.1 got 1045 instead, because the image
creates healthcheck@127.0.0.1. Both containers were removed afterwards.
In Inlet
When the server refuses the connection, Inlet’s connection window shows its message and links to
this page. If the database only has accounts for local connections and you can reach its host over
SSH, connect through an SSH tunnel (Pro): the server then sees the connection coming from the SSH
server, so an account for that machine (often 127.0.0.1 when the database runs there) is enough.
Inlet runs the system ssh, so your ~/.ssh/config and SSH agent work.