microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.34k stars 814 forks source link

The user has not been granted the requested logon type at this computer #5401

Open nd368park opened 4 years ago

nd368park commented 4 years ago

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

  1. Follow the standard instructions to install WSL2 and distro
  2. Run WSL2 distro - everything works
  3. Close terminal Window
  4. wsl --shutdown
  5. gpupdate /force
  6. Try and run distro again = error

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?

nd368park commented 4 years ago

etl trace indicates an exception was thrown from

onecore\wsl\lxss\wsl\main.cpp(380) = 0x80070569

craigloewen-msft commented 4 years ago

Could you give us a link to the traces that you took? Thank you! :)

fangxy commented 4 years ago

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.

Biswa96 commented 4 years ago

Did you contact your IT admin or someone in your corp. about this issue?

fangxy commented 4 years ago

Did you contact your IT admin or someone in your corp. about this issue?

I tried but IT has no idea.

nd368park commented 4 years ago

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.

Chuli2k commented 4 years ago

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.

ksalm commented 4 years ago

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.

p-obrien commented 4 years ago

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.

darrenmonahan commented 4 years ago

Same as @piobrien. I work for Microsoft on the gaming side so happy to provide any debug info if it's helpful.

Stat-Kaya commented 4 years ago

Same as @piobrien. The Solution from @ksalm doesnt work for me.

Chuli2k commented 4 years ago

The solution from @ksalm also did not work for me. But I installed HyperV and now it seems to be working...

ksalm commented 4 years ago

@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.

Chuli2k commented 4 years ago

@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.

ksalm commented 4 years ago

@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.

alaincao commented 4 years ago

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.

bjmi commented 4 years ago

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

alaincao commented 4 years ago

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)"

crosbyja commented 4 years ago

Same issue, AD joined machine, restarting "Hyper-V Host Compute Service (vmcompute)" resolved.

GutierrezDev commented 4 years ago

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.

EdKingscote commented 4 years ago

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.

pjcard commented 3 years ago

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.

julianonunes commented 3 years ago

I have the same issue here, however I don't have Hyper-V installed

augustsix commented 3 years ago

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

ksalm commented 3 years ago

I can also confirm that restarting vmms works for me too. No need to pull group policies then.

sejapou commented 3 years ago

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

Mathariman commented 3 years ago

Restarting VMMS service via Powershell worked for me.

*remember to run as administrator if you are not a local admin already

image

swebs commented 3 years ago

I don't need to be an administrator to restart vmms... though I may be in the hyper-v administrators group...

julianonunes commented 3 years ago

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.

sejapou commented 3 years ago

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".

WSL Logon fix.zip

Mathariman commented 3 years ago

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

byrontuckett commented 3 years ago

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.

jwsinner commented 3 years ago

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:

  1. Open command prompt and run wsl --help. If I was able to get a response from this, I moved to step 2
  2. wsl --list --verbose This lists distros installed/running on WSL.
  3. wsl --shutdown shuts down all running instances
  4. wsl --unregister [distro listed from step 2, mine started with docker-desktop]
  5. Once it was unregistered I tried to delete my Docker folder in AppData. It got stuck because ext4.vhdx was still open in System but after a restart I was able to delete the whole Docker folder.
  6. At this point, I was able to use wsl in command prompt and PowerShell
  7. Reinstall Docker Desktop
MavAlpha commented 3 years ago

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

mrfreyman commented 3 years ago

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.

alex-pravdin-sn commented 3 years ago

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.

vdsbenoit commented 3 years ago

I believe this issue impacts docker desktop as described here : https://github.com/docker/for-win/issues/10985

fpdotmonkey commented 3 years ago

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)

  1. Close any open WSL sessions,
  2. Get-Service vmcompute | Restart-Service
  3. Open a WSL session

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]
MasterChiefmas commented 3 years ago

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.

pjpmosteiro commented 3 years ago

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: image

It solves doing a gpupdate/force on every reboot, but is a bit annoying.

rawrspace commented 3 years ago

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.

legas1 commented 3 years ago

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.

kulahad commented 3 years ago

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".

WSL Logon fix.zip

I had the same issue but I got it to work by updating the Task made by @sejapou to vmcompute instead of vmms.

WSL Logon fix vmcompute.zip

kimschurmann commented 3 years ago

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 :)

i810121 commented 3 years ago

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.

ChicagoJay commented 3 years ago

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?

fguendling commented 3 years ago

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.

ajkessel commented 3 years ago

Restarting vmcompute worked for me as well but the issue recurs frequently. Has anyone reported this directly to Microsoft?

bruno-brant commented 3 years ago

Same issue here. Restarting vmcompute does the trick, but it's bothersome to do this all the time.

rosti-il commented 3 years ago

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.