Machine: Unable to access mounted volume when directory contains space or 'ø' character under c:\\Users on Windows

[ghost]

I have trouble mounting a shared volume with Docker on Windows, because the shared volume path is hardcoded to c:Users on Windows. The relevant code can be seen here:
https://github.com/docker/machine/blob/master/drivers/virtualbox/virtualbox.go#L368

Since this is the directory I want to refer to from the docker container, I get problems with the space and 'ø' character: C:UsersAndreas Røsdal

Can you please make the path for shareDir configurable?

This is the error message:
unable to prepare context: unable to evaluate symlinks in context path: readlink C:UsersAndreas Røsdal: The system cannot find the file specified.
Error response from daemon: Cannot start container 2b7d5d39283df9b2265df4264adac3b3105642050f396f58fe23055e4472412d: stat /c/Users/Andreas Røsdal//bin/webapps/ROOT: protocol error

[tiangolo]

@andreasrosdal I made a script to make Docker Toolbox work with Babun and it sets up shared folders and volumes, you may want to try: https://github.com/tiangolo/babun-docker

Or maybe you may want to read how volumes work with VirtualBox / Toolbox and Windows, that could help you track down / solve your problem: https://github.com/tiangolo/babun-docker/wiki/Docker-Volumes-with-Babun

[ghost]

@tiangolo Unfortunately, this does not solve the problem that the path of volumes is hard-coded to C:Users on Windows. This should be made configurable, and is listed as a TODO item in the source code I linked to. Thanks for the help so far, though.

[Skarlso]

Hi.

Please note this passage in the doc of sharing volumes in docker.

Note: If you are using Docker Machine on Mac or Windows, your Docker daemon only has limited access to your OS X/Windows filesystem. Docker Machine tries to auto-share your /Users (OS X) or C:Users (Windows) directory - and so you can mount files or directories using docker run -v /Users/:/ ... (OS X) or docker run -v /c/Users/:/

• Docker Managing Volumes Documentation

[ghost]

@Skarlso The problem with auto-mounting C:Users on Windows, is that my home directory is C:UsersAndreas Røsdal - note the space and 'ø' character. Mounting this directory does not work either due to the space or 'ø' character, and gived the error in this bugreport.

[Skarlso]

So your problem really is that you have space and a special character in your user name, right?

Which means you should really change the title of this bug report. :-)

So to clarify this. It won't change from c:User for a time, which means your bug's header should not say make it configurable but say that you can access your user folder because it's not escaped correctly. Which is an entirely different problem.

[ghost]

@Skarlso Thanks, description updated. Yes, so there are two problems:

• The mounted volume directory is hardcoded to c:Users on Windows. For example, I have my git repo on C:git at the moment, and want to mount that directory into the docker container.
• Mounting directory names containing space or 'ø' character does not work under c:Users on Windows.

[Skarlso]

You are most Welcome!

[Skarlso]

Hey @andreasrosdal. Could you please provide a bit more information? What command are you running? When, and how are you trying to mount / reach your folder?

Cheers!

[tiangolo]

Hardcoded volumes

@andreasrosdal: My program babun-docker actually solves the hardcoded mounting volumes problem without modifying Docker Machine's code.

It creates a shared folder in your VirtualBox machine for each of your drives, creates a directory for each of them inside the VM in the same part as Babun sees them in your local Windows (to allow using the -v $(pwd) trick) and mounts everything automatically (actually it even starts the Docker Machine VM and sets the environment). So, with that, you can work with Docker volumes in your Windows as if you were on Linux (as would be normal with Docker).

So, with babun-docker you would be able to use your C:\git directory, or directories from an external D:\ drive, etc. (e.g. my code is in D:\Sebastian\code)

But for that, you would need to use Babun instead of the Windows console or the default console in Docker Toolbox. They can coexist of course, but my program is made for Babun.

BTW, Babun is a Linux flavored terminal emulator for Windows, with git integrated, fancy autocompletion, etc.

---

What's the problem

Now, about the "Andreas Røsdal" directory:

Here's the problem, Windows encodes its system text using the encoding Windows-1252 (A.K.A. CP1252).

Linux uses UTF-8 that accepts the full base of Unicode.

So, when the Linux VM, or a Linux style terminal tries to find that directory it tries to find it using a UTF-8 encoding. And the two bytes that encode the character "ø" in UTF-8, seen as if they were Windows-1252 look like two characters: "ø". You can check it here: http://www.unicodetools.com/unicode/utf8-to-latin-converter.php

Note: Windows-1252 is an extended version of Latin-1, A.K.A. iso-8859-1, so you can assume they are "the same".

