--mount bind-mount creates non-existing directory, contradicting documentation

[Marcono1234]

According to the documentation docker run --mount with type=bind should fail when the directory on the host does not exist:

If you use --mount to bind-mount a file or directory that does not yet exist on the Docker host, Docker does not automatically create it for you, but generates an error.

From what I have heard (have not tested it), this is also the way Docker behaves on Linux.
This can cause confusion when on Windows it creates the non-existing directory (contradicting the documentation) but the equivalent command fails on Linux.

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: C373B89E-9BCA-4594-B0E3-2A4AC1E72661/20210821232229

Actual behavior

The non-existing directory on the host is created

Expected behavior

Docker should fail (as described in the documentation) because the directory does not exist on the host

Information

• Windows Version: Windows 10 21H1 (OS Build 19043.1165)
• Docker Desktop Versions:
  • 3.6.0 (67351)
  • 4.26.1 (131620)
• WSL2 or Hyper-V backend? WSL2
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: No

Steps to reproduce the behavior

1. Make sure there is no directory called does-not-exist in your current directory
2. Run the following Docker command:

   docker container run --rm --mount type=bind,source="%cd%/does-not-exist",target=/some-dir tianon/true
   

[Milly]

probably same #10422

[Marcono1234]

You are right, it looks indeed a lot like #10422; I must have missed that when looking for existing issues. However, that issue is locked, so I would have had to create a new issue either way.

[brstreetlaw]

I'm hesitant to create a new issue but here's what I was experiencing, and the workaround I finally discovered. Can someone suggest whether it is a new issue or not?

Expected behaviour

Bind mounts (whether in docker run, docker-compose, or even using portainer.io) should be able to specify a directory within the host Windows filesystem, or in the very least, how that path would appear within the WSL filesystem (e.g. /mnt/c/Users/Public/Downloads:/downloads)

Actual behaviour

Bind mounts in the format above end up pointing to an obscure directory that Windows sees as created within \\wsl.localhost\docker-desktop-data\mnt\wsl\docker-desktop-data\tarcache\entries\docker.tar\ some_long_hex_id\containers\services\docker\rootfs\mnt\c\users\public\downloads (in the example above)

Information

Windows Version: Windows 11 21H2 (OS Build 22000.376)
Docker Desktop Version: 4.3.1
WSL2 or Hyper-V backend? WSL2
Are you running inside a virtualized Windows e.g. on a cloud server or a VM: No

Workaround

Don't use PowerShell to deploy containers. Use Ubuntu bash shell within WSL to execute docker run and docker-compose; bind mounts to the Ubuntu instance of WSL work as expected, and so do bind mounts to the host Windows filesystem using /mnt/c/whatever

EDIT: the WSLg/browser steps quoted for portainer.io below might have been unnecessary. Testing shows that as long as portainer.io is installed entirely within WSL Ubuntu, subsequent container deployment from https://localhost:9443/ in a host browser seems to work as expected (that is, portainer.io sees bind-mount paths through WSL Ubuntu eyes. This did not happen when using a portainer.io container deployed using that company's WSL2 instructions!)

When deploying anything via portainer.io, first install and use a web browser via WSLg that runs within the WSL VM (e.g. open Windows Terminal, start an Ubuntu bash shell, cd /tmp and run wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb followed by sudo dpkg -i google-chrome-stable_current_amd64.deb; sudo apt-get -f install

...then launch Google Chrome (Ubuntu) from Windows start menu, and point that browser to https://localhost:9443/

...then containers deployed via the portainer.io interface can bind mount to directories in the Ubuntu and/or the host Windows filesystem using any path that can be browsed via WSL Ubuntu bash shell.

Later on, inspecting the configuration of those deployed containers, the bind mounts will appear to have been changed to host paths of /run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/some_long_hex_id but when you browse \wsl.localhost\docker-desktop-data\mnt\wsl\docker-desktop-bind-mounts\Ubuntu in Windows, those long hex directories are inaccessible and show 0 bytes as their size - making me think they are symlinks.

Docker Desktop can now start and stop these containers, access CLI, etc. from the Windows host.

This is the only way that I have been able to make containers share directories and files with the Windows host, or WSL Ubuntu for that matter.

[Marcono1234]

@brstreetlaw, to me that sounds like a different issue (though the maintainers might think differently about this). My report was only about the fact that the documentation contradicts the actual behavior regarding whether non-existent directories are created. However, for me the directories were created in the correct location.

[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

[Marcono1234]

/remove-lifecycle stale

[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

[Marcono1234]

Still the case with Docker version 20.10.16, build aa7e414

/remove-lifecycle stale

[sarisia]

Thank you for raising this issue again (I'm the author of #10422).

I've confirmed this is still the case with Docker Desktop.

My workaround is remove Docker Desktop and install docker-ce. It works very well for me for months
and still haven't have any critical issues.

Just install docker-ce as described in the official docs
and then append the lines below to /etc/wsl.conf (ref):

[boot]
command = service docker start

I feel installing docker-ce manually is a bit of a pain so hope this issue resolves...

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, add a comment on this issue.
If not, this issue will be closed in 30 days.

Mark the issue as fresh with a /remove-lifecycle stale comment.
Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[Marcono1234]

Still the case for Docker Desktop 4.14.1 (91661), Docker version 20.10.21, build baeda1f

[Marcono1234]

/lifecycle frozen

[Marcono1234]

/remove-lifecycle stale

@docker-desktop-robot seems pretty pointless to me. It only causes a lot of noise and closes valid issues. And apparently anyone can disable it with /lifecycle frozen. So why does this bot exist in the first place?

[chrisinmtown]

Also a problem on Linux! I use Docker version 20.10.12, build 20.10.12-0ubuntu4

Starting a container with a bind-mount using a file that does not exist does not yield an error at startup. Instead, some part of Docker creates a empty directory at the file path. This is very confusing for our operations people, because when they check where the file is supposed to be, they see something and occasionally miss that it's not a file but instead a directory, and waste lots of time.

I'd really like docker to fail at start if anything is missing on the host that's supposed to be mounted (directory or file). Alternately, maybe you can give us a new option like "--fail-on-missing-volume" to preserve the existing behavior but allow these problems to be detected immediately.

Thanks for listening.

[Gibbz]

This is still happening on Linux.
When can we expect to see a fix?

[Marcono1234]

This is still happening on Linux.

@Gibbz, this report here is about the behavior of Docker Desktop for Windows, and also this repository docker/for-win here is only for issues about Docker Desktop for Windows. If you experience the same issue for Docker Desktop for Linux, you should probably report it at https://github.com/docker/desktop-linux. Please link to this issue here then.