I've been working for some time with a Docker LEMP stack, and, up until now, have not had to use my MySQL portion. Today, when I added a volume to the compose file, it seems to have broken the container.

Without the volume attached, the container functions just as expected. However, when you add the volume to the stack, the task is repeatedly rejected. Because the container is automatically deleted and recreated, I was not able to pull any logs. Below is the MySQL portion of the LEMP stack...

  image: 'mariadb'
    - '3306:3306'
    - /mnt/sdb/Containers_Common/WWW/MySQL:/var/lib/mysql

Providing context: The mount point is a network share established across all nodes using fstab. For testing, permissions have been set to 777.

Is there something I am missing here? Perhaps the MySQL socket needs to be mounted as well?

Running the container outside of the stack to get a look at the logs without them being destroyed produced these results:

2019-06-07T11:45:34.286323Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-06-07T11:45:34.286835Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.16) initializing of server in progress as process 30
2019-06-07T11:45:34.293509Z 0 [ERROR] [MY-010457] [Server] --initialize specified but the data directory has files in it. Aborting.
2019-06-07T11:45:34.293532Z 0 [ERROR] [MY-013236] [Server] Newly created data directory /var/lib/mysql/ is unusable. You can safely remove it.
2019-06-07T11:45:34.293727Z 0 [ERROR] [MY-010119] [Server] Aborting
2019-06-07T11:45:34.305548Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.16)  MySQL Community Server - GPL.
6:45 root@Docker01 /mnt/sdb/Containers_Common/WWW/MySQL
  • What's in the volume? – Michael Hampton Jun 7 '19 at 3:16
  • What does the logs of docker logs <container-name-or-id> say? You should see more detailled information there why MySQL crashes. – Lion Jun 7 '19 at 9:37
  • @MichaelHampton The volume contains the persistent database files. – jkmurrell Jun 7 '19 at 11:32
  • @Lion the container logs get destroyed when the service tries to spawn another instance. I'm going to try running the container outside the stack to get some logs... – jkmurrell Jun 7 '19 at 11:39
  • 1
    @Lion that helped. I was able to fix the original problem. Thank you. Now I'm onto MySQL complaining about not being able to change the permissions of ca.pem – jkmurrell Jun 7 '19 at 13:56

Despite having 777 permissions, the MySQL server will not bind to a directory unless the owner is also changed to mysql:mysql

| improve this answer | |
  • I dont have mysql user on host server, So how i can solve this issue? – ImranRazaKhan Jun 23 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.