version: '2'
services:
    image: 'mysql:5.7'
    volumes:
       - '~/dev/dbs-data/mysql:/var/lib/mysql'
    restart: 'always'
    expose:
      - '3306'
    ports:
      - '3306:3306'
    environment:
       MYSQL_ROOT_PASSWORD: 'pass'
       MYSQL_DATABASE: 'db'
       MYSQL_USER: 'user'
       MYSQL_PASSWORD: 'pass'
The problem is that, in my Mac it works, but in my Linux I get the error above.
Should I do some other configuration for my linux?
          
Same here. The problem suddenly appears today on a new container 5.7.17. all previous containers with the same image are fine (sounds impossible, I know).
Still investigating how it changed from working to not working from one day to the next.
  ck196, Bajdzis, ihor-sakayliuk, AddoSolutions, KristianI, hiroshi-asakawa-LITALICO, JoseCage, michaelsanford, afreuDev, brandon-welsch, and 7 more reacted with thumbs up emoji
  bitte-ein-byte reacted with thumbs down emoji
  Bajdzis, danielmoa, hiroshi-asakawa-LITALICO, Neobii, mogaveeravijaya, and neffar reacted with hooray emoji
    All reactions
  lucile-sticky, bfarayev, gneutzling, jdavidzapatab, patonz, codingbycoding, merianos, manjunath-ananthu, jianglin-wu, dtelaroli, and 72 more reacted with thumbs up emoji
  gstvr, bowringjb, Krocsky, danakt, miguelch96, stopsopa, tutuca, kylemarino22, ihor-sakayliuk, linevych, and 157 more reacted with thumbs down emoji
  merianos, aaronlifton, mauleyzaola, ntvinhit, ahmed-metwaly, CyberAP, Teekaram, hiroshi-asakawa-LITALICO, helpermethod, matass, and 5 more reacted with laugh emoji
  marcospgp, GF-Huang, glebovdev, sookcha, leifniem, aigc-in-all, amin3536, newerton, arisros, matass, and 27 more reacted with confused emoji
  proteus1121, chbbk, hiroshi-asakawa-LITALICO, devozanges, ravi100, piotrowskialek, cajytam, douglasmoraisdev, maksha, tharseken, and 4 more reacted with heart emoji
  sutija, magentinos, and developeremi reacted with rocket emoji
  boay24, mahsa-ghazi, artifaqiq, and overflood reacted with eyes emoji
    All reactions
          
Can you check the user,host columns in your mysql.user table to make sure the user isn't limited in some way.

And also run from the container (or with exec)

mysqld --verbose --help | grep bind-address

To check that the server will allow external connections
  lucile-sticky, agn-7, capdragon, websysforever, brandon-welsch, TonyWang666, Jeontaeyun, and asher-lab reacted with thumbs up emoji
  mariomenjr and brandon-welsch reacted with eyes emoji
    All reactions
          
@s1dekick223
Check if the database user exists and can connect
In MySQL, each database user is defined with IP address in it, so you can have for example a root user allowed to connect from localhost (127.0.0.1) but not from other IP addresses. With a container, you never access to the database from 127.0.0.1, it could explain the problem.
To check it, you can do the following:
1* From a terminal, connect you to your MySQL running container
docker exec -it your_container_name_or_id bash
2* In your container, connect you to the MySQL database
mysql -u your_user -p
It will ask you your password, you have to write it and press enter.
3* In your MySQL database, execute this SQL script to list all existing database users
SELECT host, user FROM mysql.user;
It will display a table, for example like this:
+------------+------------------+
| host       | user             |
+------------+------------------+
| %          | root             |
| 127.0.0.1  | root             |
| ::1        | root             |
| localhost  | mysql.sys        |
| localhost  | root             |
| localhost  | sonar            |
+------------+------------------+
It has to contain a line with your database user and '%' to works (% means "every IP addresses are allowed"). Example:
+------------+------------------+
| host       | user             |
+------------+------------------+
| %          | root             |
+------------+------------------+
My root user can connect itself from any IP addresses.
Are external connections allowed?
After that, like @ltangvald said, it could be a problem of allowing external connections to the container.
To check it, you can do the following:
1* From a terminal, connect you to your MySQL running container
docker exec -it your_container_name_or_id bash
2* In your container, run this command
mysqld --verbose --help | grep bind-address
It will display address to bind to, for example like this:
  --bind-address=name IP address to bind to.
