Installing KB4565503 appears to cause "access is denied" when starting WSL2 (custom VHDX location)

[thijsputman]

Environment

Microsoft Windows [Version 10.0.19041.388]
Ubuntu 20.04 LTS (GNU/Linux 4.19.104-microsoft-standard x86_64)
WSL2

Steps to reproduce

1. Move Ubuntu WSL2 VHDX to a custom location – see for example how to move the vhdx of wsl2 to other disk MicrosoftDocs/WSL#412 (comment)
2. Install KB4565503 – reboot
3. Attempt to start Ubuntu

Expected behavior

Being greeted by a Bash-prompt.

Actual behavior

Access is denied.

[process exited with code 4294967295]

Additional Info

The relation to KB4565503 is somewhat speculative: I installed the update this morning (CET) before starting my working day, at which point I was unable to start Ubuntu (worked fine yesterday).

The issue appears to be that ownership of the VHDX file got handed over to SYSTEM. Changing ownership back to my current user permanently resolves the issue. Alternatively, starting WSL2 from an elevated prompt resolves the issue without modifying the access rights of the VHDX.

I've only got one copy of Ubuntu installed on my machine (via the Windows Store), so I'm unable to say if other distros are affected too.

I do have Docker Desktop (WSL2) installed (for which I've also moved the VHDX files). Docker Desktop doesn't appear to be affected by this issue; its VHDX files are still owned by the correct user.

See also this post on Microsoft Answers: https://answers.microsoft.com/en-us/windows/forum/all/kb4565503-installed-then-wsl-2-failed-to-start/25794c4f-0b20-465e-bbdb-a8af3d9e0e88

[ctataryn]

This too is happening to me after that update. Thank you for the suggestion of changing the ownership. Is there any danger in doing so? I'm assuming that they changed the ownership for some specific reason?

[thijsputman]

This too is happening to me after that update. Thank you for the suggestion of changing the ownership. Is there any danger in doing so? I'm assuming that they changed the ownership for some specific reason?

The KB-article mentions some security related changes, but doesn't go into enough detail to make any definitive statements.

I'm no expert, but I guess there's a case to be made that someone (already having gained broad access to your system) might modify the VHDX and add some malicious code in there which – when you start WSL – would run with higher privileges than it regularly would...

Given what recently happened at Twitter, that person is probably be better off trying to socially engineer you out of some of your bitcoin though 🙂

[Uldiniad]

In my case running ubuntu as administrator and then reopening it without admin resolved the issue. I did notice that the folder containing my vhdx had Administrators as owner

[aslamdoctor]

Environment

Microsoft Windows [Version 10.0.19041.388]
Ubuntu 20.04 LTS (GNU/Linux 4.19.104-microsoft-standard x86_64)
WSL2

Steps to reproduce

1. Move Ubuntu WSL2 VHDX to a custom location – see for example MicrosoftDocs/WSL#412 (comment)
2. Install KB4565503 – reboot
3. Attempt to start Ubuntu

Expected behavior

Being greeted by a Bash-prompt.

Actual behavior

Access is denied.

[process exited with code 4294967295]

Additional Info

The relation to KB4565503 is somewhat speculative: I installed the update this morning (CET) before starting my working day, at which point I was unable to start Ubuntu (worked fine yesterday).

The issue appears to be that ownership of the VHDX file got handed over to SYSTEM. Changing ownership back to my current user permanently resolves the issue. Alternatively, starting WSL2 from an elevated prompt resolves the issue without modifying the access rights of the VHDX.

I've only got one copy of Ubuntu installed on my machine (via the Windows Store), so I'm unable to say if other distros are affected too.

I do have Docker Desktop (WSL2) installed (for which I've also moved the VHDX files). Docker Desktop doesn't appear to be affected by this issue; its VHDX files are still owned by the correct user.

See also this post on Microsoft Answers: https://answers.microsoft.com/en-us/windows/forum/all/kb4565503-installed-then-wsl-2-failed-to-start/25794c4f-0b20-465e-bbdb-a8af3d9e0e88

Can you give us the steps to change the permissions to current user? Thank You.

[tanant]

I didn't have to mangle permissions per se, as long as the instance is running I'm fine, so it looks like there's something that doesn't like starting up the instance without full control over the VHDX (I could also solve this by giving Users full control and not having to use an admin shell)

From one admin powershell

PS H:\> wsl --list --running
There are no running distributions.

and then from my regular non admin shell

PS C:\Users\tanant> wsl
Access is denied.

then bouncing back to the admin shell

PS H:\> wsl -u tanant
tanant@cuberdon:/mnt/h$

and in my regular shell

PS C:\Users\tanant> wsl -u tanant
tanant@cuberdon:/mnt/c/Users/tanant$

[andreialecu]

Ran into this same issue after the recent Windows update, the solution by @Uldiniad above worked.

Seems like I only needed to start it once as administrator. Afterwards it went back to normal. Same situation with custom VHD location.

[summatix]

I need to run it as administrator after every reboot. After running as admin, WSL works. But after I restart it goes back to the "access is denied" state until I re-run it as admin again.

[david-bakin]

Happened for me exactly as described by @thijsputman - on rollback of KB4565503 WSL2 ubuntu worked fine. Ubuntu is installed at an alternate location.

However, having read @Uldiniad 's comment I reinstalled KB4565503. I noticed that the owner of the ext4.vhdx (and the containing directory) did not change. But I couldn't start wsl from a standard (unelevated) prompt.

I am now in @summatix 's situation - after every reboot I run wsl as administrator, then everything works fine.

Windows version currently reporting as 10.0.19041.388. Ubuntu is 20.04.

[david-bakin]

I have now used the suggestion from here - https://answers.microsoft.com/en-us/windows/forum/all/kb4565503-installed-then-wsl-2-failed-to-start/25794c4f-0b20-465e-bbdb-a8af3d9e0e88 - and assigned Full Control to Users and i'm good even without the workaround.

[bardourbano]

I'm having the same issue as described by @summatix and @david-bakin . In addition, to be sure if the problem was with my Ubuntu with alternate locale (or with Ubuntu distro in general) i've installed a Debian from Microsoft Store without any changes. It worked but, when I restarted my system it stoped working and started showing the same error message.

[fasterinnerlooper]

@david-bakin The link in your suggestion worked for me. Thanks for posting that.

[Jan1torEarl]

Same issue here. Getting Access denied after every reboot when trying to start WSL via either the wsl or bash commands, unless I ran it from an administrator prompt.

Rather than uninstalling KB4565503, simply locating and granting my user full permission to the .vhdx virtual disk file fixed it.

[benhillis]

Another thing you can do to resolve this:

1. (as admin) wsl.exe --set-version distro 1
2. wsl.exe --set-version distro 2

[ducttapecoder-vt]

I have a similar but different variation of this issue.

I had WSL1 installed with Ubuntu 18.04 (manually as my network is air-gapped) which I had not used in many months.
I attempted to update Docker Desktop and it prompted me to switch to WSL2 from Hyper-V which I attempted (including installing the WSL2 update). Docker unfortunately crashed on start with an access denied error. I then went and tried to run wsl/ubuntu directly and got an Access is Denied error there as well.

I tried uninstalling Ubuntu, renaming the Ubuntu directory (the files didn't remove for some reason), re-installing Ubuntu, changing permissions on the directory to give users full control, disabling and re-enabling WSL (with restarts) including the WSL2 update, and removing the HKCU Lxss registry keys but to no avail.

Seeing the messages here about admin vs non-admin windows, I confirmed I can run WSL in a non-admin window but not in admin window (after a brief interlude to disable the GPO someone put in place that disabled UAC elevation prompts to be able to get a non-admin window). I put the Lxss reg keys back, unregistered my Ubuntu distro from the non-admin window, re-applied the WSL2 update, converted to WSL2 default wsl --set-default-version 2 and restarted Docker and it works.

I do not currently have any distro installed but still cannot run WSL.exe at all from admin shell (cmd/PoSH/etc). My original Ubuntu installation was not VHDX and was not in the %appdatalocal% folder; it was a folder structure under c:\Ubuntu. So there's something outside the VHDX file permissions or even any distro installations that's causing my problem.

For reference, I had a second internet connected computer (also Win 10 1909) I tried the Docker WSL2 update on and it works without issue from both admin/non-admin windows, but that machine never had WSL1/Ubuntu on it.

[garyo]

I'm seeing this too. I cannot run wsl at all -- I get "access is denied". I tried uninstalling wsl, and noticed that it did not remove c:\windows\system32\wsl.exe! I could not remove that myself in any way, so I eventually resorted to AdvancedRun which allowed me to remove it by running as TrustedInstaller. But now when I reinstall wsl (using powershell or the "windows features" dialog) it does not recreate wsl.exe. Seems like some further permissions issues are happening.
I am running Win11, fresh install as of a few weeks ago. WSL2. My vhdx is in a custom location (and I have docker, which creates its own vhdx files & distros -- those are in the standard location).
I tried sfc /scannow which replaced wsl.exe but I still get "access is denied".

I notice (using procmon) it tries to start c:\Users\me\AppData\Local\Microsoft\WindowsApps\wsl.exe which does not exist.

I am totally stuck at this point; short of a full OS reinstall I'm not sure what to do.

[jethas-bennettjones]

I have now used the suggestion from here - https://answers.microsoft.com/en-us/windows/forum/all/kb4565503-installed-then-wsl-2-failed-to-start/25794c4f-0b20-465e-bbdb-a8af3d9e0e88 - and assigned Full Control to Users and i'm good even without the workaround.

@garyo The suggestion outlined in the link that David provided worked for me. Have you given it a try?

[garyo]

I have now used the suggestion from here - https://answers.microsoft.com/en-us/windows/forum/all/kb4565503-installed-then-wsl-2-failed-to-start/25794c4f-0b20-465e-bbdb-a8af3d9e0e88 - and assigned Full Control to Users and i'm good even without the workaround.

@garyo The suggestion outlined in the link that David provided worked for me. Have you given it a try?

Yes, I tried all the permission-related things, uninstall/reinstall, change ownership of wsl.exe and WindowsApps folders, etc.

I finally (just a couple of minutes ago) got it working again though! I had to not only uninstall wsl from "Turn Windows Features On/Off", but also uninstall all of my distros and all WSL-related items from "Add/Remove Programs" and reset Docker to factory defaults. At that point, weirdly, it started working again! (Yes, even before reinstalling anything. So c:\Program Files\System32\wsl.exe still existed.) After that I reinstalled things as per usual, and now I'm back working again. I cannot explain what was happening but it was extremely scary -- all my work is now in WSL.

[nbeny]

got access denied as administrator on every terminal (cmd and powershell as admin).
can't change permission of file ext4.

Uninstall Ubuntu, try to resinstall, install success after reboot and got access denied again

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!