I'm trying to run a mysql docker container with persistent data mapped to a folder that is mounted through CIFS.
(I orginally posted a more general question but got a bit further in terms of user rights and now the error seems to be specific to innodb/cifs mounts. Hence I'm reposting this as a new topic. Thanks for life888888 for the initial help.)
Here is the command to start the container:
docker run \
--name localmysql \
-v /mnt/mysqlshare:/var/lib/mysql \
--rm \
--env MYSQL_ALLOW_EMPTY_PASSWORD=true \
-it \
mysql:8.0.31-debian
/mnt/mysqlshare is a mounted cifs share. The command to map the CIFS mount is below:
sudo mount -t cifs -o username=linuxmount,cache=none,vers=3.0,uid=999,gid=999,rw [networkpath] /mnt/mysqlshare
On the machine where docker is running I have a user set up called "mysql" which is the owner of the mapped cifs drive. It is configured to have 999 as uid and group (which ties to mysql-user in the docker container which is used by default).
When remoting into the container (interactive session) and changing to "su mysql" I'm able to write into /var/lib/mysql and changes are reflected in the mounted drive.
However when starting up the container I'm getting the following error which just keeps repeating:
2022-12-08T21:12:56.435340Z 0 [ERROR] [MY-012894] [InnoDB] Unable to open './#innodb_redo/#ib_redo0' (error: 11).
2022-12-08T21:12:56.435784Z 0 [ERROR] [MY-012574] [InnoDB] Unable to lock ./#innodb_redo/#ib_redo0 error: 13
There's files added to the folder:
I had that same issue on MariaDB and I'm having some success with the following (in docker-compose.yml file):
redacted-volume:
driver: local
driver_opts:
type: "cifs"
o: "mfsymlinks,vers=3.0,username=redacted,password=redacted,uid=999,gid=999"
device: "//192.168.4.204/docker-data/redacted/data-db"
mfsymlinks enables symlinks that MariaDB needs. uid and gid are Linux UserId and GroupId of MariaDB user that accesses the share. This works for me with Windows Server connecting to SMB shares from TrueNAS Scale. Docker version 20.10.22.
I still have this same issue with MySQL. I can't get it to work with this same configuration and I feel like I have looked everywhere on the internet.
Related
I'm running docker in Ubuntu and trying to create and run a MySql container. I want to use a mounted network share for the data directory. I am trying the following docker run command, but I'm having issues with permissions. How do I fix this?
root#jarvis:/mnt/wayne/mysql-data$ sudo docker run -it -p 3306:3306 -e MYSQL_ROOT_PASSWORD=admin -v /mnt/wayne/mysql:/var/lib/mysql/ --name mysqlserver mysql/mysql-server
[Entrypoint] MySQL Docker Image 8.0.20-1.1.16
[Entrypoint] Initializing database
2020-06-08T21:43:25.253898Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.20) initializing of server in progress as process 22
2020-06-08T21:43:25.281460Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-06-08T21:43:27.815075Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
mysqld: Cannot change permissions of the file 'ca.pem' (OS errno 1 - Operation not permitted)
2020-06-08T21:43:29.851875Z 0 [ERROR] [MY-010295] [Server] Could not set file permission for ca.pem
2020-06-08T21:43:29.852970Z 0 [ERROR] [MY-013236] [Server] The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
2020-06-08T21:43:29.854806Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-06-08T21:43:31.947298Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.20) MySQL Community Server - GPL.
You use CIFs for network mount means the remote server is windows right? My answer is based on this assumption.
The latest mysql docker image has a user named mysql and its uid=27,gid=27
You verify this by mounting an empty folder as data_dir. You will see that the files created by mysql container has user and group is as 27.
Hence the mysql container expects files with uid/gid(owner userid and owner group id) as 27 in its data_dir. But the files that you mounted from the windows share has uid/gid which belongs to the user that executes mount command in ubuntu. This is the default behavior of mount command.
To solve this you need to pass "uid=27,gid=27" parameters to the Linux mount command.
For instance
sudo mount -t cifs -o
username=windows-username,uid=27,gid=27
//WIN_SHARE_IP/ /mnt/wayne
You can have look here for further details
I must say it is unlikely to run mysql over a network share. It won't perform well.
This is not exactly with MySQL but I hope it can give you an idea, I basically use this for testing against a MySQL database from my local environment, for this I use docker-compose and MariaDB, I configure the "data-dir" as a volume so that I can stop/start the docker container without the need to "seed" every time the database.
This is the content of the /your/path/docker-compose.yml file:
---
version: '3'
services:
mariadb:
image: mariadb:10.4.13
container_name: mariadb
restart: always
ports:
- 13306:3306
environment:
MYSQL_DATABASE: world
MYSQL_ROOT_PASSWORD: test
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
volumes:
- ${PWD}/mariadb/db/:/var/lib/mysql
In the same directory, I have the volume directory /your/path/mariadb/db
Then to bring up the container I use:
$ docker-compose up
From the docker-compose.yml has you can see I use port 13306 therefore for testing/connection I use:
$ mysql -h 127.0.0.1 -P13306 -uroot -p
All the data (databases) will be in /your/path/mariadb/db
If you run into the same "permissions" problem:
mysqld: Cannot change permissions of the file 'ca.pem' (OS errno 1 - Operation not permitted)
Try to change the permissions of your volume/mount point, for example:
chmod -R 777 /your/volume/mount_point
okay, I tried this and google also, what I found is
https://github.com/docker-library/mysql/issues/302#issuecomment-308745834
So basically if you are using mysql:5.7 then upgrade to mysql:5.7.16.
And if this doesn't help then I have one more solution.
Basically the problem is you are sharing dir to container -v /mnt/wayne/mysql:/var/lib/mysql/ but you ubuntu is not giving permission to access the /mnt/wayne/mysql dir. so give admin permission to this location or you can create a docker user chown and chmode.
Basically give permission to the host machine directory. so that docker container can access it.
and One more thing give permission to the docker container dir also, that is showing in your error
The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
Create a user in a docker container which have chown and chmod permissions to the dir /var/lib/mysql/.
if you are using dockerfile to create mysql container then use these following 2 lines in it
FROM mysql:5.7.16
WORKDIR /app
RUN chown -R admin:admin /app
RUN chmod 755 /app
USER admin
CMD ["Your command"]
To operate normally, MariaDB or MySQL needs to set some permissions on their own files. Some external file systems (such as FTP and many others) do not support these features. You need to use a file system which supports these features.
there is a permission issue to access the mounted volume. Please read the documentation about use volumes:
https://docs.docker.com/storage/volumes/#use-a-volume-driver
For NFSv3 Partition:
$ docker service create -d \
--name nfs-service \
--mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,volume-opt=o=addr=10.0.0.10' \
nginx:latest
Or check the CA.pem file permissions (use chmod 777 /path/to/ca.pem)
For NFSv4 Partition:
docker service create -d \
--name nfs-service \
--mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,"volume-opt=o=10.0.0.10,rw,nfsvers=4,async"' \
nginx:latest
Check https://docs.docker.com/storage/volumes/#use-a-volume-driver
Using Laradock
System Info:
Docker version: 17.10.0-ce, build f4ffd25
OS: Windows 10 Home
When I run docker-compose up -d mysql I'm getting error. Following is the docker logs
[Note] Basedir set to /usr/
[Warning] The syntax '--symbolic-links/-s' is deprecated and will be removed in a future release
[Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
[ERROR] --initialize specified but the data directory has files in it. Aborting.
[ERROR] Aborting
I have tried deleting mysql folder under ~/.laradock\data and didn't work.
Update 1
MySQL Container under laradock Dockerfile
mysql:
build:
context: ./mysql
args:
- MYSQL_VERSION=${MYSQL_VERSION}
environment:
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- TZ=${WORKSPACE_TIMEZONE}
volumes:
- ${DATA_SAVE_PATH}/mysql:/var/lib/mysql
- ${MYSQL_ENTRYPOINT_INITDB}:/docker-entrypoint-initdb.d
ports:
- "${MYSQL_PORT}:3306"
networks:
- backend
MySQL Dockerfile
ARG MYSQL_VERSION=8.0
FROM mysql:${MYSQL_VERSION}
MAINTAINER Mahmoud Zalt <mahmoud#zalt.me>
#####################################
# Set Timezone
#####################################
ARG TZ=UTC
ENV TZ ${TZ}
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN chown -R mysql:root /var/lib/mysql/
ADD my.cnf /etc/mysql/conf.d/my.cnf
CMD ["mysqld"]
EXPOSE 3306
Update 2
After I delete mysql folder under ~/.laradock/data I'm getting following error. After the command it generates the files in below image. When I rerun giving back the previous error mentioned above.
[Note] Basedir set to /usr/
[Warning] The syntax '--symbolic-links/-s' is deprecated and will be removed in a future release
[Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
[Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
[Warning] You need to use --log-bin to make --log-slave-updates work.
libnuma: Warning: /sys not mounted or invalid. Assuming one node: No such file or directory
mbind: Operation not permitted
[ERROR]
InnoDB: Operating system error number 22 in a file operation.
[ERROR] InnoDB: Error number 22 means
'Invalid argument'
[ERROR] InnoDB: File
./ib_logfile101: 'aio write' returned OS error 122. Cannot continue
operation
[ERROR] InnoDB: Cannot
continue operation.
** I tried in a windows 7 machine and its working.
Disable AIO
This fixed it for me when I got the AIO error as you did when I was starting a container from a guest Debian OS from Virtualbox and creating the database files on a shared folder on Windows 10.
The issue seems to be that AIO is not supported on shared folders, or at least on some versions of Windows. It seems to have occurred for me after I moved from Windows 10 Pro to Home after my main machine crashed.
For details:
aio
disable aio in MySQL for zfs
Here are some options:
Option 1 - start the container like this :
docker run -it mysql --innodb_use_native_aio=0
Option 2 - add the command to your docker-compose file:
command: --innodb_use_native_aio=0
In context, this is the relevant portion of my working docker-compose.yml:
services:
db:
image: ${MYSQL_IMAGE}
command: "--innodb_use_native_aio=0"
volumes:
- ${DB_DATA_PATH}:/var/lib/mysql
ports:
- ${MYSQL_PORT}:3306
Option 3 -- add an option to your my.cnf file in your build
innodb_use_native_aio=0
Option 4 - Don't persist your DB on the local file system.(Can destroy your db, Not Recommended)
Simply remove the volume in your docker configuration that contains your mysql db. Of course, your DB will be deleted if you do a docker-compose down or otherwise destroy your container, so there's that.
I am not sure but Try this step.This is because of data folder.
Try remove the docker image. List all images using docker images then remove the mysql & laradock mysql using docker rmi imagename. Dont forget remove the docker volume using docker volume rm volumename
Also go to cd ~/.laradock/data remove the mysql folder.
Then try docker-compose up mysql for debuging. If no errors, you could try docker-compose up -d mysql
I had the same problem with my Windows 10 Enterprise, I couldn't find perfect solution around it because it seems to be my Windows version issue - I have ran the same image on other windows (8 & 10 professional) successfully. My temporary work around was to remove the /var/lib/mysql mount entirely from the docker-compose file allowing the database data files to be created and modified in the container itself.
I use kitematics which will restart and reattach my created container anytime I want to work on the container, like that I don't loose my data when the container exit. If you don't use kitematics this what it does.
After running docker-compose the image will be created and a container will be created to run it as well, I avoid using run on the created image because this will create new container
I stick to running the following sequentially
docker ps -a # this command will get container_id of all container, those that are running and those that are not
docker start <container_id> # start container from background
docker attach <container_id> # attach container to standard input
With these docker commands my data were preserved in the container even after exiting and restarting
BACK UP
Now whenever I want to move the data, I will commit my container into an image and save the image to local storage
docker commit <container_id> <backup_image_name>:<1_31_2017> # I use date to tag it
docker save -o <local_storage_tar_name> <backup_image_name>
RESTORE
Whenever I need to restore the mysql container either on my computer or for a new programming intern
cd <dir_containing_the_tar_file>
docker load -o <local_storage_tar_name>
This solution is for your update
File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation
I hope this helps somebody
In addition to the response above by AndrewD, you should change the permission on the my.cnf so that it does not get ignored when booting up. You can run the below command,
sudo chmod 400 my.cnf
Do this right before running docker-compose up -d
First off, I know not to run as root normally. I have an abnormal situation: I need to use mysqldump with the --tab argument, which requires permission to write to disk, and I want to use those files outside the Docker container. I could explain why running mysqld as root makes this easier, but isn't this question long enough? Running as root is safe in this case because the container will be used only for running tests and for updating DB backup scripts based on SQL migration scripts, and it will be started to do 1 job and then taken back down again.
When I google for how to run mysqld as root, I find the answer indirectly given in instructions on how to NOT run as root. Among other things in order to run mysqld as user_name:
Start the server as user user_name. Another alternative is to start mysqld as the Unix root user and use the --user=user_name option.
To start the server as the given user automatically at system startup time, specify the user name by adding a user option to the [mysqld] group of the /etc/my.cnf option file or the my.cnf option file in the server's data directory.
Do we do one of those? Both of those? I'll assume both just in case. But do they really mean /etc/my.cnf, or does that depend on the installation (e.g. what Linux distribution)? E.g. Docker image mysql:5.6 has /etc/mysql/my.cnf. The directions for the MySql Docker image advise mounting a volume at /etc/mysql/conf.d which is referenced in the aforementioned my.cnf. (Doing so overwrites 2 configuration files that are there by default, so I used a COPY command in my Dockerfile instead to merely add a config file.) The file does make it into the container:
root#4f612d10a690:/etc/mysql/conf.d# cat my.cnf
[mysqld]
user=root
One further requirement from the MySql manual is to add the --user=root argument to mysqld. The official MySql image calls mysqld via its CMD, so I override that in my Dockerfile. My CMD command does indeed run (it is run in 2 places in official MySql image's entrypoint script):
# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mysql 1 0.1 2.8 1452788 472756 ? Ssl 14:24 0:01 mysqld --user=root
Note that mysqld has the --user=root command I provided, but is running as the mysql user, not as root.
Here's my full Dockerfile:
FROM mysql:5.6
VOLUME ["/var/lib/mysql-files"]
COPY ["my.cnf", "/etc/mysql/conf.d"]
CMD ["mysqld", "--user=root"]
My only guess as to why it's not running as root is that they mysql image's entrypoint script changes to the mysql user before running:
# allow the container to be started with `--user`
if [ ...blah... -a "$(id -u)" = '0' ]; then
...blah...
exec gosu mysql "$BASH_SOURCE" "$#"
fi
The above snippet basically says, if the user is root, then run the supplied arguments (the CMD + args in this case) as the mysql user.
Is running mysqld as root simply not supported by the official MySql Docker image?
Note: this is how to run mysqld process as SO's root user, and not how to get the root MySQL user.
I don't know whether exists a better approach but this works.
Viewing the official entrypoint.sh, it seems that it has no support of chaging the default mysql user
I realized how to run mysql as root but you need to have already initialized the data directory.
Step 1) Start a normal mysql in order to initialize a volume (the mysql entrypoint.sh will do that job):
docker run \
--rm \
-v $(pwd)/mysql/:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD="abc" \
mysql:5.6
Step 2) Stop and remove that container:
docker stop <container-id>
Step 3) Start again a new mysql process based on the data dir that has been created, but this time avoid to run the official mysql entrypoint:
docker run \
-v $(pwd)/mysql/:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD="abc" \
--entrypoint mysqld \
mysql:5.6 \
--user root
Step 4) Check it:
▶ docker exec -it 4add4d065c3e bash
root#4add4d065c3e:/# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 2.8 23.0 1314864 471104 ? Ssl 15:12 0:00 mysqld --user root
root 28 3.0 0.1 20248 3040 ? Ss 15:12 0:00 bash
root 34 0.0 0.1 17500 2068 ? R+ 15:12 0:00 ps aux
We are using docker-compose in our app and am not familiar with this part of the application we are getting this error after runnning docker-compose up --build:
Mysql: forward host lookup failed: Unknown host
After an inspection to hosts list created by docker-compose:
$ docker network prune
$ docker network ls
$ docker network inspect <desired_network>
I noticed db was not there, so I tried to build it up and see what happens:
$ docker-compose run <desired_db_image>
Getting the correct output:
Initializing database
mkdir: cannot create directory '/var/lib/mysql//mysql': No space left on device
Fatal error Can't create database directory '/var/lib/mysql//mysql'
So you need to free some space:
$ docker system prune
Select: y
I'm trying to run a docker mysql container with initialized db according instruction provided in this message https://stackoverflow.com/a/29150538/6086816. After first run it works ok, but on second run, after trying of executing /usr/sbin/mysqld from script, I get this error:
db_1 | 2016-03-19T14:50:14.819377Z 0 [ERROR] Another process with pid 10 is using unix socket file.
db_1 | 2016-03-19T14:50:14.819498Z 0 [ERROR] Unable to setup unix socket lock file.
...
mdir_db_1 exited with code 1
what can be the reason of it?
I was facing the same issue. Following are the steps that I tried to resolve this issue -
Firsly, stop your docker service by using following command - "sudo service docker stop"
Now,get into the docker folder in my Linux system using the following path -
/var/lib/docker.
Then within the docker folder you need to get into the volumes folder. This folder contains the volumes of all your containers (memory of each container) -
cd /volumes
After getting into volumes do 'sudo ls' you will find multiple folders with hash names. These folders are volumes of your containers. Each folder is named after its hash
(You need to inspect your docker container and get the hash of your container volume. For this, you need to do the following steps -
Run command "docker inspect 'your container ID' ".
Now you will get a JSON file. It is the config file of your docker container.
Seach for Mounts key within this JSON file. In Mounts, you will get the Name(hash) of your volume. (You will also get the path of your volume within the Mounts. Within Mounts "Name" key is your volume name and "Source" is the path where your volume is located.)).
Once you get the name of your volume you can go within your volume folder and within this folder you will find "_data" folder. Get into this folder.
Finally within "_data" folder use sudo ls command and you will find a folder with the name mysql.sock.lock. Remove this folder By "rm -f mysql.sock.lock".
Now restart your docker service and then start your docker container. It will start working.
Note- Use sudo in each command while you are in the docker container folder.
You should make sure the socket file have been deleted before you start mysql.Check my.cnf(/etc/mysql/my.cnf) file to get the path of socket file.
find sth like this socket = /var/run/mysqld/mysqld.sock.And delete the .sock.lock file as well.
This is a glitch with docker.
Execute following commands:
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
This will stop all containers and remove them.
After this it should work just fine.
Just faced same problem.
After many research, summary of my solution:
Find host location of docker files
$ docker inspect <container_name> --> Mounts.Source section
In my case, it was /var/snap/docker/common/.../_data
As root, you can ls -l that directory and see the files that are preventing your container from starting, the socket mysql.sock and the file mysql.sock.lock
Simply delete them as root ($ sudo rm /var/snap/.../_data/mysql.sock*) and start your docker container.
NOTE: be sure you don't have any other mysql.sock... files than those two. In that case don't use wildcar (*), delete each of them individually.
Hope this helps.
I had the same problem and got rid of it in an easy and mysterious way.
First I have noticed that I am unable to start mysql_container container. Running docker logs mysql_container indicated exactly the same problem as described repeating for few times.
I wanted to get a look around by running the container in an interactive mode by docker start -i mysql_container from one bash window while running things like
docker exec -it mysql_container cat /etc/mysql/my.cnf in another.
I have done that and was very surprised to see that this time the container started successfully. I cannot understand why. I can only guess that starting an interactive mode together with running subsequent docker exec commands slowed down init process and some another process had a bit more time to remove its locks.
Hope that helps anybody.