I’ve recently been testing Microsoft’s Windows Subsystem for Linux feature to improve my development workflow for Linux from my Windows-based workstation. This new feature is super promising/exciting, especially since Microsoft is planning to ship a full Linux Kernel with WSL2.
However, I recently experienced an issue with WSL where I was unable to interact with it at all, with my system telling me ‘Access is Denied’ and ‘Error 0x80070005’. This was odd, since my WSL distro (Ubuntu 18.04) had been working previously.
wslconfig.exe /l Access is denied. .\wsl.exe Access is denied.
I even tried reinstalling my distro:
.\ubuntu1804.exe Installing, this may take a few minutes... WslRegisterDistribution failed with error: 0x80070005 Error: 0x80070005 Access is denied.
Whenever something breaks, the first question I ask myself is ‘what changed recently?’. In my environment context, there were two possibilities:
- My organization heavily implements security benchmarks from the Center for Internet Security (CIS) for our systems, and we are constantly testing new policies to test how well we can lock down our systems to improve our security posture. In fact, I had to set up an exception group policy to allow the LxssManager service to run on my workstation initially.
- I recently upgraded my work machine from Windows 10 1803 to 1903 in order to gain access to the development build of Windows Terminal.
Of the two potentially breaking changes, the upgrade of my work machine seemed like the most likely culprit. However, after troubleshooting the issue, it turned out to be a little of both.
In order to set up WSL on my workstation initially, I had to allow the LxssManager service to run by creating a new group policy to make an exception for the service in our security baselines. This process is detailed here.
This group policy (and more specifically, the security template) was created on my workstation when I was running Windows 10 1803. Something about the security template that was generated on my Windows 10 1803 workstation did not sit well with my workstation after it was upgraded to Windows 10 1903. After rebuilding the group policy with a security template from Windows 10 1903 (following the steps in the article linked above), I was able to access my WSL instance again.