Mysql: Can not run mysql success

Created on 9 Sep 2015 · 14Comments · Source: docker-library/mysql

Environment:

docker 1.8
mysql: latest

CommandLine:

docker run -i -t -e MYSQL_ROOT_PASSWORD=password mysql

Error Report:

`Running mysql_install_db
2015-09-09 06:21:46 0 [Note] /usr/sbin/mysqld (mysqld 5.6.26) starting as process 14 ...
2015-09-09 06:21:46 14 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-09-09 06:21:46 14 [Note] InnoDB: The InnoDB memory heap is disabled
2015-09-09 06:21:46 14 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-09-09 06:21:46 14 [Note] InnoDB: Memory barrier is not used
2015-09-09 06:21:46 14 [Note] InnoDB: Compressed tables use zlib 1.2.7
2015-09-09 06:21:46 14 [Note] InnoDB: Using Linux native AIO
2015-09-09 06:21:46 14 [Note] InnoDB: Using CPU crc32 instructions
/usr/sbin/mysqld: Can't create/write to file '/tmp/ibJoJxoL' (Errcode: 13 - Permission denied)
2015-09-09 06:21:46 7f2897b56720 InnoDB: Error: unable to create temporary file; errno: 13
2015-09-09 06:21:46 14 [ERROR] Plugin 'InnoDB' init function returned error.
2015-09-09 06:21:46 14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2015-09-09 06:21:46 14 [ERROR] Unknown/unsupported storage engine: InnoDB
2015-09-09 06:21:46 14 [ERROR] Aborting

2015-09-09 06:21:46 14 [Note] Binlog end
2015-09-09 06:21:46 14 [Note] /usr/sbin/mysqld: Shutdown complete
`

Source

dragon9783

Most helpful comment

Same problem here. Investigating a little bit inside the docker container, it seems the problem is the /tmp directory has 755 permissions instead of 777. So the mysql user is not able to write there. It started to happening to me after an apt update && apt dist-upgrade, so not sure if was because an apparmor update or because a kernel update. Anyway, I solved it re-pulling the latest mysql image from Docker hub and everything started to work again.

You said you already pulled the latest... so maybe a "dirty workaround" could be to create a Dockerfile and inserting a RUN chmod 777 /tmp line, I don't know... is an idea. Good luck!

delete mysql image and pull mysql image and OK~

cute-angelia on 26 Oct 2018

👍6 🎉2

All 14 comments

I am unable to reproduce this :cry:. docker version, docker info, mysql image id? Maybe selinux or apparmor configuration problems :confused:?

yosifkit on 10 Sep 2015

@yosifkit collected information

docker version

Client:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:35:49 UTC 2015
OS/Arch: linux/amd64

Server:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:35:49 UTC 2015
OS/Arch: linux/amd64

docker info

Containers: 5
Images: 108
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 118
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-63-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 3.805 GiB
Registry: https://index.docker.io/v1/

docker images mysql

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
mysql latest 7eee2d462c8f 2 weeks ago 283.6 MB

i can run mysql well some time ago, but since yesterday it doesn't work well.

dragon9783 on 10 Sep 2015

same issue here.

quilombodigital on 9 Oct 2015

It could be an apparmor configuration, but I don't think it would suddenly change to stop working. @dragon9783 did you find out what was wrong?

@quilombodigital you also are on Ubuntu 14.04 using aufs with about 4GB of RAM?

yosifkit on 9 Oct 2015

@yosifkit it never happen after re-pull mysql image, and i run mysql container with option --restart = always, btw, mysql container volume from host dirctory, permission will be
, is it normal?

dragon9783 on 10 Oct 2015

That seems mostly normal, 999 is the user and group id of mysql in the container and so it chowns the directory before mysqld starts: https://github.com/docker-library/mysql/blob/044416ebc78ccd6b71f6ac1150937719113290c7/5.6/docker-entrypoint.sh#L21. I am not sure where the user id 8 comes in.

yosifkit on 12 Oct 2015