bind-address                                                 0.0.0.0
The bind address have to be 0.0.0.0 (which means "every IP addresses") to work.
Also, a note:
Using docker-compose, if you link a volume, the parameters
    environment:
       MYSQL_ROOT_PASSWORD: 'pass'
       MYSQL_DATABASE: 'db'
       MYSQL_USER: 'user'
       MYSQL_PASSWORD: 'pass'
in your docker-compose.yml will not be used, so default user will not be created: you have to create it manually or remove the volume declaration.
  sajadghawami, Chenzilla, aland, lvscar, nicholasodonnell, kinddevil, zhxzhxustc, jjanczyszyn, Ragazzo, grovina, and 254 more reacted with thumbs up emoji
  alwynpan, stephanelpaul, lebigsquare, notconfusing, zZENiro, abir-abdelli, jlk, and iMonZ reacted with thumbs down emoji
  zw896, JJonesAtAvaya, tomredman, amit-k-yadav, Holldike, rezanm2, tiloreboucas, eduardolfalcao, ruimartinsptl, KanagawaMarcos, and 5 more reacted with hooray emoji
  alex-rn, matiramos, Mavlyan, elbuilio, lebigsquare, unixs, A-Yamout, ITCSsDeveloper, juniorsdj, Jeontaeyun, and 3 more reacted with confused emoji
  rohithraX, zw896, cyorobert, reotra224, tomredman, Yiidiir, hiroshi-asakawa-LITALICO, dmhendricks, synchro--, atmdevnet, and 24 more reacted with heart emoji
  KanagawaMarcos, nd-brown, ivorytoast, maqtay, Jeontaeyun, pkiop, adabaed, kmcelwee, and sotdan reacted with rocket emoji
    All reactions
Using docker-compose, if you link a volume, the parameters
   environment:
      MYSQL_ROOT_PASSWORD: 'pass'
      MYSQL_DATABASE: 'db'
      MYSQL_USER: 'user'
      MYSQL_PASSWORD: 'pass'
