Vscode-remote-release: Docker 2.3.0.2 - open folder in container - error CreateProcess failed

[markharrison]

trying to open folder in container - get error:
Unable to start terminal process: CreateProcess failed

[1 ms] Start: Resolving remote
[3 ms] Setting up container for folder or workspace: d:\devx\markharrisonweb

[41 ms] Start: Run: git rev-parse --show-toplevel
[144 ms] Start: Check Docker is running
[144 ms] Start: Run: docker info
[567 ms] Start: Run: docker ps -q -a --filter label=vsch.local.folder=d:\devx\markharrisonweb --filter label=vsch.quality=stable
[742 ms] Start: Run: docker build -f d:\devx\markharrisonweb\.devcontainer\Dockerfile -t vsc-markharrisonweb-3d8e22aaa1f27181fa50269a160748de d:\devx\markharrisonweb\.devcontainer
[934 ms] Error: Unable to start terminal process: CreateProcess failed
        at new WindowsPtyAgent (c:\Users\mharriso\AppData\Local\Programs\Microsoft VS Code\resources\app\node_modules.asar\node-pty\lib\windowsPtyAgent.js:77:36)
        at new WindowsTerminal (c:\Users\mharriso\AppData\Local\Programs\Microsoft VS Code\resources\app\node_modules.asar\node-pty\lib\windowsTerminal.js:50:24)
        at Object.spawn (c:\Users\mharriso\AppData\Local\Programs\Microsoft VS Code\resources\app\node_modules.asar\node-pty\lib\index.js:28:12)
        at c:\Users\mharriso\.vscode\extensions\ms-vscode-remote.remote-containers-0.117.0\dist\extension.js:1:5211
        at async Object.t.runCommand (c:\Users\mharriso\.vscode\extensions\ms-vscode-remote.remote-containers-0.117.0\dist\extension.js:1:8512)
        at async c:\Users\mharriso\.vscode\extensions\ms-vscode-remote.remote-containers-0.117.0\dist\extension.js:1:162431
        at async Object.t.openDockerfileDevContainer (c:\Users\mharriso\.vscode\extensions\ms-vscode-remote.remote-containers-0.117.0\dist\extension.js:1:162334)

• VSCode Version: 1.45.0
• Local OS Version: Windows 10 : 2004
• Remote OS Version:
• Remote Extension/Connection Type: SSH/Docker/WSL : 0.117.0
• Docker: 2.3.0.2

Steps to Reproduce:

1. F1
2. Remote-Containers: Open Folder in Container

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No

[supernova2468]

I was just about to make an issue. I also get this error after updating.

[markharrison]

I just update Docker Desktop today - could that be the issue?
To add - im not using WSL2

[jdotlu]

Same problem for me. I updated Docker Desktop to 2.3.0.2 today and then this issue appeared. Will be downgrading Docker Desktop in the mean time.

[andyli]

Same here. And I've tried switching to the Docker WSL 2 based engine too, but that didn't help.

[TyrenDe]

I tried to work around it by copy/pasting the docker build command to a terminal and it runs successfully. Then I tried a docker run to start it and attaching to the running container, but that failed.
I think there are other steps arguments for mapping the drive and stuff that I missed.

[PavelSosin-320]

Please, check your Docker Desktop installation:
Both C: and D: are shared - check it in Docker Desktop settings
DockerDesktop distro WSL2 is installed correctly:
wsl -l -v
_Docker-Desktop v2_
both c: and d; drives are available for docker
wsl -d docker-desktop ls /mnt/host
c d wsl
wsl -d docker-desktop ls -al /mnt/host/d
You can reach your folder
wsl -d docker-desktop ls /mnt/d/ ---> path to your folder in the POSIX notation

Neither c nor d is not compressed!
The output of docker inspect is also required for successful analysis. You can use the Docker VSCode extension. Accessibility of your workspace depends on how it is mounted when dev container is running.
Windows 2004 and WSL 2.0 are full of new things which require adoptions

[markharrison]

My C: and D: drives are shared in the docker settings. And not compressed.
I'm not using WSL or WSL2

[Chuxel]

I'm even seeing strange behaviors on 2.3.0.2 on Mac that are unrelated to Remote - Containers. I suspect this is a bad Docker release and we should see a fix before too long, but I'd recommend staying on 2.2.0.x in the mean time.

I'm even seeing something as simple as pushing a second tag to a registry (whether DockerHub or Azure Container Registry in my case) for an image not working on Mac... downgrade and the problem is gone.

[Chuxel]

Direct link to 2.2.0.5 installer:

• macOS
• Windows

[dreamwayjgs]

I have a same issue.
With running docker-compose manually, I can run "open folder in container" and it works anyway.. But it's a stopgap.

[PavelSosin-320]