Can this still be reproduced with an up-to-date image?

tianon on 22 Aug 2016

I have the same problem (mysqld: Can't create/write to file '/tmp/ibV3bkv0' (Errcode: 13 - Permission denied)) when running any of mysql:5.7(ec161391b8c3) or mysql:latest (44a8e1a5c0b2) images as of 2017-07-19T09:00:00.

The failing command line`and the log:

$ docker run --name mysql --rm -ti -e MYSQL_ROOT_PASSWORD=toto mysql:5.7
Initializing database
2017-07-19T07:13:21.613098Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysqld: Can't create/write to file '/tmp/ibGHKELE' (Errcode: 13 - Permission denied)
2017-07-19T07:13:21.616035Z 0 [ERROR] InnoDB: Unable to create temporary file; errno: 13
2017-07-19T07:13:21.616047Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2017-07-19T07:13:21.616055Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2017-07-19T07:13:21.616060Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-07-19T07:13:21.616067Z 0 [ERROR] Failed to initialize plugins.
2017-07-19T07:13:21.616071Z 0 [ERROR] Aborting

If I run it with --security-opt="apparmor=unconfined" it works, so it's definitely related to AppArmor.

I have tried to run with the usr.sbin.mysqld AppArmor profile that is distributed with the mysql package for Ubuntu, but then I encounter another problem (https://github.com/moby/moby/issues/7512).

Extract from docker info:

[...]
Server Version: 17.05.0-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 598
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.8.0-58-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.62GiB
[...]
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Any suggestions for a custom AppArmor profile that fixes this issue?
Is there some way to distribute AppArmor profiles with images so things work by default?

morallo on 19 Jul 2017

Same problem here. Investigating a little bit inside the docker container, it seems the problem is the /tmp directory has 755 permissions instead of 777. So the mysql user is not able to write there. It started to happening to me after an apt update && apt dist-upgrade, so not sure if was because an apparmor update or because a kernel update. Anyway, I solved it re-pulling the latest mysql image from Docker hub and everything started to work again.

You said you already pulled the latest... so maybe a "dirty workaround" could be to create a Dockerfile and inserting a RUN chmod 777 /tmp line, I don't know... is an idea. Good luck!

OscarAkaElvis on 7 Aug 2017

🎉2

I'm going to close this given that we can't reproduce -- if someone is able to create a simple reproducer which shows that this is definitely an issue with the image and not something environmental, please file a new detailed issue (or even a PR). Thanks!

tianon on 26 Dec 2017

Same problem here. Investigating a little bit inside the docker container, it seems the problem is the /tmp directory has 755 permissions instead of 777. So the mysql user is not able to write there. It started to happening to me after an apt update && apt dist-upgrade, so not sure if was because an apparmor update or because a kernel update. Anyway, I solved it re-pulling the latest mysql image from Docker hub and everything started to work again.

You said you already pulled the latest... so maybe a "dirty workaround" could be to create a Dockerfile and inserting a RUN chmod 777 /tmp line, I don't know... is an idea. Good luck!

delete mysql image and pull mysql image and OK~

cute-angelia on 26 Oct 2018

👍6 🎉2

Same as @cute-angelia , I cannot run mysql:5.7 successfully, but mysql:latest.

keineahnung2345 on 8 Aug 2019

Thanks @cute-angelia to save my day.
In my case(docker version 19.03.3 and debian 9 ), met the same issue when I changed the root directory of persistent Docker state( ExecStart=/usr/bin/dockerd --data-root /mnt/data/docker -H fd://).

gaozhidf on 10 Oct 2019

Thanks @cute-angelia to save my day.
In my case(docker version 19.03.3 and debian 9 ), met the same issue when I changed the root directory of persistent Docker state( ExecStart=/usr/bin/dockerd --data-root /mnt/data/docker -H fd://).

Yes you are on the right track, had this problem,
I modified ExecStart, i had to purge everything out, cancel the change on ExecStart for Docker,
and it worked after cancelling the folder change.