---

A test

BTW, I just tried it and my program (using Babun) didn't solve the problem of the directory with an "ø" character.

Here's what I did:

• I Created a directory in Windows with your user name and a subdirectory in:

D:\Users\user\Andreas Røsdal\mycontainer

• I added a text file named:

text_from_windows.txt

• From Babun I "entered that directory":

cd "D:\Users\user\Andreas Røsdal\mycontainer"

• Then I created a container named "and" that shared that directory as a volume and run forever:

docker run -d --name and -v "$(pwd):/app" debian bash -c "while true; do sleep 1; done"

• I entered that container in an interactive session:

docker exec -it and bash

• I entered the shared directory inside the container:

cd /app

• I checked with ls but there was no text_from_windows.txt file, so I created another one:

echo "text from linux" > text_from_linux.txt

After all the process, I ended up with two directories with two files under my Windows user directory:

D:\Users\user\Andreas Røsdal\mycontainer\text_from_windows.txt

and

D:\Users\user\Andreas Røsdal\mycontainer\text_from_linux.txt

Notice the "ø" character in the second directory being interpreted by Windows as encoded in Windows-1252 while in Linux, encoded in UTF-8 it would look OK.

Note: Windows-1252 and UTF-8 encode all the ASCII characters with the same one byte that ASCII encodes them, so that's why all ASCII characters "just work" everywhere.

---

Workaround

Making Linux understand Windows encoding dynamically (or vice versa) would be hard, it gives all that kind of problems while copying files with non ASCII characters too.

I would suggest you to use only ASCII characters for directory and file names, for example, I use "Sebastian" instead of "Sebastián".

If you can rename your username, that could work.

Otherwise I would suggest putting your code somewhere else, for example in C:\git or C:\code and use babun-docker.

---

Learn more

If you want to learn a bit more (the minimum) about encodings, you could read this post by Joel Spolsky, the creator of StackOverflow: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[Skarlso]

Or, when mounting the folder, like this ->

docker run -v c:\\Users\\Andreas Røsdal:/whatever

you can try escaping the space there with so ->

docker run -v c:\\Users\\Andres\ Røsdal:/whatever

Also, using ' helps.

docker run -v 'c:\\Users\\Andres Røsdal':'/whatever'

Try these please.

[tiangolo]

@Skarlso but the problem is related to the character encodings, not the space escaping.

