The Request is not Supported Error for Volume "Mount" Configuration

[Vacant0mens]

docker run -d --restart=always --mount type=npipe,source=\\.\pipe\docker_engine,destination=\\.\pipe\docker_engine --mount type=bind,source=E:\Portainer,destination=C:\data -p 9000:9000 --name portainer portainer/portainer:windows1809-amd64

When the above command is submitted, it gets this response from hcsshim service (through the Docker engine, to the Docker Cli) with:

C:\Program Files\Docker\docker.exe: Error response from daemon: hcsshim::CreateComputeSystem [containerid]: The request is not supported.
(extra info: {"SystemType":"Container","Name":"551b3cac14d9fb9473a05cd1efcd92045600d101dd8ddf66b5307693cc35a208","Owner":"docker","VolumePath":"\\\\?\\Volume{bf3698ce-a504-412d-ba14-697228eff239}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"E:\\Docker\\windowsfilter\\551b3cac14d9fb9473a05cd1efcd92045600d101dd8ddf66b5307693cc35a208","Layers":[{"ID":"1ce23688-45e9-5bf6-b812-25b4e80a62a0","Path":"E:\\Docker\\windowsfilter\\b4a8ee12b2e4cc2d3514b719115dfdf50689200f0f363e4e5516363f5e0c3e35"},{"ID":"2c407c7a-6a88-5d74-a731-7dc227085ca6","Path":"E:\\Docker\\windowsfilter\\f65e751564f7d2a7b940f66e5da1501b6c2985f0f7526981c39442fa72da40e0"},{"ID":"69ba6b7e-6d4d-56d4-b032-b67015fd09c6","Path":"E:\\Docker\\windowsfilter\\758a98df51980f8a59e1931c6932206793684e314600cdd8badfc43bd38279cf"},{"ID":"b90eb358-2636-5af4-bc74-a36ca5517904","Path":"E:\\Docker\\windowsfilter\\c1e37d94cbff4cfca6af84e050e769919575c982db1a721083409e58d7e97d93"},{"ID":"8d6ab175-fc01-5ef7-bcdd-f04874af0236","Path":"E:\\Docker\\windowsfilter\\1fef6c537d5990532130d144455762ad708e6fd41bc8f6f6e299e718abac2a82"},{"ID":"c15d719e-829a-5ab9-80a0-b5b33cbb6c77","Path":"E:\\Docker\\windowsfilter\\27e2eede1c2b09401d1c192a69ebf95e17dff6ccc08742fa153ff39858699809"}],"HostName":"551b3cac14d9","MappedDirectories":[{"HostPath":"E:\\Portainer","ContainerPath":"C:\\data","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},{"HostPath":"E:\\Docker\\volumes\\bbbf8db18257f097a52cf59893ed6b4d80ea7090b899f8be2392df1b501fbbc3\\_data","ContainerPath":"c:\\data","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false}],"MappedPipes":[{"HostPath":"\\\\.\\pipe\\docker_engine","ContainerPipeName":"docker_engine"}],"HvPartition":false,"EndpointList":["4C01CC22-90C4-4289-BCCF-C2C8F9FC25B9"],"AllowUnqualifiedDNSQuery":true})

However, this command works with no issues:

docker run -d --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v E:\Portainer:C:\data -p 9000:9000 --name portainer portainer/portainer:windows1809-amd64

FYI:
Machine: Windows Server 2019

PS ~\> [System.Environment]::OSVersion.Version
Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17763  0

PS ~\> docker version
Client: Docker Engine - Enterprise
 Version:           19.03.0-rc2
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        674d742bb0
 Built:             06/05/2019 00:05:04
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.0-rc2
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.5
  Git commit:       674d742bb0
  Built:            06/05/2019 00:03:05
  OS/Arch:          windows/amd64
  Experimental:     false

[jterry75]

@jhowardmsft - What is the expectation here for Windows? I have only ever used the --mount syntax with Containerd which does work.

[Vacant0mens]

I don't know about the Microsoft devs, but the --mount option doesn't work for bind volumes in swarm services either.

[TBBle]

Just came across this looking for something else, and I note that in the failure case, we can see two MappedDirectories entries:

"MappedDirectories":[
{"HostPath":"E:\\Portainer","ContainerPath":"C:\\data","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false},
{"HostPath":"E:\\Docker\\volumes\\bbbf8db18257f097a52cf59893ed6b4d80ea7090b899f8be2392df1b501fbbc3\\_data","ContainerPath":"c:\\data","ReadOnly":false,"BandwidthMaximum":0,"IOPSMaximum":0,"CreateInUtilityVM":false}
]

That second one looks immediately suspicious to me, since nothing in the command-line suggests a Docker volume be used, and its mount-path is the same as the host-mount requested, except the case of the drive letter, C. So the problem seems to have happened before hcsshim was involved.

Poking around, it seems this was also reported moby/moby#39577, and indeed at the time the Portainer DockerFile contained VOLUME C:\\data, removed via portainer/portainer#3132 to fix this.

However, since -v worked, the underlying intended behaviour must be feasible, but without seeing the HCS JSON request for the working case, it's not clear what's different, and hence whether Docker handles that differently (ignoring one of the overlapping mounts), or if the input is different-enough that hcsshim or HCS handles it correctly.

I assume the 'Swarm' interaction is that Swarm always does the equivalent of --mount, never -v, so will hit this same case when trying to get a "last mount wins" effect on a single container path, although looking at docker/for-win#12475, it might affect all Swarm bind-mounts? (I've never used Swarm...) Or that might be a totally different issue with the same error.