Docker Desktop 4.91.0 -> 4.92.0 breaks WSL integration

Bug report

Update broke WSL integration.
Tried uninstalling, reinstalling from scratch and reboot to no avail.

running wsl distro proxy in Work-Ubuntu-26.04.1 distro: running proxy: running wslexec: An error occurred while running the command. DockerDesktop/Wsl/ExecError: c:\windows\system32\wsl.exe -d work-ubuntu-26.04.1 -u root -e /run/docker-desktop/docker-desktop-user-distro proxy --distro-name work-ubuntu-26.04.1 --docker-desktop-root /mnt/wsl/docker-desktop c:\program files\docker\docker\resources: exit status 1 (stderr: , stdout: , wslErrorCode: DockerDesktop/Wsl/ExecError) (output: [2026-09-21T16:05:43.059163457Z][docker-desktop-user-distro.version][W] failed to read component versions: open /opt/docker-desktop/componentsVersion.json: no such file or directory
[2026-09-21T16:06:13.200977826Z][docker-desktop-user-distro.apiproxy][W] restoreMounts: ensure ready failed: timed out waiting for /mnt/wslg/runtime-dir/wayland-0 to be automounted
[2026-09-21T16:06:13.201134168Z][docker-desktop-user-distro][F] timed out waiting for /mnt/wslg/runtime-dir/wayland-0 to be automounted
[main.run({0x7ffd04841b27, 0x28})
[	linuxkit/pkg/desktop/docker-desktop-user-distro/main.go:134 +0x5ba
[main.init.func6(0x394df4bb900?, {0x394df68a2d0?, 0x4?, 0x790fd859c9ad?})
[	linuxkit/pkg/desktop/docker-desktop-user-distro/main.go:86 +0x25
[github.com/spf13/cobra.(*Command).execute(0x790fd903b220, {0x394df68a280, 0x5, 0x5})
[	github.com/spf13/cobra@v1.10.2/command.go:1019 +0xafb
[github.com/spf13/cobra.(*Command).ExecuteC(0x790fd903ac60)
[	github.com/spf13/cobra@v1.10.2/command.go:1148 +0x465
[github.com/spf13/cobra.(*Command).Execute(...)
[	github.com/spf13/cobra@v1.10.2/command.go:1071
[main.main()
[	linuxkit/pkg/desktop/docker-desktop-user-distro/main.go:645 +0x1a) (wslConf: [boot]
systemd=true

[user]
default=feref
)

Platform

Windows 11 Professional for Workstations
Version 10.0.26200.9457 (25H2)

Version information

Client:
 Version:           29.8.0
 API version:       1.56
 Go version:        go1.26.8
 Git commit:        88096ef
 Built:             Thu Sep  3 21:53:38 2026
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.92.0 (240144)
 Engine:
  Version:          29.8.0
  API version:      1.56 (minimum version 1.40)
  Go version:       go1.26.8
  Git commit:       3ce5872
  Built:            Thu Sep  3 21:51:20 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.3.5
  GitCommit:        1294c24a7da8e5a793ed378161673abe94118892
 runc:
  Version:          1.5.1
  GitCommit:        v1.5.1-0-g8f2685a4
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.8.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: Docker AI Agent Runner (Docker Inc.)
    Version:  v1.140.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-agent.exe
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.31.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.37.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v5.5.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.4.4
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.7
    Path:     C:\Program Files\Docker\cli-plugins\docker-dhi.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.43.3
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.2.6
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.6.27
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.2.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-pass.exe
  sandbox: "docker sandbox" is deprecated, use Docker Sandboxes instead (Docker Inc.)
    Version:  v0.13.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.24.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 29.8.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1294c24a7da8e5a793ed378161673abe94118892
 runc version: v1.5.1-0-g8f2685a4
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.18.33.2-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 32
 Total Memory: 41.13GiB
 Name: docker-desktop
 ID: 3df9d5f5-da3b-4d22-b180-58ffc9178ecb
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
  ::1/128
 Live Restore Enabled: false
 Firewall Backend: iptables

Diagnostics ID

929B3B06-A8AB-4396-9CB5-F78C840FE51C/20260921160651

Same issue happens on a fresh install of Docker 4.92.0 on Microsoft Windows [Version 10.0.26100.8117]

Same, workaround is to downgrade to 91 for now:

download v4.91.0 from releasenotes
to override 92 run from Terminal:
& '.\Docker Desktop Installer.exe' install --disable-version-check

Same issue here, confirmed independently.

Environment: Windows 11 Pro (10.0.26200.9457), Docker Desktop 4.92.0 (240144), WSL 2.7.14.0, distro: Ubuntu (with systemd=true in wsl.conf)

Trigger: Reopen in Container via VS Code Dev Containers extension. Log output matched this issue's exactly, including restoreMounts: ensure ready failed: timed out waiting for /mnt/wslg/runtime-dir/wayland-0 to be automounted.

Ruled out a few things while debugging:

wsl --shutdown + restarting Docker Desktop temporarily got the Docker engine itself working (docker run hello-world succeeded), but the per-distro docker-desktop-user-distro proxy kept crashing with the same wayland-0 timeout, so any workflow needing WSL distro integration (like devcontainers) still failed.
Toggling systemd=true/false in wsl.conf made no difference — reproduced identically either way.
The bind-mount source paths logged before the crash (leftover registrations from unrelated past projects) all existed and were accessible, so it's not a stale-mount-registration issue either.

Fix confirmed: Downgrading to Docker Desktop 4.91.0 (build 239619) resolved it completely — WSL integration proxy starts cleanly and Reopen in Container now works as expected. Same wsl.conf, no other changes.

It happened to me with a completely default wsl.conf (just [boot] / systemd=true, no [automount] section at all).

Environment

Windows 11 Pro, Version 25H2 (OS Build 26200.9457)
Docker Desktop 4.92.0 (build 240144)
WSL distro: Ubuntu (default install/config)

Symptom 1: WSL integration crash on every startup

running wsl distro proxy in Ubuntu distro: running proxy: running wslexec: An error occurred while running the command.
DockerDesktop/Wsl/ExecError: c:\windows\system32\wsl.exe -d ubuntu -u root -e /run/docker-desktop/docker-desktop-user-distro proxy --distro-name ubuntu --docker-desktop-root /mnt/wsl/docker-desktop c:\program files\docker\docker\resources: exit status 1 (stderr: , stdout: , wslErrorCode: DockerDesktop/Wsl/ExecError) (output: [docker-desktop-user-distro.version][W] failed to read component versions: open /opt/docker-desktop/componentsVersion.json: no such file or directory
[docker-desktop-user-distro.apiproxy][W] restoreMounts: ensure ready failed: timed out waiting for /mnt/wslg/runtime-dir/wayland-0 to be automounted
[docker-desktop-user-distro][F] timed out

Note the automount target here is /mnt/wslg/runtime-dir/wayland-0 (WSLg's Wayland socket), not /var/run/docker.sock or a compose bind mount like in the original report, so this looks like the same "wait for automount" logic timing out on multiple different paths, not something specific to one mount type.

I tested disabling WSLg explicitly (guiApplications=false under [general]) in case that was the trigger, but no change: Error persisted identically.

Symptom 2: VS Code Dev Containers broken independently of the popup

Even after clicking "Skip WSL distro integration" to dismiss the crash above, opening a plain dev container (no custom mounts, no workspaceMount override, project folder on C:, no spaces, does contain hyphens) failed every time with:

"A mount config is invalid. Make sure it has the right format and a source folder that exists on the machine where the Docker daemon is running."

Manually bind-mounting the same folder via docker run -v C:\path:/test worked fine, so this appears specific to whatever path the Dev Containers extension uses to talk to Docker Desktop on WSL2 (likely routed through the same broken proxy above, just reached a different way).

Fix

Downgrading to 4.91.0 (build 239619), installed in-place over 4.92.0 with install --disable-version-check, resolved both issues completely. No other changes.

@almutareb

Thanks @almutareb
This worked for me.

Downgrade to v4.91.0 for now. Download and install .91without uninstalling .92:
https://docs.docker.com/desktop/release-notes/
Docker Desktop Installer.exe install --disable-version-check

Hey! We believe to have fixed the bug and will be releasing the fix as soon as possible.
In the meanwhile here is an internal build with it.

Came here looking for a reason for the new failure I was getting and also set my Hermes Agent with local Qwen 3.8 27B on the issue while I browsed around. As I found this issue, my agent suggested this fix and cause.

What follows is output from my local agent....

/var/lib/docker-desktop/mounts.data (written by the 4.92.0 user-distro, last modified 22 Sep 14:34 — the engine's first run after the upgrade) contains exactly one entry:

/mnt/wslg/runtime-dir/wayland-0:<uuid>/<hash>

That's a stale record of the WSLg wayland socket being present as a mount in Ubuntu — classic residue from VS Code devcontainers' "mount Wayland socket" feature (it bind-mounts that socket into dev containers). What happens:

On 22 Sep, when the new engine/proxy first ran after the upgrade, it snapshotted the distro's mounts — and recorded the wayland socket.

On every proxy start (each boot, and your "Restart WSL integration"), restoreMounts replays that list and calls "ensure ready" on the wayland-0 mount.

WSLg never (re-)mounts runtime-dir as its own mountpoint — it's just a subdirectory of the /mnt/wslg tmpfs — so the readiness wait runs the full ~28s, times out, and the proxy fatals. Deterministically. That's why the restart didn't help: the state persists.

The fix (I can't run it — needs root, and I don't have sudo without your password). In an Ubuntu terminal:
sudo cp /var/lib/docker-desktop/mounts.data /var/lib/docker-desktop/mounts.data.bak-20260923
sudo truncate -s 0 /var/lib/docker-desktop/mounts.data
Then click "Restart the WSL integration" in Docker Desktop again. With an empty restore list, the proxy has nothing to wait on and should come up.

Worst case it's a no-op (same error) and you sudo cp the backup back. Worth noting for later: this is very likely a 4.92.0 bug (the cross-distro bind-mount restore shouldn't track ephemeral WSLg sockets, and it hard-fails the whole distro integration on one missing mount) — if it recurs, worth a report to Docker, and the stale backup file is your evidence.

For me, running the two commands to backup and then truncate mounts.data did the trick. Is it the right fix? Dunno. Does it fix it? Yes.

docs: add known issue for WSL integration failures in 4.92.0

@dave00000

Same problem. Downgrading to 4.91.0 helped. Thanks to @dave00000 for the "Docker Desktop Installer.exe" install --disable-version-check tip!

@lwsrbrts

@lwsrbrts @rhnatiuk would you mind testing the build I linked to above?

@mat007

@mat007 works for me

WSL version: 2.7.14.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.9457

Distro: Ubuntu

Everything was OK with my (Agent's) fix on 4.92.0 but happy to help out.

Have just installed your build (4.94) and unfortunately got this immediately after install:

A Restart from the system tray right-click seems to have brought it to life though and WSL integration is working (a rudimentary docker container ls -a at least gives me a list of containers back.

Ah, spoke too soon...

So I used the right-click Quit Docker Desktop from the system tray icon, waited a couple of moments and started Docker Desktop up again and got this:

Seems to repeat itself after clicking the restart button too...

configuring docker in Ubuntu: docker cli config: failed to write file: running wslexec: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Wsl/Service/0x8007274c: c:\windows\system32\wsl.exe -d ubuntu -e sh -c cat - > ~/.docker/config.json: exit status 0xffffffff (stderr: , stdout: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 
Error code: Wsl/Service/0x8007274c
, wslErrorCode: Wsl/Service/0x8007274c)

After clicking Restart for a second time, the error hasn't reoccurred and WSL integration does now seem to be working. Unknown what a reboot is going to do but a Quit and restart basically repeats the above error again.

@lwsrbrts

Another data point from 4.92.0 (240144): the stale mounts.data entry here was a Windows drive path, not a WSLg socket.

/var/lib/docker-desktop/mounts.data contained /mnt/c/Linux/Hermes:<hash>/<hash>, left by a since-removed container that had bind-mounted that folder from the distro. Every start then failed with restoreMounts: ensure ready failed: timed out waiting for /mnt/c/Linux/Hermes to be automounted, although /mnt/c was mounted and the folder readable. .wslconfig has virtiofs=true, so /mnt/c is a virtiofs mount.

Removing only that line, rather than truncating the file (the mechanism @lwsrbrts described above, and @jasper-yeh in docker/for-win#15065), was enough. The remaining 15 entries restored without errors:

sudo cp -p /var/lib/docker-desktop/mounts.data /var/lib/docker-desktop/mounts.data.bak
sudo sh -c 'grep -v "^/mnt/c/" /var/lib/docker-desktop/mounts.data.bak > /var/lib/docker-desktop/mounts.data'

On the 0x8007274c errors in the comment above (wsl.exe -d ubuntu -e ... timing out after a cold start, cleared by clicking Restart): the same happened here on 4.92.0, both in setup groups (wsl.exe -d ubuntu -e whoami) and in the config.json write. It matches microsoft/WSL#14541 (early wsl.exe -e timeouts with systemd=true). At the same moment, dmesg showed UtilBindVsockAnyPort:322: bind failed 4 followed by SessionLeaderEntryUtilityVm:3083: InitCreateProcessUtilityVm failed. That part may be independent of this fix.

Environment: Windows 11 Enterprise 10.0.26200, WSL 2.7.14.0, kernel 6.18.33.2-2, Ubuntu with systemd=true, Docker Desktop 4.92.0 (240144). Build 240820 not tested.

docs: add known issue for WSL integration failures in 4.92.0 (#26170)

@lwsrbrts @rhnatiuk would you mind testing the build I linked to above?

Hi. Sorry, I can't do it because we are in the before-the-release hell

@mat007

@mat007

Hey! We believe to have fixed the bug and will be releasing the fix as soon as possible. In the meanwhile here is an internal build with it.

I could finally try your internal build.
Works like a charm.
No failed integration errors.
Not even the, by now, "classic" groups/timeout error popup on which a I had to press "restart the WSL integration" 3-4 times and that has been haunting me (and I bet other people as well) for months.
I'm touched.

@lwsrbrts

Tested build 4.94.0 (240820), installed in place over 4.92.0 (240144), against the stale drive-path case from my earlier comment.

Put /mnt/c/Linux/Hermes:<hash>/<hash> back into /var/lib/docker-desktop/mounts.data, then wsl --shutdown and a cold start: WSL integration came up without intervention, no restoreMounts ... automounted error. The stale line was gone from mounts.data afterwards.
A second cold start was also clean.
The first start right after installing hit the 0x8007274c error once (sh -c cat - > ~/.docker/config.json), as @lwsrbrts saw. One click on Restart cleared it.

Windows 11 Enterprise 10.0.26200, WSL 2.7.14.0, Ubuntu with systemd=true, .wslconfig virtiofs=true.

Fixed with latest Desktop 4.93. Closing the issue for now

Navigation Menu

Repository navigation

Docker Desktop 4.91.0 -> 4.92.0 breaks WSL integration #695

Bug report

Platform

Version information

Diagnostics ID

Environment

Symptom 1: WSL integration crash on every startup

Symptom 2: VS Code Dev Containers broken independently of the popup

Fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Docker Desktop 4.91.0 -> 4.92.0 breaks WSL integration #695

Description

Bug report

Platform

Version information

Diagnostics ID

Activity

RonStoppable1 commented on Sep 21, 2026

almutareb commented on Sep 22, 2026

ntnamazu commented on Sep 22, 2026

chris-aok commented on Sep 22, 2026

Environment

Symptom 1: WSL integration crash on every startup

Symptom 2: VS Code Dev Containers broken independently of the popup

Fix

dave00000 commented on Sep 22, 2026

mat007 commented on Sep 23, 2026

lwsrbrts commented on Sep 23, 2026

rhnatiuk commented on Sep 23, 2026

mat007 commented on Sep 23, 2026

almutareb commented on Sep 23, 2026

lwsrbrts commented on Sep 23, 2026

lwsrbrts commented on Sep 23, 2026

gustavcke commented on Sep 23, 2026

rhnatiuk-cad commented on Sep 24, 2026

Fereffe commented on Sep 24, 2026

gustavcke commented on Sep 24, 2026

bsousaa commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions