[WSL2] Permissions problem with mounted windows volume

[verglor]

• I have tried with the latest version of my channel (Stable or Edge)
• I have uploaded Diagnostics
• Diagnostics ID: 83925FF1-D3EE-4CBF-A54A-68AC6D60F69F/20191018171529

Expected behavior

Starting official mysql container with empty data directory (/var/lib/mysql) mounted from windows folder should initialize db without error.

Actual behavior

Container fails to start with [ERROR] [MY-010295] [Server] Could not set file permission for ca.pem during db initialization.

Information

• Windows Version: Win 10 Pro x64 Insider Preview 18985
• Docker Desktop Version: 2.1.4.0
• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: no
• WSL machine: Ubuntu 18.04

Steps to reproduce the behavior

Having empty directory c:\tmp\mysql:

• in wsl context it is failing:

> docker run --rm -it -v c:\tmp\mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root mysql:8.0
Initializing database
mysqld: Cannot change permissions of the file 'ca.pem' (OS errno 1 - Operation not permitted)
2019-09-28T22:35:54.454655Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8161)
2019-09-28T22:35:54.454677Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 431 (requested 4000)
2019-09-28T22:35:54.454966Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-09-28T22:35:54.455180Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.17) initializing of server in progress as process 29
2019-09-28T22:35:54.464556Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2019-09-28T22:35:59.683202Z 0 [ERROR] [MY-010295] [Server] Could not set file permission for ca.pem
2019-09-28T22:35:59.683277Z 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.
2019-09-28T22:35:59.683652Z 0 [ERROR] [MY-010119] [Server] Aborting
2019-09-28T22:36:01.382866Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.17)  MySQL Community Server - GPL.

• in default context it starts OK:

> docker run --rm -it -v c:\tmp\mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root mysql:8.0
Initializing database
2019-09-28T22:33:00.121888Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-09-28T22:33:00.121952Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.17) initializing of server in progress as process 28
2019-09-28T22:33:05.719551Z 5 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
2019-09-28T22:33:07.459395Z 0 [System] [MY-013170] [Server] /usr/sbin/mysqld (mysqld 8.0.17) initializing of server has completed
Database initialized
MySQL init process in progress...
MySQL init process in progress...
2019-09-28T22:33:09.391389Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-09-28T22:33:09.391464Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.17) starting as process 80
2019-09-28T22:33:10.357625Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2019-09-28T22:33:10.365312Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2019-09-28T22:33:10.397449Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.17'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server - GPL.
2019-09-28T22:33:10.457199Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: '/var/run/mysqld/mysqlx.sock'
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.

2019-09-28T22:33:16.856704Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.17)  MySQL Community Server - GPL.

MySQL init process done. Ready for start up.

2019-09-28T22:33:17.203008Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-09-28T22:33:17.203083Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.17) starting as process 1
2019-09-28T22:33:18.076819Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2019-09-28T22:33:18.084513Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2019-09-28T22:33:18.142383Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.17'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.
2019-09-28T22:33:18.219024Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: '/var/run/mysqld/mysqlx.sock' bind-address: '::' port: 33060

[verglor]

I have even tried granting full control to Everyone on c:\tmp\mysql but the result is the same.

[vadim888]

Same problem. Have you resolved this issue?

[nunix]

I'm having the similar behavior with a Jekyll container where the _site/CNAME file generated is triggering an error.

I started the container from Powershell and checked the permissions with WSL (ubuntu) for the file, here are the results:

• WSL Docker daemon: 777 -> ends with an error, stops the container
• Windows Docker daemon: 755 -> succeeds, the container keeps running

Running the same Docker command from WSL with the WSL Docker daemon running, ends up working fine and the file permissions are 744

so it seems to have some kind of issue when running the Docker commands from Powershell with the WSL Docker daemon active and instead of "not enough permissions", I guess it's the inverse, it's too open (full access)

[simonferquel]

I think it is because of the way WSL handles permission mappings when mounting windows files.
For both performance, and file system semantic consistency (case sensitivity atomicity of operations etc), I strongly suggest wsl2 users to only mount files from their wsl distros and avoid leveraging windows file mounts.

