Windows bind-mount volumes incompatible with Stacks and Services

[Vacant0mens]

Description Within Swarm, deploying a stack with bind-mount volume present in the config results in starting container failed: hcsshim::CreateComputeSystem 4818f892a98a6bb185d291a84f308883a3c2814a78ccbfdee4ca401186b39e31: The request is not supported

Steps to reproduce the issue:

1. When stack file includes:

   volumes:
     - E:\data:C:\data

   Or

   volumes:
     - type: bind
       source: E:\data
       target: C:\data

2. docker stack deploy command succeeds, but service crashes with error mentioned.
3. When stack file includes something else like:

   volumes:
     - type: npipe
       source: \\.\pipe\docker_engine
       target: \\.\pipe\docker_engine

4. docker stack deploy command succeeds and service starts normally.

Describe the results you received: stack service does not start, throws error mentioned (only visible in docker service ps [stackname]_[servicename] --no-trunc)

Describe the results you expected: service should start and map volumes appropriately

Additional information you deem important (e.g. issue happens only occasionally):

Output of 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

Output of docker info:

Client:
 Debug Mode: false
 Plugins:
  cluster: Manage Docker clusters (Docker Inc., v0.3.5)

Server:
 Containers: 4
  Running: 3
  Paused: 0
  Stopped: 1
 Images: 5
 Server Version: 19.03.0-rc2
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics l2bridge l2tunnel nat null overlay transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: active
  NodeID: k6b5wampalqkdwmrlarduw92a
  Is Manager: true
  ClusterID: 7feiqt4btrywxyyy7r67qy1ny
  Managers: 5
  Nodes: 5
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 10.0.137.76
  Manager Addresses:
   10.0.137.76:2377
   10.0.2.236:2377
   10.0.2.243:2377
   10.0.2.255:2377
   10.0.3.44:2377
 Default Isolation: process
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Windows Server 2019 Standard Version 1809 (OS Build 17763.615)
 OSType: windows
 Architecture: x86_64
 CPUs: 2
 Total Memory: 6GiB
 Name: GPSDHive-1a
 ID: 290d4588-5d18-4951-95ad-48c520056d9f
 Docker Root Dir: E:\Docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  dhivicappl1.dhicorp.com
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.): Swarm of 5 managers all running Windows Server 2019

EDIT: docker service create --name portainer -p 9000:9000 --mount type=bind,source=E:\data,destination=C:\data portainer/portainer:windows1809-amd64 also throws the same error as above.

But this works: docker run -d -p 9000:9000 --name portainer --restart always -v E:\Portainer:C:\data portainer/portainer:windows1809-amd64

[Vacant0mens]

confirmed that the problem occurs even with no named pipe mapping configured. updated issue title and initial post appropriately.

[ziilok]

I have same issue with swarm. Workaround for me is to remove VOLUME directive from dockerfile.

[ziilok]

Example for portainer wich works in swarm on windows with data mount: Download release 1.21.0. Extract to folder "portainer". Dockerfile:

FROM mcr.microsoft.com/windows/nanoserver:1809

COPY portainer /

WORKDIR /

EXPOSE 9000

USER ContainerAdministrator

ENTRYPOINT ["/portainer.exe"]

docker build -t portainer:1.21.0-nanoserver-1809 .

[Vacant0mens]

Interesting. I'll try running the container as another user (outside of the build).

[Vacant0mens]

I attempted to run the following two scenarios:

version: '3.7'
services:
  portainer:
    image: portainer/portainer:windows1809-amd64
    credential_spec: 
      file: GMSA-User.json # domain-based GMSA
    ports:
      - 9000:9000
    volumes:
      - type: bind
        source: E:\Portainer
        target: C:\data
      - type: npipe
        source: \\.\pipe\docker_engine
        target: \\.\pipe\docker_engine

and

services:
  portainer:
    image: portainer/portainer:windows1809-amd64
    user: "NT Authority\\SYSTEM" # localsystem service user
    ports:
      - 9000:9000
    volumes:
      - type: bind
        source: E:\Portainer
        target: C:\data
      - type: npipe
        source: \\.\pipe\docker_engine
        target: \\.\pipe\docker_engine

Both of those users are valid, but it gave me the same error message using both.

[Vacant0mens]

I would like a way to persist the data from my portainer service without relying on docker volumes because a volume may be dropped and spun up again at any time and then we'd lose the configuration each time the volume gets re-created.

[Vacant0mens]

@ziilok I don't really want to build my own image every time I need to update portainer on my system. I may do it temporarily, but I'll see about opening an issue on their end to update their dockerfile.

[Vacant0mens]

created: portainer/portainer/issue#3132

[ziilok]

Hello. Looks like it's an issue of docker swarm on windows. I discovered this error when I tried to deploy team city in swarm.

[mattscully]

I ran into the same problem when deploying a team city agent to a swarm on windows. I'm fairly new to docker and didn't realize I could still mount volumes if they weren't declared in the Dockerfile, so I'm glad to have a workaround. But this seems to be a fairly fundamental break to docker swarm on windows, so I hope it gets some attention.