compose "docker compose up" does not start if volumes are used

Whenever I try to use volumes in docker compose up it fails with the following error:

Error response from daemon: hcsshim::CreateComputeSystem {GUID}: The request is not supported.

I see the following entries in Windows Event Viewer :

Warning: Cannot create a template for a Hyper-V Container, reached the maximum number of templates. (Hyper-V-Compute)
Error: {GUID} cleanup: failed to delete container from containerd: no such container
Error: Handler for POST /v1.41/containers/{GUID}/start returned error: hcsshim::CreateComputeSystem {GUID}: The request is not supported.

Bind mounts are working fine.

Windows 21H2 Build 22000.739 Docker Desktop 4.9.1 (81317)

docker version

Client:
 Cloud integration: v1.0.25
 Version:           20.10.16
 API version:       1.41
 Go version:        go1.17.10
 Git commit:        aa7e414
 Built:             Thu May 12 09:17:07 2022
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.9.1 (81317)
 Engine:
  Version:          20.10.16
  API version:      1.41 (minimum version 1.24)
  Go version:       go1.17.10
  Git commit:       f756502
  Built:            Thu May 12 08:44:17 2022
  OS/Arch:          windows/amd64
  Experimental:     true

docker context show

default

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.6.0)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 16
  Running: 0
  Paused: 0
  Stopped: 16
 Images: 65
 Server Version: 20.10.16
 Storage Driver: windowsfilter (windows) lcow (linux)
  Windows:
  LCOW:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: inactive
 Default Isolation: hyperv
 Kernel Version: 10.0 22000 (22000.1.amd64fre.co_release.210604-1628)
 Operating System: Windows 10 Pro Version 2009 (OS Build 22000.739)
 OSType: windows
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.91GiB
 Name: ***REDACTED***
 ID: ***REDACTED***
 Docker Root Dir: C:\ProgramData\Docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

docker-compose-volumes-not-working.zip

Jun 20 '22 18:06 dobri-002

I have this same issue although I don't have the Hyper V template warning the eventlog, I do see the other two errors. Also with a Windows container and same version of Docker Desktop 4.9.1 / compose 2.6.0.

The problem does not occur if you uncheck the "Use Docker Compose V2" in the settings and use docker-compose up instead of docker compose up. If I understand it correctly then it uses an older version of compose.

Simple compose file to reproduce not needing any custom images:

version: '3.1'

services: test: image: mcr.microsoft.com/windows/servercore:ltsc2019 volumes: - "test:C:\test"

volumes: test:

docker-compose.zip

Simply doing a docker compose up gives "The request is not supported". When you remove the volumes lines docker compose up starts the container successfully.

Creating and using volumes without docker compose by just using docker directly works fine: docker volume create test docker run -v test:c:\test mcr.microsoft.com/windows/servercore:ltsc2019

When I switch docker desktop to Linux containers mode, I can use volumes with docker compose with no problems. This is issue only occurs with Windows containers.

Not sure if this is related but in the Docker Desktop Dashboard I can also not view any volumes in the Volumes tab. The loader icon keeps spinning. While docker image ls on the command line works fine. In Linux mode Docker Desktop Dashboard does show the Linux volumes correctly in the UI. I see that you also have this and already reported that here https://github.com/docker/for-win/issues/12789 this looks like a regression: in version 4.8.2 of Docker Desktop the Volumes tab works correctly.

Jun 29 '22 09:06 robbie-coder

I'm getting the exact same error on a Win 2019 server with Docker Community Edition 20.10.17 and compose 2.6.1

Jul 06 '22 09:07 theatricshrink

I am also having this issue with docker compose 2.7.0 and docker community edition 2022-03-26

Aug 30 '22 15:08 Jeb135

Same issue reproducible with v2.10.2 and use of volumes in compose file.

Oct 13 '22 20:10 wolfeno

This is a blocker for using Docker Compose on WCOW. Present in Docker 20.10.17 with Compose v2.10.2

Oct 14 '22 13:10 tkielan

I'm also seeing this issue on Windows 11 with Docker Desktop 4.11.1 and on Windows Server 2022 (not entirely clear on the specific docker version here).

I already did some digging around. I found https://github.com/microsoft/hcsshim/issues/649 which hints at the fact that somehow multiple volumes are used in a conflicting manner, where only one volume was specified. This led me to look further into the bowels of Docker. First of all, I found that the following sequence of commands does not work (as expected) and produces the error mentioned intially:

docker compose up

However, the following works as expected:

docker-compose-v1.exe up
docker-compose-v1.exe stop
docker compose start

This seems to indicate that the problem is with container creation, not with starting/stopping the container itself. When I run docker compose up and check its D:\Docker\containers\6cc61425a88b335e2a24e8010330be1996c5ffc00a4a863d743cbbd4187c004b\config.v2.json file, I find the following snippet:

"MountPoints": {
        "C:\\Shared": {
            "Source": "D:\\Docker\\volumes\\docker-compose-volumes-not-working_shared-files\\_data",
            "Destination": "C:\\Shared",
            "RW": true,
            "Name": "docker-compose-volumes-not-working_shared-files",
            "Driver": "local",
            "Type": "volume",
            "ID": "14f630261b09fad88272bfafd9217bc45bb86c75c593e5223bf6bb4587ad6725",
            "Spec": {
                "Type": "volume",
                "Source": "docker-compose-volumes-not-working_shared-files",
                "Target": "C:\\Shared",
                "VolumeOptions": {}
            },
            "SkipMountpointCreation": false
        },
        "c:\\shared": {
            "Source": "",
            "Destination": "c:\\shared",
            "RW": true,
            "Name": "b961dabff033f52163ebdee6d7607a4eda8f7494edc99dc6143d1393ff0cf86d",
            "Driver": "local",
            "Type": "volume",
            "ID": "f30c954763f542be0f7adaa608c852ac27429fcfa5e5c20c037780a88cae258f",
            "Spec": {},
            "SkipMountpointCreation": false
        }
    },

The double entry of the share seems to be highly suspicious.

Starting the container with docker-compose-v1.exe up, I check D:\Docker\containers\66c2ea9546535502c064b2b0dc1b22535b8a6023c8317a520a9bbee4adb225fc\config.v2.json to find the following, more along what one would expect:

    "MountPoints": {
        "c:\\shared": {
            "Source": "D:\\Docker\\volumes\\docker-compose-volumes-not-working_shared-files\\_data",
            "Destination": "c:\\shared",
            "RW": true,
            "Name": "docker-compose-volumes-not-working_shared-files",
            "Driver": "local",
            "Type": "volume",
            "Relabel": "rw",
            "ID": "df572d1960c1f7fa0e29945df4b6774b9b6b944bef54bca7c107ea8b41977da7",
            "Spec": {
                "Type": "volume",
                "Source": "docker-compose-volumes-not-working_shared-files",
                "Target": "c:\\shared"
            },
            "SkipMountpointCreation": false
        }
    },

Dec 13 '22 14:12 DamianDap

Thank you for the reports, especially the excellent analysis by @vdaphi!

A fix will be in the next release of Compose. As a temporary workaround (if possible), using lowercase paths in target appears to work.

Dec 16 '22 18:12 milas