DevContainers fail to start with Docker Desktop version 3.39+
- VSCode Version: 1.99.2
- Local OS Version: Windows 11 24H2
- Remote OS Version: n/a
- Remote Extension/Connection Type: Dev Containers
- Logs:
[2039 ms] Start: Run: docker inspect --type image myprivateacr.azurecr.io/myimage:dev
[2132 ms] TypeError: Cannot read properties of null (reading 'User')
[2133 ms] at ga (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:393:19836)
[2133 ms] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2133 ms] at async cw (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:412:5164)
[2133 ms] at async c6 (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:432:2475)
[2133 ms] at async u6 (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:412:3489)
[2133 ms] at async H6 (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:484:4015)
[2133 ms] at async BC (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:484:4957)
[2133 ms] at async d7 (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:665:202)
[2134 ms] at async f7 (c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:664:14804)
[2134 ms] at async c:\Users\BenAdelson\.vscode\extensions\ms-vscode-remote.remote-containers-0.409.0\dist\spec-node\devContainersSpecCLI.js:484:1188
[2142 ms] Exit code 1
Steps to Reproduce:
I'm only able to replicate this with a docker-compose file that hits our private ACR hosted in Azure. When using a docker-compose that builds the same containers locally with a Dockerfile the issue does not appear. Additionally I attempted to replicate with a docker-compose that simply pulls from redis:latest but the issue does not occur.
This issue occurs with Docker Desktop version 3.39.0 and 3.40.0, it does not occur on 3.38.0
It appears the response from docker inspect is materially different between Docker Desktop 4.38.0 and 4.40.0
4.38.0
[
{
"Id": "sha256:c7acd86014c0e61d788763b3263ffaf37b262933bbdbf7d15ecabc0fefcde83a",
"RepoTags": [
"redacted"
],
"RepoDigests": [
"redacted"
],
"Parent": "",
"Comment": "buildkit.dockerfile.v0",
"Created": "2025-04-10T17:11:18.088285524Z",
"DockerVersion": "27.5.1",
"Author": "",
"Config": {
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"443/tcp": {},
"80/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"APP_UID=1654",
"ASPNETCORE_HTTP_PORTS=8080",
"DOTNET_RUNNING_IN_CONTAINER=true",
"DOTNET_VERSION=8.0.15",
"ASPNET_VERSION=8.0.15"
],
"Cmd": null,
"Image": "",
"Volumes": null,
"WorkingDir": "/app",
"Entrypoint": [
"dotnet",
"redacted"
],
"OnBuild": null,
"Labels": {
"redacted"
}
},
"Architecture": "amd64",
"Os": "linux",
"Size": 103557709,
"GraphDriver": {
"Data": null,
"Name": "overlayfs"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:ea680fbff095473bb8a6c867938d6d851e11ef0c177fce983ccc83440172bd72",
"sha256:e0b67c464120d351c7041a69adcdf583260b67cc97d33a2d59759fff5a0e680b",
"sha256:cb9b9ae4449d13ae277fc9a1c67e7dc52075f79f6d5dc44c4c0f4be632282a75",
"sha256:5055a02f56c5a609574d3381c0146bad4ec5eedd4be73d20d289c84388a7a67c",
"sha256:a39bf4304068543a3a43676727bb13422364da6d8fd0b4a9a6e1ea87d4f28b33",
"sha256:a397b402e65f9a0e693940768138198af6e8e539af7b51214d27131be0b47505",
"sha256:e54be8edb03f713de1e17017f2fd880a2e66ee8208ff531c4a6a2420b1129736",
"sha256:c8b045041bed0355f7ea8248a7864e6b81048381e28d2f68eb520b48f323a7af",
"sha256:859dadccad200611587d6ad57a18ad972c9155cec870c1c10c3dbdd9952c9e23",
"sha256:e3c18834971e69acf62a60a8229464846390fdf632cb16187ef2c5969894ce94",
"sha256:6457947c582820f59658a0f6b69b3b463884daed0f5984a8499faee43ac3ca8a"
]
},
"Metadata": {
"LastTagTime": "2025-04-14T17:03:46.371700546Z"
}
}
]
4.40.0
[
{
"Id": "sha256:c7acd86014c0e61d788763b3263ffaf37b262933bbdbf7d15ecabc0fefcde83a",
"RepoTags": [
"redacted"
],
"RepoDigests": [
"redacted"
],
"Parent": "",
"Comment": "",
"DockerVersion": "",
"Author": "",
"Config": null,
"Architecture": "",
"Os": "",
"Size": 103557709,
"GraphDriver": {
"Data": null,
"Name": "overlayfs"
},
"RootFS": {},
"Metadata": {
"LastTagTime": "2025-04-14T17:03:46.371700546Z"
},
"Descriptor": {
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:c7acd86014c0e61d788763b3263ffaf37b262933bbdbf7d15ecabc0fefcde83a",
"size": 2623
}
}
]
Notice in 4.40.0 the Config property is null
Is there any update on this? This issue is preventing us from using devcontainers with a private hosted Azure Container Repository.
I am experiencing the same issue, but without "Docker Desktop". Our images are also from a private Azure Container Registry.
ii docker-buildx-plugin 0.23.0-1~ubuntu.22.04~jammy amd64 Docker Buildx cli plugin.
ii docker-ce 5:28.1.1-1~ubuntu.22.04~jammy amd64 Docker: the open-source application container engine
ii docker-ce-cli 5:28.1.1-1~ubuntu.22.04~jammy amd64 Docker CLI: the open-source application container engine
ii docker-ce-rootless-extras 5:28.1.1-1~ubuntu.22.04~jammy amd64 Rootless support for Docker.
ii docker-compose-plugin 2.35.1-1~ubuntu.22.04~jammy amd64 Docker Compose (V2) plugin for the Docker CLI.
I can confirm that the Config property is null for the retrieved image. Also notable: When just calling docker inspect myprivateacr.azurecr.io/myimage:dev, the Config property is set. When calling docker inspect --type image myprivateacr.azurecr.io/myimage:dev, the Config property is null.
The mentioned workaround (building the image locally) seems to work just fine. But that bypasses the purpose of our build workflows.
@benadelsonmb The new JSON seems incomplete. E.g., where did the environment variables go?
I can report that after several testings the issue does not reproduce with 3.41.1 After reset to docker desktop settings .
Meaning , there is a combination of version 3.39+ but with some specific docker desktop setting that causes it.
So quick mitigation without downgrading is reset to docker desktop Settings.
I can report that after several testings the issue does not reproduce with 3.41.1 After reset to docker desktop settings .
Meaning , there is a combination of version 3.39+ but with some specific docker desktop setting that causes it.
So quick mitigation without downgrading is reset to docker desktop Settings.
I can reproduce the issue without ever having Docker Desktop installed at all. So whatever causes the issue doesn't seem to be necessarily related to Docker Desktop.
I can reproduce the issue without ever having Docker Desktop installed at all. So whatever causes the issue doesn't seem to be necessarily related to Docker Desktop.
Docker desktop is also a bundle of Docker tools, including the docker daemon , which also has settings. specific setting of docker in a specific version causes it.
Try to reinstall your docker installation (whatever it may be) with default settings and check if issues reproduces.
@benadelsonmb The new JSON seems incomplete. E.g., where did the environment variables go?
I am not sure where the environment variables went but this is the complete json result for docker inspect myAcr.azurecr.io/myImage:latest
It seems to have been removed when I have docker desktop version 3.39+
I also have docker version Docker version 28.1.1, build 4eba377
This could be related to containerd being used for storing images locally in the latest versions of Docker. I got that enabled automatically after doing a factory reset in the latest Docker Desktop. I cannot reproduce the issue at the moment though, if you find steps to get into this state please share them here.
I'm on Docker Desktop v4.41.2 and when I try to use ghcr.io/elibroftw/devcontainers/templates/rust-full-stack:0.0.3, I also get the following error. At first I thought it was because I'm on arm64 (Surface laptop), but now I'm not sure. My base image (ghcr.io/elibroftw/devcontainers/images/base-almalinux) works fine. I also tried to use devcontainers/template-starter/color but that is a complete goner! It's quite unfortunate that this happened just when I decided to fix my custom devcontainer features and template. Guess I'll just have to copy-paste my template in the mean time.
TypeError: Cannot read properties of null (reading 'User')
[2025-05-10T03:40:10.184Z] Start: Run: docker inspect --type image ghcr.io/elibroftw/devcontainers/templates/rust-full-stack
[2025-05-10T03:40:10.258Z] Stop (74 ms): Run: docker inspect --type image ghcr.io/elibroftw/devcontainers/templates/rust-full-stack
[2025-05-10T03:40:10.259Z] TypeError: Cannot read properties of null (reading 'User')
[2025-05-10T03:40:10.259Z] at ga (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:393:19836)
[2025-05-10T03:40:10.259Z] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2025-05-10T03:40:10.259Z] at async Wu (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:395:253)
[2025-05-10T03:40:10.259Z] at async dw (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:467:1923)
[2025-05-10T03:40:10.259Z] at async Ix (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:467:608)
[2025-05-10T03:40:10.259Z] at async Y6 (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:484:3842)
[2025-05-10T03:40:10.259Z] at async BC (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:484:4957)
[2025-05-10T03:40:10.259Z] at async p7 (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:665:202)
[2025-05-10T03:40:10.259Z] at async d7 (c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:664:14804)
[2025-05-10T03:40:10.259Z] at async c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js:484:1188
[2025-05-10T03:40:10.270Z] Stop (740 ms): Run: C:\Users\maste\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js up --user-data-folder c:\Users\maste\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --container-session-data-folder /tmp/devcontainers-3386f84f-37f1-40de-91ed-3a50df58af731746848407724 --workspace-folder d:\repos\multi-spot-booker --workspace-mount-consistency cached --gpu-availability detect --id-label devcontainer.local_folder=d:\repos\multi-spot-booker --id-label devcontainer.config_file=d:\repos\multi-spot-booker\.devcontainer\devcontainer.json --log-level debug --log-format json --config d:\repos\multi-spot-booker\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --build-no-cache --remove-existing-container --mount type=volume,source=vscode,target=/vscode,external=true --mount type=bind,source=\\wsl.localhost\AlmaLinux-9\mnt\wslg\runtime-dir\wayland-0,target=/tmp/vscode-wayland-907c4c7c-ebda-4d02-93df-bcb9a5f6a72a.sock --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root --include-configuration --include-merged-configuration
[2025-05-10T03:40:10.271Z] Exit code 1
[2025-05-10T03:40:10.272Z] Command failed: C:\Users\maste\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\maste\.vscode\extensions\ms-vscode-remote.remote-containers-0.413.0\dist\spec-node\devContainersSpecCLI.js up --user-data-folder c:\Users\maste\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --container-session-data-folder /tmp/devcontainers-3386f84f-37f1-40de-91ed-3a50df58af731746848407724 --workspace-folder d:\repos\multi-spot-booker --workspace-mount-consistency cached --gpu-availability detect --id-label devcontainer.local_folder=d:\repos\multi-spot-booker --id-label devcontainer.config_file=d:\repos\multi-spot-booker\.devcontainer\devcontainer.json --log-level debug --log-format json --config d:\repos\multi-spot-booker\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --build-no-cache --remove-existing-container --mount type=volume,source=vscode,target=/vscode,external=true --mount type=bind,source=\\wsl.localhost\AlmaLinux-9\mnt\wslg\runtime-dir\wayland-0,target=/tmp/vscode-wayland-907c4c7c-ebda-4d02-93df-bcb9a5f6a72a.sock --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root --include-configuration --include-merged-configuration
[2025-05-10T03:40:10.273Z] Exit code 1
docker inspect sha256:c332fd1aa6c6cd994d44e95e13bc9cd4c8525d3a83348b356237ba1bba2b3eb8
[
{
"Id": "sha256:c332fd1aa6c6cd994d44e95e13bc9cd4c8525d3a83348b356237ba1bba2b3eb8",
"RepoTags": [
"ghcr.io/elibroftw/devcontainers/templates/rust-full-stack:latest"
],
"RepoDigests": [
"ghcr.io/elibroftw/devcontainers/templates/rust-full-stack@sha256:c332fd1aa6c6cd994d44e95e13bc9cd4c8525d3a83348b356237ba1bba2b3eb8"
],
"Parent": "",
"Comment": "",
"DockerVersion": "",
"Author": "",
"Config": null,
"Architecture": "",
"Os": "",
"Size": 7954,
"GraphDriver": {
"Data": null,
"Name": "overlayfs"
},
"RootFS": {},
"Metadata": {
"LastTagTime": "2025-05-09T23:40:13.047094764Z"
},
"Descriptor": {
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:c332fd1aa6c6cd994d44e95e13bc9cd4c8525d3a83348b356237ba1bba2b3eb8",
"size": 1296
}
}
]
I can replicate this issue with the following steps:
-
Ensure the Docker image is not present locally in Docker Desktop.
-
In VS Code's Remote Explorer, use "Clone Repository in Container Volume." This action pulls the image, builds the container, and everything works as expected.
-
Attempt to build a different container using the same image (which is not locally available). VS Code raises the following error:
[2025-05-11T03:40:10.259Z] TypeError: Cannot read properties of null (reading 'User') ...
The current workaround is to delete the image locally (which requires deleting all containers using this image) and then rebuild the container in VS Code.
Docker Desktop Version: 4.41.2 VSCode Version: 1.100.0 VSCode DevContainers Extension: 0.413.0
@0xfabioo Is this with an image from an ACR? Or some other registry? (Can't reproduce on my MacBook at the moment.)
@0xfabioo Is this with an image from an ACR? Or some other registry? (Can't reproduce on my MacBook at the moment.)
It's from an internal registry (RedHat Quay).
@0xfabioo Do you also see this with other registries?
Could you try to narrow it down with the Docker CLI? Does it show when you first pull and then inspect locally? Or maybe when you first run and then inspect? (Always starting without the image in the local cache.)
This looks like a bug between the Docker CLI and some of the image registries. Would be great if we could collect the information to file an upstream bug report.
Could someone seeing this append the full Dev Containers log from when this happens? (F1 > Dev Containers: Show Container Log)
Sorry for the delay. I tried the following:
- Delete the image locally.
- Pull the image (manually) with docker cli
docker pull myregistry.company.com:myimage:2.20 - Inspecting the image shows that Config is null
[
{
"Id": "sha256:dd36c7608d2743846e3776e89ae05215d270de3245b2735afcc4cbc08a6b2d9a",
"RepoTags": [
"registry.*****.com/****/****-dev:2.2.0"
],
"RepoDigests": [
"registry.*****.com/****/****-dev@sha256:dd36c7608d2743846e3776e89ae05215d270de3245b2735afcc4cbc08a6b2d9a"
],
"Parent": "",
"Comment": "",
"DockerVersion": "",
"Author": "",
"Config": null,
"Architecture": "",
"Os": "",
"Size": 837401074,
"GraphDriver": {
"Data": null,
"Name": "overlayfs"
},
"RootFS": {},
"Metadata": {
"LastTagTime": "2025-05-14T07:09:54.148207775Z"
},
"Descriptor": {
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"digest": "sha256:dd36c7608d2743846e3776e89ae05215d270de3245b2735afcc4cbc08a6b2d9a",
"size": 5137
}
}
]
- Image is locally available. In VScode "Clone Repository in Container Volume", same error message
TypeError: Cannot read properties of null (reading 'User').
[2025-05-14T07:13:37.403Z] Start: Run: docker inspect --type image registry.******.com/******/*****:2.2.0
[2025-05-14T07:13:37.439Z] Stop (36 ms): Run: docker inspect --type image registry.******.com/******/*****:2.2.0
[2025-05-14T07:13:37.438Z] TypeError: Cannot read properties of null (reading 'User')
[2025-05-14T07:13:37.438Z] at ga (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:393:19836)
[2025-05-14T07:13:37.438Z] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2025-05-14T07:13:37.438Z] at async cw (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:412:5164)
[2025-05-14T07:13:37.438Z] at async c6 (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:432:2475)
[2025-05-14T07:13:37.438Z] at async u6 (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:412:3489)
[2025-05-14T07:13:37.439Z] at async Y6 (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:484:4015)
[2025-05-14T07:13:37.439Z] at async BC (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:484:4957)
[2025-05-14T07:13:37.439Z] at async p7 (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:665:202)
[2025-05-14T07:13:37.439Z] at async d7 (/root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:664:14804)
[2025-05-14T07:13:37.439Z] at async /root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js:484:1188
[2025-05-14T07:13:37.458Z] Stop (762 ms): Run in container: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.413.0/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-496bfe38-0c7c-425c-8811-2a830fdc1ff81747206809762 --workspace-folder /workspaces/****** --workspace-mount-consistency cached --gpu-availability detect --id-label vsch.local.repository=https://****@dev.azure.com/****/*****/_git/****** --id-label vsch.local.repository.volume=vsc-remote-containers --id-label vsch.local.repository.folder=*********--id-label devcontainer.config_file=/workspaces/********/.devcontainer/devcontainer.json --log-level debug --log-format json --config /workspaces/*******/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-18a30e02-7a58-42c7-b463-15ab82edc79e.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vsc-remote-containers,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --mount type=bind,source=\\wsl.localhost\Ubuntu-22.04\mnt\wslg\runtime-dir\wayland-0,target=/tmp/vscode-wayland-3bdd959f-d2fe-4c82-94fa-7843ae232b67.sock --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root --include-configuration --include-merged-configuration
[2025-05-14T07:13:37.458Z] Exit code 1
Hope that helps.
Could someone seeing this append the full Dev Containers log from when this happens? (
F1>Dev Containers: Show Container Log)
@0xfabioo Do you also see this with other registries?
Could you try to narrow it down with the Docker CLI? Does it show when you first
pulland theninspectlocally? Or maybe when you firstrunand theninspect? (Always starting without the image in the local cache.)This looks like a bug between the Docker CLI and some of the image registries. Would be great if we could collect the information to file an upstream bug report.
Running onto this issue with Docker Desktop v4.41.2 but not with Docker Desktop v4.36.0. Same exact commands, but old one pulls from our ACR with the metadata, and the other does not. Build locally, it has the metadata. Not really sure how to resolve this issue but it definitely breaks the dev container.
@chrmarti Any updates on this, or do you need further information?
Could you try disabling containerd in the latest Docker Desktop version and check if that works around it? (https://docs.docker.com/desktop/features/containerd/)
@chrmarti It works for me with containerd disabled, Docker Desktop version 4.41.1
@benadelsonmb Thanks! Could you file an issue for Docker? I have asked on https://github.com/moby/moby/issues/49473 if this might be the same issue, but didn't get an answer yet.
Debian user here - obviously I'm not using docker desktop, just the core packages.
Installing a specific version from the instructions: https://docs.docker.com/engine/install/debian/
Rolling back to version 27. (the package 5:27.5.1-1~debian.12~bookworm) resolved this for me and docker inspect returns a lot more data now.
Hey @chrmarti, this issue might need further attention.
@benadelsonmb, you can help us out by closing this issue if the problem no longer exists, or adding more information.
This issue has gone away with latest version of docker desktop