Mysql in docker container cannot go through mounted volume on os x

Question

In OS X.

I am trying to start mysql in a docker container via boot2docker by setting the volume /var/lib/mysql on the host so that I have persistent mysql data. I plan to use the data container only in the future, but right now I was trying to do this using this option.

I use the following command to start the container:

docker run -v /Users/yash/summers/db:/var/lib/mysql -i -t 'image name'

The folder /Users/yash/summers/db already exists.

In this, I ran into problems with the press. Using the command line, I can access the directory, create / delete new files, but when I start the service mysql start , I get the following error:

 150528 15:43:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150528 15:43:43 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150528 15:43:43 [Note] /usr/sbin/mysqld (mysqld 5.5.43-0ubuntu0.14.04.1) starting as process 909 ... 150528 15:43:43 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive 150528 15:43:43 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.150528 15:43:43 [Note] Plugin 'FEDERATED' is disabled. /usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist 150528 15:43:43 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 150528 15:43:43 InnoDB: The InnoDB memory heap is disabled 150528 15:43:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150528 15:43:43 InnoDB: Compressed tables use zlib 1.2.8 150528 15:43:43 InnoDB: Using Linux native AIO 150528 15:43:43 InnoDB: Initializing buffer pool, size = 128.0M 150528 15:43:43 InnoDB: Completed initialization of buffer pool 150528 15:43:43 InnoDB: Operating system error number 13 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name ./ibdata1 InnoDB: File operation call: 'create'. InnoDB: Cannot continue operation. 150528 15:43:44 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 

I have been trying to solve this in the last 2 days by going through as many pages as this , this and this .

I can not solve my problem. I think that I am not able to do what the proposed solutions offer.

From my point of view, there are some workarounds listed on these pages that include modifying uids and guids, but I think they are not entirely clear.

Can someone please explain me a detailed workaround for this.

Update 1: I tried it using a data-only container and still ran into the same problem.

I can start everything fine if I do not use the -v or --volumes-from , so I think there are no problems on the mysql server.

Update 2: Dockerfile used to create a data-only container:

 FROM ubuntu RUN mkdir /var/lib/mysql VOLUME /var/lib/mysql 

Answer 1

There are two different solutions.

• Solution No. 1. With dockerfile

  (I don't like this because I prefer the official look from the Docker Hub without any changes)

  Add the RUN usermod -u 1000 mysql to the Docker file to set the ID 1000 for the user "mysql" (the same identifier as inside the docker machine).

• Decision number 2. With my.cnf .

  However, I use my own configuration. I prefer this solution. We have a root user with the identifier 1000, because of this we can start MySQL with this user:

  • my.cnf

    The main line is user = root (you can use sed to change only this line in the file. I prefer to mount the entire file)

     [client] port = 3306 socket = /var/run/mysqld/mysqld.sock default-character-set = utf8 [mysqld_safe] pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = root pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql explicit_defaults_for_timestamp init_connect='SET collation_connection = utf8_unicode_ci' init_connect='SET NAMES utf8' character-set-server=utf8 collation-server=utf8_unicode_ci skip-character-set-client-handshake # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 #log-error = /var/log/mysql/error.log # Recommended in standard MySQL setup sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # * IMPORTANT: Additional settings that can override those from this file! # The files must end with '.cnf', otherwise they'll be ignored. # !includedir /etc/mysql/conf.d/ 

  • Change default my.cnf file:

    docker run -it -v./mysql/var/lib/mysql:/var/lib/mysql -v./my.cnf::/etc/mysql/my.cnf mariadb: 10.0.22

Answer 2

When you use the docker run -v , then docker does not manipulate file ownership. Thus, the owner of the mounted folder inside the container will have the same UID as in the main system (the username may be different). You can change the ownership of a file or directory inside the container with the chmod , but it will also change ownership in the host system. In this way, you can prepare the proper ownership of your host system before launching the docker container. This example demonstrates how it works (try on your system):

I have a ~ / foo directory that belongs to me - my UID 1000

 ~ $ ls -lnd foo drwxr-xr-x 2 1001 1000 4096 Nov 24 22:47 foo 

Launch the docker container, set the ~ / foo directory and show ownership inside the container.

 ~ $ docker run -it --rm -v ~/foo:/tmp/foo busybox ls -ln /tmp total 4 drwxr-xr-x 2 1000 1000 4096 Nov 24 21:47 foo 

The native UID inside the container is the same. Now I am changing the ownership of my computer.

 ~ $ sudo chown 1001 foo 

Run the container again, mount the foo directory and show ownership

 ~ $ docker run -it --rm -v ~/foo:/tmp/foo busybox ls -ln /tmp total 4 drwxr-xr-x 2 1001 1000 4096 Nov 24 21:47 foo 

Owner ID has also been changed

But there is one exception. If you try to install the volume in a non-existent directory, the dockers will automatically create this missing directory (but this is an obsolete function, so do not do this), and this directory will be created using UID 0. Try:

 ~ $ docker run -it --rm -v ~/foo:/tmp/bar/foo busybox ls -ln /tmp total 4 drwxr-xr-x 3 0 0 4096 Nov 24 22:10 bar 

Answer 3

I also ran into this problem; I solved this by chmod / chown'ing inside my data container, for example:

 FROM ubuntu # Create data directory RUN mkdir -p /data /var/lib/mysql RUN chmod -R 777 /data /var/lib/mysql RUN chown -R root:root /data /var/lib/mysql # Create /data volume VOLUME /data VOLUME /var/lib/mysql 

I believe this works because UFS now correctly writes permissions, rather than relying on Direct from the host to do this, which, as you discovered, does not work on OS X