Also, in my test, I already used your suggestion of using quotes to escape the space (it threw "space character related errors" when I didn't):

docker run -d --name and -v "$(pwd):/app" debian bash -c "while true; do sleep 1; done"

the -v "$(pwd):/app" translates to -v "/cygdrive/d/Users/user/Andreas Røsdal/mycontainer:/app".

But after that, the changing characters ("ø" becoming "ø") persisted.

[Skarlso]

Ahh okay, gotcha.

[Ralle]

It's not only directories but also filenames. I am writing code that takes files from a dump on a computer and indexes it in a database inside of Docker and I needed to make sure that file encodings worked but am unable to because of this issue. I can appreciate the complexity of the problem and wish there was some sort of solution. I thought Windows had a unicode API? Wouldn't files be saved with unicode names then?

[tiangolo]

@Ralle Here's what I would do:

• I would write the script in Python inside Windows.
• I would rename each file with Werkzeug's secure_filename, it will use a filename that's secure for the OS and that "as a plus" doesn't have any non ASCII characters, which is the point of using it: http://werkzeug.pocoo.org/docs/0.11/utils/#werkzeug.utils.secure_filename
• And then, after renaming them, I would submit those files to the Docker database.

Another simpler option you may try is with this: http://stackoverflow.com/a/2365444/219530
mystr.encode('ascii', 'ignore')

[Eneuman]

Since VS 2017 now support docker, this behavior have now become an even bigger problem.
Computers connected to a Azure AD, has there user profile path hardcoded by WIndows 10 and this can not be changed. So basicly, any Visual Studio 2017 user with a business computer (connected to Azure AD) that have a foreign character in their name, will not be able to use Docker in Visual Studio.

For more information about this, see here:
https://github.com/docker/compose/issues/5998

[JohnGalt1717]

Just ran into this too! Docker for Windows should map paths properly with -v. This should be a no-brainer.

[davidjrh]

Hi, I was suffering exactly this issue and my workaround was to create a SymLink. My user name created from the Azure AD is "AzureADDavidJRodríguezHerná", so my user folder is "C:UsersDavidJRodríguezHerná". When trying to run from VS2017 a docker for Windows containerized app, I was getting this error:

docker: Error response from daemon: error while creating mount source path '/host_mnt/c/Users/DavidJRodríguezHerná/vsdbg/vs2017u5': mkdir /host_mnt/c/Users/DavidJRodríguezHerná/vsdbg: permission denied.

Note that the resulting path used by Docker differs from the real one. So the trick is to create a symlink on the file system:

mklink C:\Users\DavidJRodr├¡guezHern├í C:\Users\DavidJRodríguezHerná /D

After doing that, I could start debugging the project from VS 2017 with no other issues.

[BobbyBabes]

Enclosing a volume mapping, in its entirety, with single quotes does the trick on Linux. For both paths below. Even with env vars substitution. And env vars left and right of the : are OK.
On Windows, specifying forward slashes, instead of backslashes in the paths also works.

In .env :

HTTPD_SVR_DOCUMENT_ROOT=/usr/share/nginx/html

In docker-compose.yml :

    volumes:
      - './test/Users/Andreas Røsdal/sites/document_root_01:${HTTPD_SVR_DOCUMENT_ROOT}/site_01/'
      - '../_wp/demos/Sixthavenue/:${HTTPD_SVR_DOCUMENT_ROOT}/sixth_avenue/'

Now (depending on your Windows) you could use Powershell's wslpath command to help you properly convert paths. If it is in your Windows build.: https://github.com/MicrosoftDocs/WSL/releases/tag/17046

https://blog.stangroome.com/2018/06/25/wslpath-and-mktemp/

[tthorleifson]

So, if you're running Docker (v. 2.1.0.1) on a Windows 10 desktop, it simply doesn't appear to be possible to _directly_ mount a Windows folder containing spaces in the path in a Linux-based Docker container using either the _-v_ or _--mount_ options with the docker run command at the cmd window or Windows PowerShell command prompt. Surrounding the Windows folder path with single or double quotes does not work. Escaping the spaces with a backslash does not work. (Docker on Windows 10 interprets a backslash as a line continuation character.)

A workaround that _does_ work is using the Windows command mklink to create a symbolic link that has a path with _no_ spaces to your source Windows folder that _does_ have spaces. Note that you'll have to execute the cmd window as administrator, so that you'll have permissions to create the symbolic link. Also note that you'll have to create a 'hard' symlink (the _/J_ option); 'soft' links (the _/D_ option) don't work, either.

Example:
Consider a source Windows folder with spaces in the path, e.g., _C:Usersmyuserwork space_. We'll create a 'hard' symlink to this folder with the path, _C:Usersmyuserworkspace_. (Note the removal of the space in the path.) In the cmd window (running as administrator):

mklink /J C:\Users\myuser\workspace "C:\Users\myuser\work space"

Note the use of double quotes around the source folder that has a space in the path. With the 'hard' symlink created, we can now fire up a Docker container that mounts the Windows folder via the symlink. In the cmd window:

docker run -it --mount type=bind,source=C:/Users/myuser/workspace,destination=/home/myuser/workspace --name mycontainer mycompany/dockerimages:linuximage

where _/home/myuser/workspace_ is the container directory in which I'm mounting the source Windows folder, _mycontainer_ is the name I'm assigning to the container, and _mycompany/dockerimages:linuximage_ is the Docker image I'm pulling from to create the container.

I hope this helps Windows users trying to link to a Windows folder containing spaces in the path; Lord knows I've struggled with it. Docker Dev Team, it'd sure be _nice_ if you threw us poor Windows users a bone. And, I'm sorry, I don't know whether this will do anything at all for Docker users with unusual characters, e.g., "ø", in their Windows folder paths.

[klauer]

@tthorleifson I've been struggling with the volume with spaces issue on Windows, too. I initially assumed I needed quotes around each portion - i.e., -v "a":"b" - but it turns out -v "a:b" is correct. This example, with Docker v2.1.0.2 on Windows 10 using cmd, works for me (note the 2nd -v):

docker run -v "C:\Repos\ads-deploy\tools\:/ads-deploy/tools" -v "C:\Repos\Annoying Directory With Spaces\TwinCAT Project 99\:/reg/g/pcds/epics/ioc/TwinCAT Project 99" -i pcdshub/ads-deploy:latest "find '/reg/g/pcds/epics/ioc/TwinCAT Project 99' -type f -name '*.tsproj' -exec pytmc pragmalint '{}' \;"

Quotes around each path results in docker: invalid reference format: repository name must be lowercase. as it fails to parse the arguments.

[tthorleifson]

@klauer Awesome sauce!

[xeontem]

thanks @klauer -v "a:b" works for me too even with spaces in the folder path