on windows, cannot start a container with host directory as /var/lib/mysql mount

[powernic]

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

[yosifkit]

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.

[powernic]

@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.

[powernic]

It's work with Docker VM on VirtualBox.

[imsergiobernal]

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 ?

[ChrislyBear-GH]

Same here.

[yosifkit]

@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.

[sameronline]

Having the same issue here

[shengnian]

+1

[lmurawsk]

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.

[neuotq]

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

[ericrector]

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.

[sameronline]

Same issue here, this is critical bug honestly, any solutions?