It's interesting to see which caps are delegated to Dev container and whether it is running privileged to be able to navigate through host WSL distro FS and reach host Windows folder. Unfortunately, it is not documented. By default Docker container runs in very restrictive mode and no Linux caps are passed according to security recommendations. I suspect DAC_READ_SEARCH which is not granted by default. I think that it's right to expect the further reduction of default caps to allow the container to provide only a certain microservice with no frils.

[jtommi]

I have the same issue.
Downgrading docker to 2.2.0.5 solved the issue for me. Thanks to @Chuxel for the links
Some additional info :

• All devcontainers in VS Code are impacted (I tested with a standard Alpine file generated by VS Code)
• I'm not using WSL2
• Docker worked fine through the command prompt or Powershell

Versions when the issue appeared

• VSCode Version: 1.45.0 (I also tried 1.46.0-insider)
• Local OS Version: Windows 10 Pro : 18363
• Remote Extension/Connection Type: SSH/Docker/WSL : 0.117.0
• Docker: 2.3.0.2

[PavelSosin-320]

I investigated this issue from the Docker internals side and found that Docker Desktop 2.3 on top of WSL 2.0 works correctly and doesn't prevent access to the mounted volumes. All volumes which I've created are created correctly and accessible from the Docker host the WSL distros: docker-desktop and docker-desktop-data. It can be checked in a few steps:
Login to Docker-desktop distro using command wsl -u root -d docker-desktop
cd /mnt/host/wsl/docker-desktop-data/data/docker/volumes
You should see all your volumes created and mounted to all created and not removed containers.
cd to volume folder which corresponds to the mounted workspace.
Navigate to the desired folder using cd
List the folder content.
If you succeded The container is created OK and the "workspace" Volume is mounted correctly.
Docker-desktop distro provides a common bottom layer for all running Linux containers If some issue appears it means that either container created from the image in the wrong way or mount parameters were wrong.
Any attempt of accessing folders outside the workspace is impossible due to obvious security reasons - attempt to access non-owned data on the Docker host!
In the non-wsl scenario, the same checks could be carried via connection to MobyLinux Desktop's VM via RDP and investigation of VM's volume.

[PavelSosin-320]

When I manually created VSCode base dev container with the proper mounting in wsl bash, i.e. without DOS path references non-understandable to Docker and tools integrated inside the image I didn't have any minor issue.

_pavel@MSI:~$ docker run -it -d --mount type=bind,source=/mnt/c/Users/Pavel/vscodeWS,target=/var/vscodeWS mcr.microsoft.com/vscode/devcontainers/base
d59ffd9a05a60d5f2d123b6c1bd86f4fe1728dced3985a452188890f75a37828
pavel@MSI:~$ docker attach d59ffd9a05a60d5f2d123b6c1bd86f4fe1728dced3985a452188890f75a37828
root@d59ffd9a05a6:/# pwd
root@d59ffd9a05a6:/var# cd vscodeWS_ 

I can navigate, create folders and files both at host side using cmd and container side using mkdir touch and ls and see absolutely consistent pictures. It means "nothing to correct" if the tool is used as designed.
Of course, it is impossible to open a folder outside the volume Otherwise the user will be able to open a folder everywhere using flexible Docker's mount mechanism.
The VSCode base Dev container is absolutely OK too and works how it was designed to work.

[arniwesth]

Same problem. Starting the container manually ie "Run Interactive" and then "Attach Visual Studio Code" works.

[Chuxel]

@chrmarti I am able to run the Docker Compose command in question from the command line to start things up - I'm not entirely sure what is failing that is specific to 2.3.0.2. If we can identify what is going wrong, we can go and upvote / report in the docker repo. Are you able to repro as well?

[chrmarti]

We accidentally pick up the docker script next to docker.exe. Deleting or renaming "<docker install folder>\Docker\resources\bin\docker" might work as a workaround. Fix will be on our side.

[KenxinKun]

Thanks @chrmarti the workaround above worked just fine (docker -> docker.sh)

[vladgovor77771]

Same issue. Attaching to running container works for me!

[jsperafico]

@chrmarti on Windows 10, same thing happened with docker-compose file.
Deleting both (docker and docker-compose) files worked for me.

[nimamahmoudi]

Same here, renaming both files fixed the issue. Thanks @chrmarti.

[offbeatful]

Confirming solution from @chrmarti
Thanks!

[WandyYing]

Same problem. Confirming solution from @chrmarti. I renamed "\Docker\resources\bindocker"， it work now.
Thanks!

[chrmarti]

Fixed in version 0.117.1 of the Remote-Containers extension. 👍

[simonferquel]

Update from Docker Desktop team: this docker script (without exe extension) that we added in Docker Desktop is a little hack to help users deal with:

• Distros not converted yet to WSL 2
• WSL 2 distros with DOCKER_HOST set to something like tcp://localhost:2375

This can be safely removed if needed :)

BTW, this bug is awesome!

[PavelSosin-320]

@simonferquel which docker => and I see what I run or create bash alias. I love Linux!