docker-compose 目录挂载的权限问题
我用docker-compose.yml去启动一个mysql镜像,用命令docker-compose up
version: '2'
services:
mysql:
image: centos/mysql-56-centos7:latest
restart: always
container_name: mysql
environment:
- MYSQL_ROOT_PASSWORD=111111
volumes:
- /etc/localtime:/etc/localtime
- /data/mysql:/var/lib/mysql/data
ports:
- 3306:3306
总是失败
失败原因是
Can't create test file /var/lib/mysql/data/cdef45a5817c.lower-test
全部日志为:
Creating network "mysql_default" with the default driver
Creating mysql ... ^M
^[[1A^[[2K^MCreating mysql ... ^[[32mdone^[[0m^M^[[1BAttaching to mysql
^[[36mmysql |^[[0m => sourcing 20-validate-variables.sh ...
^[[36mmysql |^[[0m => sourcing 25-validate-replication-variables.sh ...
^[[36mmysql |^[[0m => sourcing 30-base-config.sh ...
^[[36mmysql |^[[0m ---> 16:39:17 Processing basic MySQL configuration files ...
^[[36mmysql |^[[0m => sourcing 60-replication-config.sh ...
^[[36mmysql |^[[0m => sourcing 70-s2i-config.sh ...
^[[36mmysql |^[[0m ---> 16:39:17 Processing additional arbitrary MySQL configuration provided by s2i ...
^[[36mmysql |^[[0m => sourcing 40-paas.cnf ...
^[[36mmysql |^[[0m => sourcing 50-my-tuning.cnf ...
^[[36mmysql |^[[0m ---> 16:39:17 Initializing database ...
^[[36mmysql |^[[0m ---> 16:39:17 Running mysql_install_db --rpm --datadir=/var/lib/mysql/data
^[[36mmysql |^[[0m 2020-01-10 16:39:17 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
^[[36mmysql |^[[0m 2020-01-10 16:39:17 0 [Note] Ignoring --secure-file-priv value as server is running with --bootstrap.
^[[36mmysql |^[[0m 2020-01-10 16:39:17 0 [Note] /opt/rh/rh-mysql56/root/usr/libexec/mysqld (mysqld 5.6.38) starting as process 30 ...
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Warning] Can't create test file /var/lib/mysql/data/a5d11f4146dd.lower-test
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Warning] Can't create test file /var/lib/mysql/data/a5d11f4146dd.lower-test
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Using atomics to ref count buffer pool pages
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: The InnoDB memory heap is disabled
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Memory barrier is not used
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Compressed tables use zlib 1.2.7
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Using Linux native AIO
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Using CPU crc32 instructions
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Initializing buffer pool, size = 32.0M
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] InnoDB: Completed initialization of buffer pool
^[[36mmysql |^[[0m 2020-01-10 16:39:17 7f1048c42840 InnoDB: Operating system error number 13 in a file operation.
^[[36mmysql |^[[0m InnoDB: The error means mysqld does not have the access rights to
^[[36mmysql |^[[0m InnoDB: the directory.
^[[36mmysql |^[[0m 2020-01-10 16:39:17 7f1048c42840 InnoDB: Operating system error number 13 in a file operation.
^[[36mmysql |^[[0m InnoDB: The error means mysqld does not have the access rights to
^[[36mmysql |^[[0m InnoDB: the directory.
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] InnoDB: Creating or opening ./ibdata1 failed!
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] Plugin 'InnoDB' init function returned error.
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] Unknown/unsupported storage engine: InnoDB
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [ERROR] Aborting
^[[36mmysql |^[[0m
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] Binlog end
^[[36mmysql |^[[0m 2020-01-10 16:39:17 30 [Note] /opt/rh/rh-mysql56/root/usr/libexec/mysqld: Shutdown complete
如果删除 /data/mysql:/var/lib/mysql/data 这一行就启动正常
我运行docker-compose up命令是在root下,为何会有权限问题? 因为镜像是远程下下来的,我不知道docker内运行的用户是什么,假如是mysql好了,那权限影响的也应该是docker内的目录,和docker内目录挂载的宿主机目录权限有什么关联呢?如何理解?
但是我对/data/mysql chmod 777 了啊
# ls -l /data
total 0
drwxrwxrwx 2 root root 6 Jan 9 15:28 mysql
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
今天刚遇到,稍微总结下。
官方解决办法
Running as an arbitrary user
If you know the permissions of your directory are already set appropriately (such as running against an existing database, as described above) or you have need of running mysqld with a specific UID/GID, it is possible to invoke this image with --user set to any value (other than root/0) in order to achieve the desired access/configuration:
docker run -v "$PWD/data":/var/lib/mysql --user 1000:1000 --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
mysql镜像默认以mysql用户(uid999)运行,会造成权限问题,如果设置777理论上应该可以解决,你的问题是映射到 /data/mysql:/var/lib/mysql/data,应该/data/mysql:/var/lib/mysql,未测试是否可以。
测试了,修改目录777无法解决问题,报错--initialize specified but the data directory has files in it. Aborting.或者mysqld: Can't create/write to file '/var/lib/mysql/is_writable' (Errcode: 13 - Permission denied)
相关报错说明:
If you get Errcode 13 (which means Permission denied) when starting mysqld, this means that the privileges of the data directory or its contents do not permit server access. In this case, you change the permissions for the involved files and directories so that the server has the right to use them. You can also start the server as root, but this raises security issues and should be avoided.
再次补充下777的问题
本机环境为简单起见使用的docker-machine,上述设为777仍然会无法访问,是因为创建测试文件默认权限是644,但是docker-machine由于通过vbox挂载到本机目录(对应本机uid 1000mac,虚拟机uid 1000docker),容器初始化所创建的文件用户仍然是物理机用户(1000 mac/docker),并不是容器内创建者mysql(uid 999),这是vbox挂载磁盘的一个问题引起的,如果在linux上直接部署不会出现上述问题(可以用name volume测试)。