Open nd368park opened 4 years ago
etl trace indicates an exception was thrown from
onecore\wsl\lxss\wsl\main.cpp(380) = 0x80070569
Could you give us a link to the traces that you took? Thank you! :)
I got same issue here. Windows version 2004
wsl --shutdown wsl Logon failure: the user has not been granted the requested logon type at this computer.
Did you contact your IT admin or someone in your corp. about this issue?
Did you contact your IT admin or someone in your corp. about this issue?
I tried but IT has no idea.
Could you give us a link to the traces that you took? Thank you! :)
Sorry company policy prevents that but here are the events as viewed in WPA
lxcore_service
Microsoft.Windows.LxssManager
lxcore_kernel = empty
lxcore_user
Microsoft.Windows.Subsystem.Lxss
There is no additional information in any other column displayed in WPA (apart from threadid, processid) even when all are turned on.
Started to get the same error. Also an AD connected machine.
Tried to reintall Ubuntu and now i get this error:
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80070569
Error: 0x80070569 Logon failure: the user has not been granted the requested logon type at this computer.
I started to get the same issue after upgrading to Win10 2004. Since my workstation is also connected to AD and I am certain that my user rights have not been changed I tried to reload our group policy
gpupdate /force
That immediately solved the problem for me.
I can reproduce the issue with WSL2 on Windows 10 Version 2004 with Ubuntu 20.04.
It appears when a background group policy refresh runs you're unable to launch WSL2 again, if you leave it running everything works until a relaunch.
Have tried granting the special user "VIRTUAL MACHINE\Virtual Machines" logon as a service role via a Group Policy and it hasn't made any difference.
Same as @piobrien. I work for Microsoft on the gaming side so happy to provide any debug info if it's helpful.
Same as @piobrien. The Solution from @ksalm doesnt work for me.
The solution from @ksalm also did not work for me. But I installed HyperV and now it seems to be working...
@Chuli2k I already had HyperV installed but the problem still occured. I also noticed that when I reboot my system I am no longer able to run WSL2 distros as before. My proposed "gpupdate" still solves the issue for me though - until the next reboot that is.
@ksalm I also installed "Platform for hypervisor" and "Platform for virtual computers" if that made any difference. Note: I translated the names to english, so the names can be a bit different.
@Chuli2k I think its "Hyper-V Platform" and "Virtual Machine Platform" and I also have them both activated. Though the issue is still not entirely resolved for me. My workaround doesn't take to much time, so I keep forcing a group policy update for the time beeing. It's kind of annoying but I can live with it.
Heylow all, this note just say that I have the same error from time to time.
I do "hibernate" the computer every evenings instead of doing a complete shutdown. This issue does appear sometimes after a computer wake up.
The gpupdate /force
does not fix. OTOH, a complete reboot does.
If this error occurs
Logon failure: the user has not been granted the requested logon type at this computer.
Press any key to continue...
I restart Hyper-V Virtual Machine Management (vmms) service. Then it works again until next hibernate.
powershell restart-service vmms
Hey, the restarting Hyper-V trick works for me, many thanks!
Except the name of the service to restart for me is "Hyper-V Host Compute Service (vmcompute)"
Same issue, AD joined machine, restarting "Hyper-V Host Compute Service (vmcompute)" resolved.
Same issue, AD joined machine, restarting "Hyper-V Host Compute Service (vmcompute)" resolved.
This also worked for me too. I have this issue since Windows 10 2004 update. This is the first command that worked that didnt required me to reboot my system. Thanks guys. Hope this issue is fixed soon.
I also have this problem on 1909 (18363.1082) with WSL Update 4.19.104 on an AD joined machine with u18.04 using WSL2. I'm not seeing anything in the GPReport that would trigger, and as far as I know our IT team haven't changed anything that would impact this. gpupdate /force without reboot has resolved for now.
powershell restart-service vmms
works for us as a temporary fix. When will this be fixed properly? We're relying on WSL to build our production services, so having it potentially break with each update is not ideal.
I have the same issue here, however I don't have Hyper-V installed
I have the same issue. restarting vmms works for me. Ubuntu 20.04 LTS. WSL2. Windows 10 19041.508. AD joined computer. Did not have this issue with WSL. started after upgrading Windows 10 and installing wsl2
I can also confirm that restarting vmms works for me too. No need to pull group policies then.
I can also confirm that restarting vmms works for me too. No need to pull group policies then.
Windows 20H2 and Ubuntu 2.04.1
Restarting VMMS service via Powershell worked for me.
*remember to run as administrator if you are not a local admin already
I don't need to be an administrator to restart vmms... though I may be in the hyper-v administrators group...
How about when you don't have Hyper-V installed and still gets Logon failure: the user has not been granted the requested logon type at this computer.
?
As I don't have Hyper-V installed, I can't restart vmms.
Restart-Service: Cannot find any service with service name 'vmms'.
UPDATE
Just found that in my case I have to run Restart-Service vmcompute
, then it works again.
I have made a "Task Scheduler" task that restarts the VMMS service when any user logs on. Unzip the attachment and import the xml file with "Task Scheduler".
I don't need to be an administrator to restart vmms... though I may be in the hyper-v administrators group...
You are probably right. I am in a domain environment and not a local administrator
Same scenario - domain joined.
Solution by @julianonunes rocked it. Restart-Service vmcompute
👍
When I used Hyper-V with Linux containers (don't really think that matters) I had to restart-service vmms
all the time.
Just had this issue happen to me. Using PowerShell resulted in either the user has not been granted error, or running as Administrator resulted in Access Denied. I was able to resolve the issue by doing the following:
wsl --help
. If I was able to get a response from this, I moved to step 2wsl --list --verbose
This lists distros installed/running on WSL.wsl --shutdown
shuts down all running instanceswsl --unregister [distro listed from step 2, mine started with docker-desktop]
I got this today after the computer resumed from hibernation. After reading the comments on this site I found restarting the vmcompute service fixed the problem for me.
From an Administrator command prompt run the following: sc stop vmcompute sc start vmcompute
To check its running you can use: sc query vmcompute
If you want to do it in one line you can probably use the following: sc stop vmcompute && sc start vmcompute & sc query vmcompute
Existing Docker Desktop, then stopping and restarting the Hyper-V Virtual Machine Management Service via the Microsoft Management Console allowed me to then restart Docker Desktop and cleared the error "System.InvalidOperationException: Failed to deploy distro docker-desktop to C:\Users...\AppData\Local\Docker\wsl\distro: exit code: -1 stdout: Logon failure: the user has not been granted the requested logon type at this computer.". No reboot was required.
This issue happens on my machine every time it wakes up. The machine is in a domain. Very weird because WSL1 distros work perfectly but WSL2 requires workarounds on every wake-up. I have to restart the Hyper-V service to make WSL2 work again.
I believe this issue impacts docker desktop as described here : https://github.com/docker/for-win/issues/10985
Just ran into this issue on Windows 10 Version 20H2 (OS Build 19042.928), WSL 2, Ubuntu 18.04.
Running Restart-Service vmcompute
as others have suggested didn't help and resulted in this output.
> Restart-Service vmcompute
Restart-Service : Service 'Hyper-V Host Compute Service (vmcompute)' cannot be stopped due to the following error:
Cannot open vmcompute service on computer '.'.
At line:1 char:1
+ Restart-Service vmcompute
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (System.ServiceProcess.ServiceController:ServiceController) [Restart-Service
], ServiceCommandException
+ FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Commands.RestartServiceCommand
I was able to fix by rebooting the whole computer.
A colleague that also has experienced this problem was able to solve with these steps (without rebooting)
I didn't know about them before I rebooted, so I'll try them next time I run into the issue.
Here's the exact error I got on the failed WSL login
Logon failure: the user has not been granted the requested logon type at this computer.
[process exited with code 4294967295]
This is a more general Hyper-V problem that's been around for years, so I don't have any hope it'll will get fixed any time soon. I've run into it at least since 2012R2. I've tried fixing it on and off over the years, Microsoft has various articles on it, or posts, or what have you about doing so. None of the fixes ever seem to completely resolve it, and it particularly seems to happen with domain connected systems (I think Hyper-V related services try to run as local services and end up with permission issues once the machine is added to the domain).
I've never managed to permanently resolve it, once it starts happening, I've always had to restart the VMM service sooner or later, and it's so trivial and non-impactful I've ended up just living with it. It's been tricky to troubleshoot since a lot of the suggested fixes end up restarting the VMM service anyway, masking, in the short term, whether or not the fix actually worked. All that said, I'd love it if someone really does get the permissions(which is what I think it is) permanently sorted, or figures out why the creds seem to expire after a while, necessitating the service restart.
Hi there, another one with this problem. I´ve been using WSL1/WSL2 for two years, no problem until last week that I did a gpupdate /force. Now the system shows me the error:
It solves doing a gpupdate/force on every reboot, but is a bit annoying.
Domain connected machine with Windows 10 Version Enterprise (OS Build 21387.1), WSL 2, Ubuntu 21.04 and this issue occurs for me daily.
Running gpupdate /force
does not resolve it for me but like @fpdotmonkey said. I have a shortcut on my desktop that runs as administrator and executes a .cmd script with:
PowerShell -Command "Get-Service vmcompute | Restart-Service -Force"
So if I get the error I close all my WSL windows, run the shortcut, and then relaunch and it works....I dislike that I have to do this but it is a little more convenient than typing it each time.
Just ran into this issue on Windows 10 Version 20H2 (OS Build 19042.928), WSL 2, Ubuntu 18.04.
Running
Restart-Service vmcompute
as others have suggested didn't help and resulted in this output.> Restart-Service vmcompute Restart-Service : Service 'Hyper-V Host Compute Service (vmcompute)' cannot be stopped due to the following error: Cannot open vmcompute service on computer '.'. At line:1 char:1 + Restart-Service vmcompute + ~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (System.ServiceProcess.ServiceController:ServiceController) [Restart-Service ], ServiceCommandException + FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Commands.RestartServiceCommand
Start the console as Administrator.
I have made a "Task Scheduler" task that restarts the VMMS service when any user logs on. Unzip the attachment and import the xml file with "Task Scheduler".
I had the same issue but I got it to work by updating the Task made by @sejapou to vmcompute
instead of vmms
.
I switched to use the organizations Azure AD - that helped. But I have heard that you can run
Restart-Service vmcompute
And that will fix the issue...try it out :)
Hey, the restarting Hyper-V trick works for me, many thanks! Except the name of the service to restart for me is "Hyper-V Host Compute Service (vmcompute)"
This was the silver bullet for me. Thank you to all of ya.
I'm seeing the same issue The user has not been granted the requested logon type at this computer
.
VMWare guest, running Windows 10 Pro 21H1 (19043.1151). AD-joined.
Restarting the Hyper-V Computer Service got it back up and running. The bug is now 14 months old. Is there a permanent fix yet?
I just wanted to add that restarting the host computer resolved the issue for me, and I assume that it is related to the fact that I changed the Windows password recently on my host computer, without restarting afterwards.
Restarting vmcompute worked for me as well but the issue recurs frequently. Has anyone reported this directly to Microsoft?
Same issue here. Restarting vmcompute does the trick, but it's bothersome to do this all the time.
Same issue. Stopping the vmcompute
service works around this annoying bug. Docker Desktop starts this service again if stopped, so no need to restart, just stop it.
Fails to start any WSL distro with the error:
Logon failure: the user has not been granted the requested logon type at this computer
Environment
Windows 10 x64 10.0.19041.264 wsl2 Ubuntu 18.04 Windows Terminal 1.0 AD joined machine
Steps to reproduce
Expected behavior
Distro runs under wsl2
Actual behavior
Can't run any distro under wsl2
The question is what Group Policy, account privileges are required in order for wsl2 to run successfully?