[dauxuanngo]

I have Same problem.
I changed the image version from mysql:5.7 to mysql:5.7.16 and now it is working fine.

[tingjhenjiang]

same problem when I was running wsl 2 kernel of Docker for Windows ( Docker Desktop Community 2.2.0.0 42247 ), Windows 10 19041.21.

[da-mask]

I'm suffering the same. Windows 19541, docker desktop 2.1.7.0 edge.

[davclark]

It seems like there should be a fairly simple fix here, which would be to add the metadata flag to the drvfs mount for the Windows drive. Is there a reason this absolutely can't be done? Is there a way I could modify the docker configuration or perhaps the wsl2 runtime / distro (moby?) that's running the docker daemon?

[strarsis]

Mounting files from "normal" Windows file system into WSL/Docker is the main reason for me to actually use WSL. Otherwise, I could use a linux VM with Hyper-V. I/O performance and compatibility (ownership, permissions) have always been the development bottleneck, either from folder shares, SMB, NFS, etc.

[davclark]

With the arrival of 2.2.3 this morning, and the imminent default of WSL2 for everyone in (I think) June, I figured I'd better start working at least on a hack for this. It turns out my idea does seem to work. You can do something like this (PS> is your powershell prompt on the Windows host, # is the prompt you get inside the docker-desktop distro):

PS> wsl -d docker-desktop
# cat wsl.conf  # make sure this looks right
# cat >> wsl.conf
options = metadata

This seems to fix some of my issues. It is sadly, quite slow - not sure if that's because of the metadata flag.

[simonferquel]

It is mainly slow because mounting files from Windows is very slow, compared to mountings files living in a wsl distro.

The prefered workflow is to use docker from your distro of choice and store bind mount sources (source code, database data etc.) from this distro file system instead of from Windows.

If you use vs code, you can even use "Remote to WSL" extension to run vs code server within WSL and the UI on Windows.

[Silic0nS0ldier]

Just to clarify @davclark 's workaround, wsl.conf refers to /etc/wsl.conf. Happy to say this has worked for me.

Understandable that the file mounts to Windows are slow. The team at Microsoft noted as much for the jump from WSL1 to WSL2, and that it is an area they are working on. Even without Docker in the mix, IO that crosses the WSL2 VM boundary is slow. git status as an example in Ubuntu on a Windows-side git repo is extremely slow (proportional to the repo size) and in older builds could cause the mount to break.
Only thing holding me back from moving development into WSL is fear of data loss, I've had distros spontaneously break in WSL2 in the past.

[davclark]

It is mainly slow because mounting files from Windows is very slow, compared to mountings files living in a wsl distro.

Thank you @simonferquel and @Silic0nS0ldier for clarifying about file performance. Bummer! IO performance was THE big thing I was hoping for with WSL2. I suppose mounting from another WSL2 filesystem has better performance?

The prefered workflow is to use docker from your distro of choice and store bind mount sources (source code, database data etc.) from this distro file system instead of from Windows.

I've experimented with this, and it works. At Gigantum, we have an Electron GUI that manages docker for you - it's running on the Windows host, and communicates with docker using the named pipe (npipe). Is there any way to specify a mount in a wsl distro in this scenario?

If you use vs code, you can even use "Remote to WSL" extension to run vs code server within WSL and the UI on Windows.

Unfortunately, many of our users are not developers, per se - they may often be researchers who have just learned a bit of Python or R. So, I also worry about file access for this kind of user: "smart, but not a developer".

Anyway, this is all getting a bit far afield of the initial issue, but I wanted to clarify that the needs here can extend beyond your normative developer use case!

[simonferquel]

Mounting from another WSL2 distro filesystem has the best performance profile (+ permission, inotify, etc).
Unfortunately, you can't mount a wsl distro path from windows. There are 2 workarounds though:

