Docker Desktop 4.88.1 fails to start WSL 2 engine: HCS E_ACCESSDENIED on Windows 26200

[jiangshngyue1123]

Description

Docker Desktop 4.88.1 cannot start its existing WSL 2 engine under the normal Windows user token.

Expected behavior

Docker Desktop should start the existing WSL 2 engine and preserve the existing Docker data disk, containers, and volumes.

Actual behavior

• docker version and docker info return: Error response from daemon: Docker Desktop is unable to start
• docker ps -a returns the same daemon error or HTTP 500 through //./pipe/dockerDesktopLinuxEngine.

Reproduction steps

1. Start Docker Desktop normally as the local Medium-integrity user.
2. Wait for the engine startup attempt.
3. Run docker version, docker info, or docker ps -a.

Relevant evidence

• Docker backend logs report Wsl/Service/AttachDisk/MountDisk/HCS/E_ACCESSDENIED while mounting the existing Docker data VHDX.
• The same local user can successfully run elevated wsl.exe --mount --bare --vhd <docker_data.vhdx> and then unmount it successfully.
• The failure persists after Docker runtime socket cleanup, WSL update from 2.7.11 to 2.7.12, successful DISM RestoreHealth, and successful SFC with no integrity violations.
• WSL and VirtualMachinePlatform are enabled; the Windows hypervisor is present.

Please advise whether this is a known Docker Desktop / WSL-HCS compatibility issue on Windows build 26200.9168, and whether there is a supported workaround that does not require resetting the existing Docker data disk.

Environment

• Docker Desktop 4.88.1
• Docker CLI 29.7.2
• Windows Home / Core, build 26200.9168
• WSL 2.7.12.0
• AMD Ryzen 7 4800H
• Backend: WSL 2

Diagnostics ID

B76A83B7-B77F-4907-AB31-C86314445658/20260831080702

[ytazky]

Hi @jiangshngyue1123,

Thanks for submitting a detailed report.

From my investigation, this isn't caused by Docker Desktop directly — Windows is denying WSL permission to attach your Docker data disk at D:\DockerDesktop\DockerDesktopWSL, and Docker Desktop was retrying silently instead of showing you the error.

As a workaround, please run wsl --shutdown and restart Docker Desktop; if it still fails, grant your account full control over that D:\ folder, or move the disk image location back to the default C: drive under Settings → Resources.

If you have a security software installed, temporarily disabling it and retrying is also worth trying.

If all of the above fails, please generate the latest Diagnostics ID and share it with us.

[jiangshngyue1123]

Hi @ytazky, thanks for looking into this.

I did some additional isolation work, and I don't think this is explained by a simple NTFS permission issue on D:\DockerDesktop\DockerDesktopWSL.

The key result is that the exact same Docker VHDX can be attached successfully from an elevated context, while the normal user / Docker Desktop HCS path fails with E_ACCESSDENIED.

Specifically:

From an elevated terminal, running wsl.exe --mount --bare --vhd <docker_data.vhdx> succeeds, and the disk can also be unmounted normally.

From my normal desktop user context, Docker Desktop / WSL fails during the HCS attach path with:

Wsl/Service/AttachDisk/MountDisk/HCS/E_ACCESSDENIED

The normal user can also open both Docker VHDX files directly with read and read/write access, so the user does not appear to be denied ordinary NTFS access to the files themselves.
I already isolated and cleared separate stale Docker runtime socket/reparse-point issues. Docker now gets past that stage and consistently fails later at the HCS VHD attach step.
WSL has been updated, and the problem still reproduces.
DISM /Online /Cleanup-Image /RestoreHealth completed successfully.
sfc /scannow reports no integrity violations.
Docker Desktop is running with its service available, but the medium-integrity desktop path still hits the HCS E_ACCESSDENIED.

Because elevated attach succeeds against the same VHDX, while the normal Docker Desktop/HCS path fails, could this be related to an HCS token/elevation boundary, service/user-context interaction, or how Docker Desktop is asking HCS/WSL to attach the VHD, rather than the VHD file ACL itself?

I have deliberately avoided moving or recreating the Docker data disk because it contains existing data that I want to preserve.

My previous Diagnostics ID is:

B76A83B7-B77F-4907-AB31-C86314445658/20260831080702

If you need a new Diagnostics ID from the current state, or a specific HCS/WSL/ETW trace captured while reproducing the failure, please let me know exactly what trace/log would be most useful and I can provide it.

I would especially appreciate clarification on why the same VHDX is attachable from an elevated WSL context but rejected through the normal Docker Desktop/HCS context.

[ytazky]

Hi @jiangshngyue1123,

I pulled the actual diagnostic behind your Diagnostics ID, and it shows the exact failure you found manually was already present from the very first report: Docker Desktop's own WSL2 engine hits Wsl/Service/AttachDisk/MountDisk/HCS/E_ACCESSDENIED on docker_data.vhdx, and your desktop session token is running at Medium integrity (not elevated) even though the account is a local admin — that's consistent with an HCS-level privilege boundary rather than an NTFS ACL issue.

Here are some next steps you could try:

1. Add your account to the Hyper-V Administrators local group (net localgroup "Hyper-V Administrators" /add), sign out and back in fully, then relaunch Docker Desktop. This is a plausible fix based on how HCS checks disk-attach permissions.
2. Could you generate one more fresh Diagnostics ID from the current state? Since WSL was updated since your first capture, I want to confirm the signature is unchanged.

Thanks.