Can't open WSL2 distro - "The specified file is encrypted and the user does not have the ability to decrypt it"

[aaazalea]

Environment

Windows build number: 10.0.19041.0
Your Distribution version: Ubuntu 20.04
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Some other possibly relevant information:

• I have Docker Desktop installed, and it's set to use the WSL 2 backend. I don't use it though, I couldn't get it to talk to my WSL2 systems properly so I'm running docker inside the guest OS instead.
• my user account is not an administrator, though I have an administrator account on this computer. This is a security precaution.

Steps to reproduce

I'm not sure the exact steps to reproduce this. Now that I'm having the issue, all I need to do is (now for either of my two WSL2 distributions, but previously only one) try to open a WSL command line.

Things that might or might not be relevant:

• This happened to one of my systems a few weeks ago, and I couldn't fix it so I gave up and installed another WSL distro. This is the second time it's happened.
• Maybe it started when my computer ran out of battery and did not cleanly shut down?
• For my first distro on which this occurred, maybe it started when I ran sudo ifconfig eth0 down in the guest OS? I was trying to debug this issue [WSL2] Checkpoint VPN breaks network connectivity #4246 which eventually one of the workarounds in that issue helped me with in the second WSL installation.

I've also tried downgrading to WSL 1 but I get the same error.

Expected behavior

I get access to my WSL VM

Actual behavior

PS C:\Users\Jakob> wsl
The specified file is encrypted and the user does not have the ability to decrypt it.

Here's the strace wsl output: https://gist.github.com/jakob223/a6f95c14cef7895af07b9d71b026ada6
And the detailed logs: detailed_logs.zip

[sirredbeard]

Do you have any third-party security or antivirus software installed?

It appears that something is blocking access to C:\Windows\System32\lxss\LxssManagerProxyStub.dll link

onecore\vm\wsl\lxss\lxcmdlineshared\hcs.cpp(252)\lxssmanager.dll!00007FFD94D64A51: (caller: 00007FFD94D64783) 
Exception(4) tid(187c) 80071772 The specified file is encrypted and the user does not have the ability to decrypt it.
    Msg:[(null)] 

[aaazalea]

Yep, I'm running Sophos Endpoint Agent (or my employer is, anyway). Does that seem like a plausible culprit?

It doesn't list any events that look like blocking access to that DLL, but maybe it's not important enough to make the event list.

[sirredbeard]

It's a possible culprit yes, but other causes should not be ruled out.

[abagonhishead]

This was happening to me too - not sure if this will help you @jakob223, but I worked around the issue by finding the distro's Appx package under c:\Program Files\WindowsApps\

$ gci 'C:\Program Files\WindowsApps\' -Filter '*Canonical*'


    Directory: C:\Program Files\WindowsApps


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----l        25/07/2020     18:38                CanonicalGroupLimited.Ubuntu20.04onWindows_2004.2020.424.0_x64__79rhkp1fndgsc

Then copying everything in there into a separate directory on the root of your drive.
If you copy them using Windows Explorer, you'll probably get an error saying something like 'your organization doesn't allow copying this file here' for the AppxMetadata & Assets directories - I fixed this by creating directories with the same names inside the new directory at the root of my drive, and then copying the child files of AppxMetadata & Assets inside them both. It might prompt you saying that encryption isn't supported in the new directory, just click OK.

You should (hopefully) be able to start the distro, at least running the executable seems to work for me. There's also an ext4 disk image in the new directory afterwards, so I'm assuming this is where the distro will run from - make sure you don't delete it afterwards.

[jsaus2003]

I had this issue and my fix was similar to @abagonhishead . I had to give myself permissions to the Program Files\WindowsApps folder and COPY (cutting did not work) to a folder in the root directory. After that I ran Kali.exe as administrator from the newly copied location.

[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!