• shellout with something like "wsl -d my-distro docker run -v /some/dir:/some/where my-image".
• run an X server on windows, and run the gui from the WSL distro.
  If we get popular demand for this one, we'll probably work on something for better supporting this.

We agree that user education is an issue there. We will try our best to bring docs, guidance etc. to get the most of Docker Desktop and WSL 2 in the future.

[strarsis]

Is this new issue related (WSL 1 though)?: #6209

[davclark]

I saw that #6284 was closed. Should that also address this issue?

While I'm here: @simonferquel I have to say that you are quickly becoming my favorite Docker programmer. Specifically, I admire the professionalism you exhibited in that issue!

[Ageraluon]

As to my knowledge, docker for win always mounts outside folders with 755 root:root permissions, hence many programs, especially those that run outside of root context break. Has that changed with WSL2?

[simonferquel]

Mounting a directory from a WSL2 distro keeps the mode/owner untouched (like it does on Linux).

[mhamri]

@simonferquel I am experiencing something different.

given this

ARG password=Abcd1234@@

FROM mcr.microsoft.com/mssql/server as base
#the base is ubuntu, we need to use ubuntu image

ARG password

ENV ACCEPT_EULA=Y
ENV SA_PASSWORD=${password}

ENV DATA_PATH=/var/opt/mssql/data
ENV BACKUP_PATH=/var/opt/mssql/backup

VOLUME ["${DATA_PATH}" , "${BACKUP_PATH}" ]
USER root
RUN chmod 666 "${DATA_PATH}" && chown mssql "${DATA_PATH}" && chown mssql "${BACKUP_PATH}" && chmod 666 "${BACKUP_PATH}"

USER mssql

EXPOSE 1433

HEALTHCHECK --interval=10s --timeout=5s --start-period=10s --retries=10 \
    CMD /opt/mssql-tools/bin/sqlcmd -S . -U sa -P ${SA_PASSWORD} -Q "select 0;" || exit 1

CMD [ "/opt/mssql/bin/sqlservr" ]

if attach to the container and check the permission of the backup and data folder, they are still root

using the VOLUME inside a docker file with WSL2 isn't supported?

[simonferquel]

@mhamri note that your dockerfile is executed while building the container image. However, if at runtime you mount a volume in there, the permissions set on the mount source overrides the mountpoint permissions.

If you are using a bind mount (mounting a wsl dir there), you need to do the chmod 0666 on your directories before mounting them.

If you are using a named volume, you should initialize it using a temporary container (like docker run --rm -v volume-name:/data alpine chmod 666 /data)

[mhamri]

@simonferquel you are right. but I see a behavior different in here. before WSL2 the previous docker file doesn't fail. but in WSL2 it fails. so thinking more about your comment I thought the problem should be that the folder doesn't exist in first place so the mapped folder in volumes should be created with default root permission.

so I changed the build script to this

ARG password=Abcd1234@@

FROM mcr.microsoft.com/mssql/server as base
#the base is ubuntu, we need to use ubuntu image

ARG password

ENV ACCEPT_EULA=Y
ENV SA_PASSWORD=${password}

ENV DATA_PATH=/var/opt/mssql/data
ENV BACKUP_PATH=/var/opt/mssql/backup

RUN mkdir -p "${DATA_PATH}" && mkdir -p "${BACKUP_PATH}"
VOLUME [ "${DATA_PATH}", "${BACKUP_PATH}" ]

EXPOSE 1433

HEALTHCHECK --interval=10s --timeout=5s --start-period=10s --retries=10 \
    CMD /opt/mssql-tools/bin/sqlcmd -S . -U sa -P ${SA_PASSWORD} -Q "select 0;" || exit 1

CMD [ "/opt/mssql/bin/sqlservr" ]

and it works.

[simonferquel]

That is because when mounting files/directories from windows which have a different permission semantic, we expose everything to Linux as 777, and let Windows enforce permissions (if your windows account does not have sufficient rights, Linux will still try to open the file, but Windows will report an access denied error)

[docker-robott]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked