on windows, cannot start a container with host directory as /var/lib/mysql mount
powernic opened this issue Β· 52 comments
Tried running a mariadb container by means of docker-compose.
This trouble similar to this issue #38
docker-library/mysql#99 (comment) it doesn't solve the issue.
db:
image: 'mariadb:latest'
environment:
- "MYSQL_ROOT_PASSWORD=xxxxxx"
container_name: db
volumes:
- "./mysql/db:/var/lib/mysql"
- "./mysql/localdb-run.sh:/localdb-run.sh"
command: "/localdb-run.sh"
restart: always
$ docker-compose run db
Creating network "docker_default" with the default driver
* Working around permission errors locally by making sure that "mysql" uses the same uid and gid as the host volume
-- Setting mysql user to use uid 0
-- Setting mysql group to use gid 0
* Starting MySQL
2017-01-16 0:12:44 139975239862208 [Note] mysqld (mysqld 10.1.19-MariaDB-1~jessie) starting as process 18 ...
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: The InnoDB memory heap is disabled
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Using Linux native AIO
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Using SSE crc32 instructions
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2017-01-16 0:12:44 139975239862208 [Note] InnoDB: Completed initialization of buffer pool
2017-01-16 0:12:44 139975239862208 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 0 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2017-01-16 0:12:44 139975239862208 [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!
2017-01-16 0:12:44 139975239862208 [ERROR] Plugin 'InnoDB' init function returned error.
2017-01-16 0:12:44 139975239862208 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-01-16 0:12:44 139975239862208 [Note] Plugin 'FEEDBACK' is disabled.
2017-01-16 0:12:44 139975239862208 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2017-01-16 0:12:44 139975239862208 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-01-16 0:12:44 139975239862208 [ERROR] Aborting
I can almost guarantee that the usermod -o -u $TARGET_UID mysql || true from your script is failing; using usermod you can't set another user or group to be id 0 since it is already root. Even if you could, that would cause our script to loop and continually re-exec itself.
If you need to set the user that mysqld uses, you can just set the user on docker run --user 1000:50 (or user: "1000:50" in the compose.yml) and the entrypoint script will skip the parts requiring root access. If you are using docker toolbox and boot2docker, this should be the correct userid and groupid. I am not sure what user and group you would use when running "Docker for Windows"; I was under the impression that it was supposed to just work with regards to permissions on host directories shared to containers.
@yosifkit All the same.
db:
image: 'mariadb:latest'
environment:
- "MYSQL_ROOT_PASSWORD=xxxxxx"
container_name: db
volumes:
- "./mysql/db:/var/lib/mysql"
user: "1000:50"
restart: always
$ docker-compose run db
2017-01-17 12:16:50 139770370467776 [Note] mysqld (mysqld 10.1.19-MariaDB-1~jessie) starting as process 1 ...
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: The InnoDB memory heap is disabled
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Using Linux native AIO
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Using SSE crc32 instructions
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2017-01-17 12:16:50 139770370467776 [Note] InnoDB: Completed initialization of buffer pool
2017-01-17 12:16:50 139770370467776 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 0 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2017-01-17 12:16:50 139770370467776 [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!
2017-01-17 12:16:50 139770370467776 [ERROR] Plugin 'InnoDB' init function returned error.
2017-01-17 12:16:50 139770370467776 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-01-17 12:16:50 139770370467776 [Note] Plugin 'FEEDBACK' is disabled.
2017-01-17 12:16:50 139770370467776 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2017-01-17 12:16:50 139770370467776 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-01-17 12:16:50 139770370467776 [ERROR] Aborting
I will try mount a Windows directory as a folder inside Docker VM VirtualBox.
It's work with Docker VM on VirtualBox.
Hello I'm facing the same trouble.
MariaDB 10.1.23 and 10.2.7
Windows 10 Pro 64 bits
Docker for Windows with Hyper-v docker
I would like to keep using Hyper-v, how can I solve this ?
Same here.
@sbernaldev and @Chrisly3ear, I believe the current workaround is to not use a host mounted volume with mariadb on Docker for Windows (docker-library/percona#42 (comment)). If you are using docker-compose, the volume that contains your database files will be kept around unless you explicitly delete it.
The other alternatives are to use Docker Toolbox instead of Docker for Windows, or to use a different SQL database (all versions of MySQL work with a host mounted volume in Docker for Windows, as does Percona 5.5 and 5.6).
I don't have any insight as to why Percona 5.7 and all versions of MariaDB fail when using a host mounted volume on Docker for Windows. I am too unfamiliar with their code to find and fix the issue whether it is in MariaDB/Percona or Docker for Windows.
Having the same issue here
+1
Docker for Windows based on Hyper-V is a native Windows 10 docker solution. Being able to mount custom persistent storage from host is in my opinion crucial.
As a temporary solution, you can do so(in your docker-compose.yml) this is solution for laradoc package:
#- ${DATA_SAVE_PATH}/mariadb:/var/lib/mysql
- mariadb:/var/lib/mysql
This has to be a mariadb issue. In my compose file for my phpfpm service use:
volumes:
- ./public:/usr/share/nginx/html
which works
inspect shows:
"Mounts": [
{
"Type": "bind",
"Source": "/E/docker/01_testing/my_first_docker-compose/public",
"Destination": "/usr/share/nginx/html",
"Mode": "rw",
"RW": true,
"Propagation": "rprivate"
}
...
"Volumes": {
"/usr/share/nginx/html": {}
},
I can modify the files on the host side on the volume mapping everything works as expected.
when I try the same for mariadb service there are problems, for my db service:
volumes:
- ./data:/var/lib/mysql
but when I up the mariadb compose I get:
mysql_1 | 2017-12-12 9:53:49 139728345196416 [ERROR] InnoDB: Write to file ./ibdata1 failed at offset 0, 1048576 bytes should have been written, only 0 were written. Operating system error number 22. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
mysql_1 | 2017-12-12 9:53:49 139728345196416 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
mysql_1 | 2017-12-12 9:53:49 139728345196416 [ERROR] InnoDB: Could not set the file size of
./ibdata1'. Probably out of disk space
inspecting the container shows:
"Mounts": [
{
"Type": "bind",
"Source": "/E/docker/02_services/mariaDb/data",
"Destination": "/var/lib/mysql",
"Mode": "rw",
"RW": true,
"Propagation": "rprivate"
}
...
"Volumes": {
"/var/lib/mysql": {}
},
The service did write in to the mapped volume ./data:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 12/12/2017 10:53 AM mysql
-a---- 12/12/2017 10:53 AM 16384 aria_log.00000001
-a---- 12/12/2017 10:53 AM 52 aria_log_control
-a---- 12/12/2017 10:53 AM 0 ibdata1
I have also tried using docker run with -v and I get the same outcome.
Interestingly enough, as neuotq suggested if you use the docker internal volumes, then it works.
Same issue here, this is critical bug honestly, any solutions?
@sameronline yes, see #95 (comment)
Essentially, the best solution is to put /var/lib/mysql in a volume on your Docker VM (managed via docker volume xyz commands) instead of trying to share those files directly all the way back to your Mac or Windows host filesystem.
Same here on Mac! This is an critical issue.
Yeah, just use a named volume and connect it to more than one container. However, note that using a named volume already makes the database persistent -- the volume will outlive the container by itself without any additional intervention.
Seeing a similar issue with mariadb10.2.X
I'm using a Dockerfile (not docker-compose.yml) to create a standalone MariaDB instance that looks like this currently:
FROM mariadb:10.2
LABEL maintainer="me@domain.com"
# ENVIRONMENT VARIABLES
ENV MYSQL_ROOT_PASSWORD = XXX
ENV MYSQL_DATABASE = XXX
ENV MYSQL_USER = XXX
ENV MYSQL_PASSWORD = XXX
ENV MYSQL_ALLOW_EMPTY_PASSWORD = no
ENV MYSQL_RANDOM_ROOT_PASSWORD = no
# DATABASE SQL FILE(S)
VOLUME ${pwd}/data:/var/lib/mysql
EXPOSE 3306
I have specified a single VOLUME that is my D:\ drive, not the hosts C:\
Builds fine, no errors, but using this docker run command:
docker run -p 3306:3306 --name mariadb -v ${pwd}/data:/var/lib/mysql stevenwillett/mariadb
The terminal output on run and errors are:
PS D:\OneDrive\Projects\XAMPP\htdocs\BitBucket\docker_projects\base_templates\mariadb> docker run -p 3306:3306 --name mariadb -v ${pwd}/data:/var/lib/mysql stevenwillett/mariadb
2018-03-10 11:11:46 140267705505664 [Note] mysqld (mysqld 10.2.13-MariaDB-10.2.13+maria~jessie) starting as process 1 ...
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Uses event mutexes
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Compressed tables use zlib 1.2.8
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Using Linux native AIO
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Number of pools: 1
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Using SSE2 crc32 instructions
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Completed initialization of buffer pool
2018-03-10 11:11:46 140266967877376 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-03-10 11:11:46 140267705505664 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 0 pages than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2018-03-10 11:11:46 140267705505664 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2018-03-10 11:11:46 140267705505664 [Note] InnoDB: Starting shutdown...
2018-03-10 11:11:46 140267705505664 [ERROR] Plugin 'InnoDB' init function returned error.
2018-03-10 11:11:46 140267705505664 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-03-10 11:11:46 140267705505664 [Note] Plugin 'FEEDBACK' is disabled.
2018-03-10 11:11:46 140267705505664 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2018-03-10 11:11:46 140267705505664 [ERROR] Unknown/unsupported storage engine: InnoDB
2018-03-10 11:11:46 140267705505664 [ERROR] Aborting
Environment Details:
- W10 Pro (Hyper-V)
- Docker CE (Version 17.12.0-ce-win47 (15139))(stable edition)
Any pointers to a solution when using a Dockerfile and not docker-compose.yml file appreciated.
@StevenWillett, the VOLUME line you declare is probably not doing what you think it is doing (see volumes). It is creating a folder at the path /data:/var/lib/mysql/ in the container. VOLUME in a Dockerfile can only declare a directory as a volume and cannot pre-seed where to mount that volume on run.
To use the already defined volume on Docker for Windows you have to use a named volume like @tianon suggested in the comments above yours.
$ docker run -d -p 3306:3306 --name mariadb -v mysql-data:/var/lib/mysql stevenwillett/mariadb
$ # to see the volume
$ docker volume lsUnfortunately, you cannot mount the folder for MariaDB to the host using Docker for Windows because it presents the shared files/folders permissions to the Linux container as root owned with writable only by root (755).
See also docker-library/percona#42 (comment).
Thanks, @yosifkit,
I have managed to get the DB file mapping to work from the container to the Host this evening in fact.
You also helped me free up 3GB of space by clearing my old volumes docker volume prune.
For those interested or facing similar issue ${pwd} is your friend here:
Dockerfile: (Note: removal of VOLUME entirely)
FROM mariadb:10.2
LABEL maintainer="me@domain.com"
RUN apt-get update && apt-get upgrade -y
#RUN apt-get install nano
# ENVIRONMENT VARIABLES
ENV MYSQL_ROOT_PASSWORD some_password
ENV MYSQL_DATABASE some_db_name
ENV MYSQL_USER some_user
ENV MYSQL_PASSWORD some_password
# UPDATE BIND ADDRESS TO ALLOW REMOTE ACCESS (USE A FIREWALL TO MANAGE TRAFFIC)
RUN sed -Ei 's/#bind-address\s+=\s+127.0.0.1/bind-address=0.0.0.0/g' /etc/mysql/my.cnf
EXPOSE 3306
NOTES: Notice I have fully removed the VOLUME option in the Dockerfile as there appears to be a bug with this, plus my docker run command's -v (volume) mapping is overriding this anyhow it would appear.
Docker run command:
docker run -d -p 3306:3306 --name mariadb --restart unless-stopped -v ${pwd}/data/mariadb/base-db:/var/lib/mysql stevenwillett/mariadb
You will most likely want to also add the run command option for --network to allow container linking.
-network test-docker-network
So the updated docker run command would be something like:
docker run -d -p 3306:3306 --name mariadb --restart unless-stopped --network test-docker-network -v ${pwd}/data/mariadb/base-db:/var/lib/mysql stevenwillett/mariadb
If anyone is able to achieve the below run command option as part of the Dockerfile build I would be grateful to hear how instead of needing to include as part of the docker run command.
-v ${pwd}/data/mariadb/base-db:/var/lib/mysql
What I have found out through trying to resolve this issue on Windows is that ${pwd} copies from the container any files of the -v mapped directory.
This has been something I could not find any documentation for. (maybe my search terms)
I hope the above helps someone else facing a similar issue.
Correct me if I'm wrong but it seems since 17.06 docker changed docker system prune, so it now cleans up volumes only when running with --volumes flag. So if you run a container with a named volume (i.e. VOLUME in image's Dockefile) and then you kill it, you won't lose any data until you run docker system prune --volumes. That's definitely an improvement in my opinion but not really a solution to:
Could not set the file size of './ibdata1'. Probably out of disk space
I want to run docker system prune --volumes to clean up volumes I used for tests without worrying that I might lose some important data. It's still not clear to me why this bug happens with mariadb, I never had any bind mounts issues with other images. Is this possibly related to innodb + docker driver storage? Anyway, I think it's a critical issue and we should reopen the issue (or have a new one).
@csandanov, using a named volume is basically the only option to keep the database files when running MariaDB on Docker for Windows since the host-shared folder presented to the container does not behave in a standard way.
PS C:\Users\sauron> docker run -it --rm -v C:\Users\sauron\tmp\:/my-tmp/ -u 1000:50 debian
I have no name!@664436f5a386:/$ id -u
1000
I have no name!@664436f5a386:/$ id -g
50
I have no name!@664436f5a386:/$ cd /my-tmp/
$ # it presents as a root owned folder but doesn't allow chown/chmods
I have no name!@664436f5a386:/my-tmp$ ls -al
total 4
drwxr-xr-x 2 root root 0 Apr 10 20:44 .
drwxr-xr-x 1 root root 4096 Apr 10 20:47 ..
$ # and doesn't respect the permissions that it presents
I have no name!@664436f5a386:/my-tmp$ touch foo
I have no name!@664436f5a386:/my-tmp$ ls -l
total 0
-rwxr-xr-x 1 root root 0 Apr 10 20:48 foo
I have no name!@664436f5a386:/my-tmp$Hello,
It's incredible that the problem persists for a year and nobody has managed to find a solution!
MariaDb / docker are not compatible when we need to map a volume to the host? Which is the more important thing for a container like a database.
Docker and MariaDB work fine together; the bit that doesn't work is the custom filesystem employed by Docker for Windows and Docker for Mac for sharing files across the VM boundary, which is not all that surprising for a database, which often use features like mmap for performance but thus also require support from the underlying filesystem. There are many reports of similar issues with vboxsf, for example.
Are there any requests to solve this behaviour? How would you recommend working with them toghether then?
Any fixes would have to happen either in Docker's shared filesystem or in MariaDB itself (not something we can really fix in this Docker image), so I'd recommend checking their respective upstream bugtrackers for any discussion of fixing the problem.
Reported in MariaDB's JIRA: https://jira.mariadb.org/browse/MDEV-16015
Thks a lot^^ @csandanov
I ran into this issue recently when trying to use a newer image of MariaDB. I tried upgrading to 10.2-3.1.3 but I encountered the issue in this thread.
I then rolled back to 10.1-2.1.0 and the issue was gone.
I am using Docker Version 18.03.1-ce-win65 (17513)
Channel: stable
93354b3
Alright, for those who don't like to spend 2+ hours around this issue like I did, here's what fixed it for me (Windows 10, Docker with Hyper-V):
docker-compose.yml:
version: "3"
services:
db:
image: mariadb:10.1
restart: unless-stopped
volumes:
- ./config:/etc/mysql/conf.d
- ./data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=xxxxxxx
- MYSQL_PASSWORD=xxxxxxx
- MYSQL_DATABASE=xxxxxxx
- MYSQL_USER=xxxxxxx
command:
mysqld --innodb-flush-method=littlesync --innodb-use-native-aio=OFF --log_bin=ON
conf.d/local.cnf
[mysqld]
innodb_flush_method=littlesync
innodb_use_native_aio=OFF
log_bin=ON
Please fix this ASAP!
Still receiving this error on Docker for Windows. Fix above didn't work for me @darkguy2008
Mariadb: 10.3.7
Docker version: 18.03.1-ce, build 9ee9f40
Initializing database
2018-05-27 23:36:07 0 [Warning] InnoDB: Retry attempts for writing partial data failed.
2018-05-27 23:36:07 0 [ERROR] InnoDB: Write to file ./ibdata1 failed at offset 0, 1048576 bytes should have been written, only 0 were written. Operating
system error number 22. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2018-05-27 23:36:07 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
2018-05-27 23:36:07 0 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space
@darkguy2008 solution worked for me on Windows 8.1 Pro - Docker Toolbox. Wasted 2 hours anyway :(
Mariadb: 10.1.34
Docker version: 18.03.1-ce, build 9ee9f40
same here
κ³ μ³μ£ΌμΈμ
got error (
command
docker run --name mariadb -d -v D:\Projects\docker\docker-qub:/var/lib/mysql -e MYSQL_USER=user -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=address -e MYSQL_ROOT_PASSWORD=password mariadb
docker logs f7e30
2018-07-07 18:54:11 0 [Note] mysqld (mysqld 10.3.8-MariaDB-1:10.3.8+maria~jessie) starting as process 1 ...
2018-07-07 18:54:11 0 [Note] InnoDB: Using Linux native AIO
2018-07-07 18:54:11 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-07-07 18:54:11 0 [Note] InnoDB: Uses event mutexes
2018-07-07 18:54:11 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
2018-07-07 18:54:11 0 [Note] InnoDB: Number of pools: 1
2018-07-07 18:54:11 0 [Note] InnoDB: Using SSE2 crc32 instructions
2018-07-07 18:54:11 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2018-07-07 18:54:11 0 [Note] InnoDB: Completed initialization of buffer pool
2018-07-07 18:54:11 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-07-07 18:54:11 0 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 0 pages than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2018-07-07 18:54:11 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2018-07-07 18:54:11 0 [Note] InnoDB: Starting shutdown...
2018-07-07 18:54:11 0 [ERROR] Plugin 'InnoDB' init function returned error.
2018-07-07 18:54:11 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-07-07 18:54:11 0 [Note] Plugin 'FEEDBACK' is disabled.
2018-07-07 18:54:11 0 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2018-07-07 18:54:11 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2018-07-07 18:54:11 0 [ERROR] Aborting
docker ps
f7e30a92ad33 mariadb "docker-entrypoint.sβ¦" 3 minutes ago Exited (1) About a minute ago
docker info
Containers: 68
Running: 28
Paused: 0
Stopped: 40
Images: 47
Server Version: 18.03.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
NodeID: umg8s7ejhmcybmvotfukeyr82
Is Manager: true
ClusterID: 9nvcjrfg2x4g1vcjf53pj49q5
Managers: 1
Nodes: 1
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 10
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Force Rotate: 0
Autolock Managers: false
Root Rotation In Progress: false
Node Address: 192.168.65.3
Manager Addresses:
192.168.65.3:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.87-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 3
Total Memory: 4.569GiB
Name: linuxkit-00155d006a66
ID: MPAV:XNLY:FH2E:XCK4:KCUE:C647:3JMR:43PM:LR5A:ECCI:WFHS:RDLT
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 84
Goroutines: 210
System Time: 2018-07-07T19:08:46.9034987Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
@vzakusylo, We recently added #168 which should make sharing a directory from a windows host possible. Try the following (I don't have a host with Docker for Windows at the moment, but it worked when I last checked):
$ # also updated to specify a version of mariadb so that things don't break when latest becomes 10.4
$ docker run --name mariadb -d -v D:\Projects\docker\docker-qub:/var/lib/mysql -e MYSQL_USER=user -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=address -e MYSQL_ROOT_PASSWORD=password mariadb:10.3 --innodb-flush-method=fsyncFor future users that are using docker-compose it would be adding --innodb-flush-method=fsync to the command.
@yosifkit thanks for this. It works for me.
My docker-compose.yml
version: '3.1'
services:
mariadb:
image: mariadb:10.3
volumes:
- ./docker/mariadb:/docker-entrypoint-initdb.d/
- ./var/mariadb:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: '${MYSQL_ROOT_PASSWORD}'
MYSQL_DATABASE: '${MYSQL_DATABASE}'
MYSQL_USER: '${MYSQL_USER}'
MYSQL_PASSWORD: '${MYSQL_PASSWORD}'
ports:
- '${MYSQL_PORT:-3306}:3306'
command:
'mysqld --innodb-flush-method=fsync'@darkguy2008 Very Thanks! It's work!!
@darkguy2008 Nice temp solution! @yosifkit thanks for all!
Waiting for a solid solution on future versions...
I changed .env file:
DATA_PATH_HOST=~/.laradock/data
-->
DATA_PATH_HOST=~/laradock_data
and error fixed.
@darkguy2008 solution works perfectly for my environment (Win10 Pro / Hyper-V)
And alternative way is write settings to only \laradock\mariadb\my.cnf.
(Need rebuild image, not only remove container.)
Hope this helps.
Issue is still active for mariadb:10.4.8-bionic with Windows 10.
Issue is still active for latest image with macOS 10.15.1.
@darkguy2008 Thanks sir :) π
Same issue here on Windows, Docker for Desktop.
Just a note to others.
Adding --innodb-flush-method=fsync does solve the issue (as clarified by @yosifkit and @peter-gribanov previously in this issue), with one caveat...
If you're using WSL 2, and try to use something like:
- "/mnt/s/Development/Docker/Phabricator/MariaDB/data:/var/lib/mysql"
You'll still run in to this issue... You'll need to change it to look like:
- "S:\Development\Docker\Phabricator\MariaDB\data:/var/lib/mysql"
Using the Windows formatted directory location.
So far, I haven't had any success with the above approaches except for using docker named volumes, which is more of a workaround than a solution.
I prefer to use bind mounts (i.e. "./mysql/db:/var/lib/mysql") since the development database can be easily coupled with the project for development purposes.
So, I've downgraded MariaDB to 10.1 from 10.2, and it works.
I guess something was introduced from 10.2 which caused this issue.
Again, this is just another workaround, but if I had to choose between the two, I'd prefer downgrading MariaDB version, compared to using docker named volumes.
Did a Docker update today. Now none of these solutions work on Windows.
@pkscout did you check this solution?
Docker 2.0.0.3
mariadb 10.5
stably works on Windows
I had the same issue, what may happen is volumes are having so much space on your Docker so just delete it
docker system prune --volumes
and then start your container back again
I had the same issue, what may happen is volumes are having so much space on your Docker so just delete it
docker system prune --volumesand then start your container back again
Thanks a lot, this solved my problem on Mac OS :D
You are welcome Glad i helped you solve the problem
Does anyone have any idea for a workaround when using Docker on Windows with WSL 2.
Trying to install Seafile with following yml
`version: '2.0'
services:
db:
image: mariadb:10.1
container_name: seafile-mysql
environment:
- MYSQL_ROOT_PASSWORD=db_dev # Requested, set the root's password of MySQL service.
- MYSQL_LOG_CONSOLE=true
volumes:
- /opt/seafile-mysql/db:/var/lib/mysql # Requested, specifies the path to MySQL data persistent store.
networks:
- seafile-net
memcached:
image: memcached:1.5.6
container_name: seafile-memcached
entrypoint: memcached -m 256
networks:
- seafile-net
seafile:
image: seafileltd/seafile-mc:latest
container_name: seafile
ports:
- "80:80"
- "443:443" # If https is enabled, cancel the comment.
volumes:
- /opt/seafile-data:/shared # Requested, specifies the path to Seafile data persistent store.
environment:
- DB_HOST=db
- DB_ROOT_PASSWD=db_dev # Requested, the value shuold be root's password of MySQL service.
- TIME_ZONE=Etc/UTC # Optional, default is UTC. Should be uncomment and set to your local time zone.
- SEAFILE_ADMIN_EMAIL=me@example.com # Specifies Seafile admin user, default is 'me@example.com'.
- SEAFILE_ADMIN_PASSWORD=asecret # Specifies Seafile admin password, default is 'asecret'.
- SEAFILE_SERVER_LETSENCRYPT=false # Whether to use https or not.
- SEAFILE_SERVER_HOSTNAME=docs.seafile.com # Specifies your host name if https is enabled.
depends_on:
- db
- memcached
networks:
- seafile-net
networks:
seafile-net:`