in your docker-compose.yml will not be used, so default user will not be created: you have to create it manually or remove the volume declaration.
This is not quite accurate. They will be used if the database files do not exist in the folder.  If it is a folder from a previous run of mysql, either from another container or an install from the host machine (ensure neither is running), then the initialization step will be skipped and these environment variables have no effect.
If there is no important data in the files, you can always docker-compose rm -fv; sudo rm -rf ~/dev/dbs-data/mysql/* and then docker-compose up -d.




    

  lucile-sticky, Chenzilla, nicholasodonnell, geerlingguy, dailing, horrorin, dmitrym0, hmamman, mortensassi, FoGhost, and 72 more reacted with thumbs up emoji
  bad-mushroom and akostyanika reacted with hooray emoji
    All reactions
          
I have today this problem, but it was my mistake.
I copying docker-compose.yml and related volumes directories (where logs and database settings stored) from one old project to another new project. And run docker-compose up -d
So i have, in result, mysql's service image builted from cache, with database settings from original project. No environments were applied, @yosifkit make exact definition of situation.
Simply delete from volume's directory all old mysql data, rebuild image - and all works fine.
  rmorrise, IMJacky, Glavin001, imrankhan17, anasanzari, christiankiller, helpermethod, JJonesAtAvaya, anuragteapot, seesiva, and 25 more reacted with thumbs up emoji
  alkhachatryan reacted with hooray emoji
    All reactions
          
@LordRahl90 to change the bind-address option, you have to:
find your mysql configuration file (maybe you already customize it for your container)
under the section [mysqld], add bind-address=0.0.0.0
Example:

In my case, I create my own mysqld.cnf file:
[mysqld]
pid-file	            = /var/run/mysqld/mysqld.pid
socket		            = /var/run/mysqld/mysqld.sock
# Where the database files are stored inside the container
datadir		            = /var/lib/mysql
# My application special configuration
max_allowed_packet          = 32M
sql-mode                    = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'
# Accept connections from any IP address
bind-address	            = 0.0.0.0
Then in my Dockerfile, I tell to Docker to copy it inside the container:
FROM mysql:5.6
MAINTAINER lucile-sticky "aaa@bbb.ccc"
# Setup the custom configuration
ADD mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf
So when MySQL starts, it uses my special configuration instead of the default one.
  mike-sino, casamia918, continuous1024, gfauth, codeybear, aderbique, davidkokkelink, oscarnevarezleal, krearthur, helpermethod, and 20 more reacted with thumbs up emoji
  barath1997, KanagawaMarcos, and HanMufu reacted with heart emoji
    All reactions
          
For me, I hit the same issue once I switched the volume to a path local on my computer, then went through a docker-compose down and docker-compose up -d cycle. After clearing out the files in that directory, the next docker-compose up -d created things fresh, and it worked fine.
I didn't have this problem when using a data volume (volumes: ['db_data:/var/lib/mysql']).
          
You can also copy the my.cnf file

docker cp mysql_mysql_1:/etc/my.cnf conf/
And then include a volume mapping exclusively to your file.
volumes:
    - './conf/my.cnf:/etc/my.cnf'
So you can add bind-address=0.0.0.0 to your my.cnf file.
Anyway, I've done this, but still cannot connect from outside.
  vgjenks, servatj, rus-ik, GF-Huang, helpermethod, furkanpur, Gompali, matiramos, HueHung, brandon-welsch, and 19 more reacted with thumbs down emoji
  fsmaiorano, aaronjamt, and aydek reacted with heart emoji
    All reactions
          
I think I know the issue. When using docker-compose, a new network is created with a different subnet, leading to a new gateway and ip address. By default, mysql will use 172.17.0.1 as a gateway for communication - which is normally the value on the 'bridge' network (you can view this using docker inspect bridge and docker inspect <your instance name or ID>). To view available networks, you can use docker network ls.
A new root host needs to be specified to allow specified IPs to connect if you're going to use docker-compose the way you have it, but you will also need to know what your new subnet will be. In docker-compose version 3, you lose the ability to specify your own gateway for a new network - I'm guessing the gateway will always be x.x.x.1. However, you do have the ability to specify the subnet for the new network (this video does a good enough job to helping you understand subnetting assuming you already know a bit of binary math).
Documentation doesn't seem to be updated or at least I was unable to use "bridge", so what I did was create a new network.

[edit] After reading the error, it seems like you can only re-use user defined networks.
Here's my docker-compose.yml file
version: '3'
services:
  mysql:
    image: mysql/mysql-server:5.7
    env_file: #Use environment variables from file.
      - mysql.env
    volumes:
      - ./data:/var/lib/mysql
    ports:
      - 3306:3306
    environment:
      ## Use % to allow remote access to all addresses. 
      ## Generally not recommended by some people to allow for root.
      #- MYSQL_ROOT_HOST=% 
      # This allows ip ranges from 192.168.0.49 to 192.168.0.54 to connect to root
      - MYSQL_ROOT_HOST=192.168.0.48/255.255.255.248
    networks:
      network:
        ipv4_address: 172.20.0.2
networks:
  network: #will be prefixed with 'parent_dir_name_' so for me, it will be 'mysql_network'
    ipam:
      config:
        - subnet: 172.20.0.0/16
Currently looking into other ways and learning more about networking and docker.
Using the compose file above, to connect to the database, you'll need to use the IP of the machine that the container is being hosted on, rather than the IP of the container; so localhost won't work unless a user with host 172.20.0.1 is created - and localhost won't work on a different machine because 127.0.0.1 is loopback. For example, if the machine that's running the mysql container is using 192.168.1.25 on my network, that will be the IP entered to access my database.
  dev-silverleap, TruongDungkyo, cleverUtd, thiagopecanha, alingse, kevinquillen, LazyFury, cezarmezzalira, radicand, mostafa8026, and zerzavot reacted with thumbs up emoji
  bra-fsn, olegkamuz, loiphong1996, kamal2222ahmed, watcharap0n9, dev-silverleap, and jeliasson reacted with heart emoji
    All reactions
          
@lucile-sticky I am having this in my mysql.user table.

| host      | user          |

+-----------+---------------+

| localhost | mysql.session |

| localhost | mysql.sys     |

| localhost | root          |

+-----------+---------------+

and I am getting the same error ""Host '172.22.0.1' is not allowed to connect to this mysql server". Suggest some way to resolve the issue.
          
Hi @meenakshik-optimus,
Create new user with host '%' rather than localhost. Below is works for me. It may useful to you.

mysql> CREATE USER 'usernameall'@'%' IDENTIFIED BY 'ThePassword';

mysql> grant all on *.* to 'usernameall'@'%';
  efernandes-dev-ops, Dmthakkar, subhashb, SqrTT, KeiraX, niloct, AndersonFirmino, van-ibm, miguelch96, NunuM, and 97 more reacted with thumbs up emoji
  michaelsanford, shrikantrshelke, welljs, Henrique82g, and jonatasoc reacted with thumbs down emoji
  miguelch96, vladislavzakharzhevskii, elhardoum, itReverie, tomijuarez, andriibuda, sovietspy2, mhandria, lam-man, abiezerm, and 18 more reacted with hooray emoji
  lam-man, zinthose, loooping-old, lucianoprea, LucasGalvaoNunes, nuqz, Nafarbelal, codingCoffee, kassioschaider, Mikkou, and 18 more reacted with heart emoji
    All reactions
          
I am experiencing the same issue with 5.7.19
Did a quick test:

I ran 2 containers; the first with 5.6.34 and the second with 5.7.19 & listed the users on the mysql.user table on both of them (jfr: ran the first, stopped it and then ran the second).

While on 5.6.34 there is an entry for 'root' on '%', it is not the case with 5.6.34.

It looks like the "culprit" might be either mysql 5.7 (as a new default for user root maybe?) or the bootstraping process on the docker image mysql:5.7
5.6.34 mysql.user table:
> select Host, User from user \G
*************************** 1. row ***************************
                  Host: %
                  User: root
5.7.19 mysql.user table:
*************************** 1. row ***************************
                  Host: localhost
                  User: root
*************************** 2. row ***************************
                  Host: 127.0.0.1
                  User: root
Here is the docker-compose definition I used for the 5.6.34 service:
 api-db:
     image: mysql:5.6.34
     volumes:
       - ./devel-api-db:/var/lib/mysql:rw
     environment:
       - MYSQL_ROOT_PASSWORD=root
       - MYSQL_DATABASE=app1
       - MYSQL_USER=super-secret-pwd
       - MYSQL_PASSWORD=devel
       - MYSQL_ROOT_HOST=127.0.0.1
     ports:
       - "3307:3306"
Here is the docker-compose definition for the 5.7.19 service:
 api-db:
     image: mysql:5.7.19
     volumes:
       - ./devel-api-db:/var/lib/mysql:rw
     environment:
       - MYSQL_ROOT_PASSWORD=root
       - MYSQL_DATABASE=app1
       - MYSQL_USER=super-secret-pwd
       - MYSQL_PASSWORD=devel
       - MYSQL_ROOT_HOST=127.0.0.1
     ports:
       - "3307:3306"
          
I ran into this symptom for a different reason. For posterity:
My project is set up to run containers with docker-compose and our custom services have user: ${UID}. At some point while debugging, I ran the db service (which just uses the mysql:5.7 image) as root -- without running export UID in my shell beforehand. That caused its volume to have the wrong permissions. So the fix for me was to remove all volumes (docker volume rm $(docker volume ls -q)) and then either (a) run my default project scripts, which take care of publishing UID, or (b) export UID in my shell and then run one-offs like docker-compose run db or docker-compose run db-migration.




    

My `docker-compose.yaml' contained:
services:
    image: mysql:5.7
    env_file:
      - db/vars.env
    volumes:
      - db:/var/lib/mysql
  db-migration:
    depends_on:
    user: ${UID}
    build:
In my case, bind-address was * instead of 0.0.0.0, and that was fine; and I didn't see any difference between mysql:5.7 (which uses 5.7.20 currently) and the previous 5.7.19. And none of the issues seemed to be with images/containers, just with the volumes' permissions; I can deterministically recreate the issue by changing whether I export UID and deleting/recreating volumes, without changing images. The volume permission issue led to db setup failing (so the root user wasn't configured correctly even though mysqld started).
          
I think this is probably as solved as it's going to be (and is turning into a dumping ground for other folks' connection issues).  I'm going to close since there's nothing to be changed in the image (as far as I can tell -- would love to see a PR if that's not correct ❤️).
In the future, these sorts of questions/requests would be more appropriately posted to the Docker Community Forums, the Docker Community Slack, or Stack Overflow.  Thanks! 👍
          
my solution with mysql 5.7.x
docker run -p 3306:3306 --name mysql2 -e MYSQL_ROOT_PASSWORD=b3RmELKOvCUrAdxIg0GEmugc3SY -e MYSQL_ROOT_HOST=% -d mysql/mysql-server:latest
MySQLWorkbench config
Hostname: 0.0.0.0
Port: 3306
Username: root
Password: b3RmELKOvCUrAdxIg0GEmugc3SY  [mysql  random secret]
nodejs mysql
var mysql      = require('mysql');
var connection = mysql.createConnection({
  host     : '0.0.0.0',
  port     : 3306,
  user     : 'root',
  password : 'b3RmELKOvCUrAdxIg0GEmugc3SY',
  database : 'mysql'
connection.connect();
connection.query('SELECT 1 + 1 AS solution', function (error, results, fields) {
  if (error) throw error;
  console.log('The solution is: ', results[0].solution);
connection.end();
  morellana88, wired00, xafardero, itainortecview, tomas-schmidt, liyuanhust, pawel-ochrymowicz, erikmd, lucasnvd, lucianmachado, and 27 more reacted with thumbs up emoji
  wired00, lightecoder, richerald, j1i-ian, sesteva, jetchegoyen, abhishekbhakat, mehuled, and gdois reacted with hooray emoji
  hynospt, rkatsala, lightecoder, richerald, j1i-ian, jetchegoyen, abhishekbhakat, mehuled, and gdois reacted with heart emoji
    All reactions
          
Stupid issue for me ...it was not working because I've explicitly set  MYSQL_RANDOM_ROOT_PASSWORD=no
Complely removing the key/value now works (it uses the MYSQL_ROOT_PASSWORD value)
          
Any ideas why this would be happening?: I have an install script which installs both Laradock and my Larvel application. I use this install script successfully within a Virtualbox VM - Ubuntu 16.04 without any issues at all. Every thing comes up and MySQL migrates no problem. I then install the exact same Ubuntu 16.04 OS on my same machine. This time, not as a VM but as the native OS. I run the exact same script, under the same Ubuntu OS with no modifications at all and I get the dreaded MySQL: "SQLSTATE[HY000] [1130] Host '172.20.0.3' is not allowed to connect to this

MySQL server" during migration. Why would 2 identical systems react this way? Everything is exactly the same and I have repeated this problem 3 times so far.
          
In my case It works only when the container is run second time. That's because the mysql service is restarted after first failure. So mysql loads with new config my.cnf with bind-address set to 0.0.0.0. How can this be fixed?
version: '3.3'
services:
  mysql:
    container_name: affility-mysql
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'root'
      MYSQL_DATABASE: 'wellness_db'
      MYSQL_USER: 'someuser'
      MYSQL_PASSWORD: 'somepassword'
    ports:
      - '3306:3306'
    expose:
      - '3306'
    volumes:
      - mysqldb-data:/var/lib/mysql
      - './mysql/my.cnf:/etc/mysql/my.cnf'
volumes:
  affility-datavolume:
In my case It works only when the container is run second time. That's because the mysql service is restarted after first failure. So mysql loads with new config my.cnf with bind-address set to 0.0.0.0. How can this be fixed?
version: '3.3'
services:
  mysql:
    container_name: affility-mysql
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'root'
      MYSQL_DATABASE: 'wellness_db'
      MYSQL_USER: 'someuser'
      MYSQL_PASSWORD: 'somepassword'
    ports:
      - '3306:3306'
    expose:
      - '3306'
    volumes:
      - mysqldb-data:/var/lib/mysql
      - './mysql/my.cnf:/etc/mysql/my.cnf'
volumes:
  affility-datavolume:
Look to my answer above.
@felipemeddeiros

I did that and that's how I created the my.cnf file. I only have the default my.cnf along with bind-address set to 0.0.0.0, and it sometimes work and sometimes doesn't work. I logged into the container and found this..
[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
secure-file-priv= NULL
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Custom config should go here
!includedir /etc/mysql/conf.d/
bind-address=0.0.0.0
Which means that my changes are being written there. But it works only when I restart the cotainer, as I'm not restarting the mysql service in the container somehow. Some other times it shows the same old message and my app reports Error: ER_HOST_NOT_PRIVILEGED: Host '172.18.0.3' is not allowed to connect to this MySQL server that I figured because the environment variables are being overlooked while building the container because of the volume declaration.
      MYSQL_ROOT_PASSWORD: 'root'
      MYSQL_DATABASE: 'wellness_db'
      MYSQL_USER: 'someuser'
      MYSQL_PASSWORD: 'somepassword'
...and I can't login into the container mysql as root using password root, no database named wellness_db or user someuser.
Database changed
mysql> select host, user from user;
+-----------+------------------+
| host      | user             |
+-----------+------------------+
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
4 rows in set (0.00 sec)
@felipemeddeiros

I did that and that's how I created the my.cnf file. I only have the default my.cnf along with bind-address set to 0.0.0.0, and it sometimes work and sometimes doesn't work. I logged into the container and found this..
[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
secure-file-priv= NULL
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Custom config should go here
!includedir /etc/mysql/conf.d/
bind-address=0.0.0.0
Which means that my changes are being written there. But it works only when I restart the cotainer, as I'm not restarting the mysql service in the container somehow. Some other times it shows the same old message and my app reports Error: ER_HOST_NOT_PRIVILEGED: Host '172.18.0.3' is not allowed to connect to this MySQL server that I figured because the environment variables are being overlooked while building the container because of the volume declaration.
      MYSQL_ROOT_PASSWORD: 'root'
      MYSQL_DATABASE: 'wellness_db'
      MYSQL_USER: 'someuser'
      MYSQL_PASSWORD: 'somepassword'
...and I can't login into the container mysql as root using password root, no database named wellness_db or user someuser.
Database changed
mysql> select host, user from user;
+-----------+------------------+
| host      | user             |
+-----------+------------------+
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
4 rows in set (0.00 sec)
Did you update your mysql version?
Did you update your mysql version?
Yes, image: mysql:8.0. Actually I have never been using 5.7.
As I said you didn't see my answer properly on staskoverflow. Use 8.0.20 version. I was facing the same problem with 8.0 version.
docker run --name mysql1 -e MYSQL_ROOT_HOST=% -e MYSQL_ROOT_PASSWORD=your_password -p 3306:3306 -d mysql:latest
worked and without need to create user / set grant.
This might solve the problem, but won’t it create security risk?
          
Yes -- that will expose your MySQL instance to your network (which in many cases, especially with VMs on cloud providers, might be the internet at large, depending on your local networking), so you will want to ensure your password is strong, you don't have any additional GRANTs, you keep your instance up-to-date, you firewall access to that port as much as possible from a higher level firewall, etc (standard "exposing my database to the outside world" precautions).
Did you update your mysql version?
Yes, image: mysql:8.0. Actually I have never been using 5.7.
As I said you didn't see my answer properly on staskoverflow. Use 8.0.20 version. I was facing the same problem with 8.0 version.
Okay, I have set it up with mysql:8.0.20 now but the problem remains. After rebuilding everything often there is no new entry in mysql.user table or any new database. However, that works after couple of retrials!
          
If anyone struggles with this needs to:
Ensure that volume was freshly created when starting Docker because users and passwords are created only on initial startup (so changing passwords in docker-compose.yml doesn't actually change password in existing volume)
Passwords defined in docker-compose.yml doesn't contain characters that would malform compose format. For example if $ is used it would be interpolated, so for password foo$bar/foo you could get WARNING: The bar variable is not set. Defaulting to a blank string. when starting and actual password would be foo/foo (and then you would get Access denied for user 'your_user'@'172.19.0.1' (using password: YES) when trying to connect with "complete" password)
Passwords defined in your web apps using .env files are loaded properly. I don't have example right now, but I remember one day I had a problem that file wasn't parsed properly (probably because of = or ") so actual password used in the app wasn't the password defined in .env and in the database
ensure that correct user+password is provided 😉 For example I was using non-root user with password defined in MYSQL_ROOT_PASSWORD, so it wasn't matched. Silly mistake, but it happens.
Happy connecting!
          
The way I fixed this was to create a bash script file and place it inside the 'db' folder (alongside my usual init.sql file that I use to populate my DB). This 'db' folder is the same one I use in my docker-compose.yml for the docker-entrypoint-initdb volume. That means that every script inside the db folder will run automatically while compose is setting up. The bash script contains the following;
	echo "Creating new user g..."
	mysql -uroot -p"pass" -e "CREATE USER 'g'@'%' IDENTIFIED BY 'pass';"
	echo "Granting privileges..."
	mysql -uroot -p"pass" -e "GRANT ALL PRIVILEGES ON *.* TO 'g'@'%';"
	mysql -uroot -p"pass" -e "FLUSH PRIVILEGES;"
	echo "All done."
It essentially logs in as root and creates a user called 'g' on the host '%' - which means the user 'g' works on all hosts, not just localhost. This is the user that my python app will use to connect to the db.
My docker compose yml looks like this;
version: "2"
services:
  mysql:
    image: mysql:5.7
    restart: always
    container_name: my_db
    environment:
      MYSQL_ROOT_PASSWORD: 'pass'
      MYSQL_DATABASE: 'db'
    ports:
      - 33060:3306
    volumes:
      - ./db:/docker-entrypoint-initdb.d
    depends_on:
      - mysql
    container_name: my_app
    build: .
    env_file:
      - .env
    ports:
      - "8000:8000"
Hope this helps someone else. Godspeed fellas.
@s1dekick223
Check if the database user exists and can connect
In MySQL, each database user is defined with IP address in it, so you can have for example a root user allowed to connect from localhost (127.0.0.1) but not from other IP addresses. With a container, you never access to the database from 127.0.0.1, it could explain the problem.
To check it, you can do the following:
1* From a terminal, connect you to your MySQL running container
docker exec -it your_container_name_or_id bash
2* In your container, connect you to the MySQL database
mysql -u your_user -p
It will ask you your password, you have to write it and press enter.
3* In your MySQL database, execute this SQL script to list all existing database users
SELECT host, user FROM mysql.user;
It will display a table, for example like this:
+------------+------------------+
| host       | user             |
+------------+------------------+
| %          | root             |
| 127.0.0.1  | root             |
| ::1        | root             |
| localhost  | mysql.sys        |
| localhost  | root             |
| localhost  | sonar            |
+------------+------------------+
It has to contain a line with your database user and '%' to works (% means "every IP addresses are allowed"). Example:
+------------+------------------+
| host       | user             |
+------------+------------------+
| %          | root             |
+------------+------------------+
My root user can connect itself from any IP addresses.
Are external connections allowed?
After that, like @ltangvald said, it could be a problem of allowing external connections to the container.
To check it, you can do the following:
1* From a terminal, connect you to your MySQL running container
docker exec -it your_container_name_or_id bash
2* In your container, run this command
mysqld --verbose --help | grep bind-address
It will display address to bind to, for example like this:
  --bind-address=name IP address to bind to.
bind-address                                                 0.0.0.0
The bind address have to be 0.0.0.0 (which means "every IP addresses") to work.
Also, a note:
Using docker-compose, if you link a volume, the parameters
    environment:
       MYSQL_ROOT_PASSWORD: 'pass'
       MYSQL_DATABASE: 'db'
       MYSQL_USER: 'user'
       MYSQL_PASSWORD: 'pass'
in your docker-compose.yml will not be used, so default user will not be created: you have to create it manually or remove the volume declaration.
Can you show how to change the bind-address parameter?
Can you show how to change the bind-address parameter?
If you haven't already changed it (like via command in docker-compose.yml or providing a .cnf file), then you really shouldn't need to change it. The container IP address is usually unknown beforehand and so the container-default of 0.0.0.0 ensures that it will "just work".  This is why the Dockerfile comments out bind-address in the upstream-provided config files:
      mysql/template/Dockerfile.debian
         Line 82
      79fb37b
          
Posting a single command that worked in my case (replace paths to yours):
docker run \
--name=mysql \
--env="MYSQL_ROOT_HOST=%" \
--env="MYSQL_ROOT_USERNAME=root" \
--env="MYSQL_ROOT_PASSWORD=master" \
--mount type=bind,src=/Users/eugene/docker/mysql/etc/my.cnf,dst=/etc/my.cnf \
--mount type=bind,src=/Users/eugene/docker/mysql/var/lib/mysql,dst=/var/lib/mysql \
--detach \
-p 3306:3306 \
mysql/mysql-server:5.7.19
Make sure you have two folders created before running the command above:
/Users/eugene/docker/mysql/etc/my.cnf
/Users/eugene/docker/mysql/var/lib/mysql
Here's the content of /Users/eugene/docker/mysql/etc/my.cnf:
[mysqld]
# IMPORTANT
user=root
# IMPORTANT
bind-address=0.0.0.0
max_allowed_packet=2000M
#ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
sql_mode=NO_ENGINE_SUBSTITUTION
show_compatibility_56=ON
# logging settings
general-log=0
# actual path: /Users/eugene/docker/mysql/var/lib/mysql/general_log_file.log
general_log_file=/var/lib/mysql/general_log_file.log
slow-query-log=0
# actual path: /Users/eugene/docker/mysql/var/lib/mysql/slow_query_log_file.log
slow_query_log_file=/var/lib/mysql/slow_query_log_file.log
          
(1)  First, check if HOST "%" is present for the USER you created in the container by running the following: -
docker exec -it your_container_name_or_id bash
mysql -u your_user -p
SELECT host, user FROM mysql.user;
For me, this was the output and "%" host was not present
+------------+------------------+

| host       | user                |

+------------+------------------+

| localhost  | root               |

| localhost  | mysql.sys     |

| localhost  | root               |

+------------+------------------+
To  fix this, we need to manually add the "%" for the USER created in the container
+-----------+---------------+

| host      | user             |

+-----------+---------------+

| %         | root               |

+-----------+---------------+
(2) You can add it by running the following commands: -
docker exec -it your_container_name_or_id bash
mysql -u your_user -p
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'Pa55w0rd' WITH GRANT OPTION;
          
My passwords were defined in a .env-file. As they contained "special characters" (asterisk, equals-sign, the like), I enclosed them with quotes. The line

      MYSQL_PASSWORD: ${DB_PASSWORD}

in the docker-compose.yml resulted in the database being configured with a password containing those quotes.
Defining a password with just alphanumeric characters and not enclosing it solved the issue for me.
          
I was getting this because I'm using mysql 8 and the mysql library doesn't seem to support the new auth protocol in mysql 8 (caching_sha2_password). I had to change my mysql user over to use mysql_native_password:
ALTER USER 'theUsername'@'%' IDENTIFIED WITH mysql_native_password BY 'thePassword';
FLUSH PRIVILEGES;
      Host '172.18.0.1' is not allowed to connect to this MySQL server using docker compose 3.8 & mysql 8.0.24
          
Hey guys!

I read all messages here, and after all I tried to redefine the password of my user on database and no way.

So I do this:

1- drop the user from database (no mercy here)

2- recreate user with same password

3- apply privileges again
In my case, I used environment variables, and some days ago, I received a docker update, and I think after this update, thinks going strange.

But, anyway, when I deleting, recreating user and apply privileges, everything is ok!
I hope it helps someone :)

Peace!