search

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?

ajkessel commented 2 years ago

Looks like this long-standing and serious issue has not been assigned. Does anyone know how to get this onto Microsoft's radar? Really interferes with things like scheduled tasks that are expected to run wsl actions.

ajkessel commented 2 years ago

Just recently got a different error launching wsl: insufficient quota to complete the requested service. Restarting vmcompute fixed this as well. Maybe a new variation on this bug with Windows 10 release 21H2?

zbarr commented 2 years ago

Same here - fixed by restarting vmms (no need to log off) or gpupdate /force (have to log off). Coming up on 2 years with this one Microsoft!

nd368park commented 2 years ago

The problem is a lot broader than WSL. If you ever have had the misfortune of using Hyper-V (desktop) in a domain environment you will have found that all sorts of permissions errors randomly occur.

aleon1220 commented 2 years ago

I got this

>>
Updating policy...

Computer Policy update has completed successfully.
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.
aleon1220 commented 2 years ago

I got this

>>
Updating policy...

Computer Policy update has completed successfully.
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

after 10 minutes i executed it again and it was successful

Updating policy...                                                                                                                                                                                                                              Computer Policy update has completed successfully.                                                                      
User Policy update has completed successfully.

but it didnt work

aleon1220 commented 2 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 :)

This worked for me and my windows version Windows 10 Enterprise OS Build 19042.1348

sumanmadavapeddi commented 2 years ago

Restart-Service vmcompute this worked on windows

Windows 10 Enterprise OS Build 2021.12.17.26246216

ajkessel commented 2 years ago

I had set up a scheduled task to run the following on every suspend/resume: sc stop vmcompute && sc start vmcompute

Starting a few weeks ago, this was causing a BSOD in dxgkrnl.sys on every resume. It took me a long while to figure out the cause of the BSOD, but once I disabled this scheduled task on resume, I stopped getting BSOD.

It appears I need to wait some time after the resume to restart vmcompute to prevent BSOD.

This really needs to be fixed!

aleon1220 commented 2 years ago

I had set up a scheduled task to run the following on every suspend/resume: sc stop vmcompute && sc start vmcompute

Starting a few weeks ago, this was causing a BSOD in dxgkrnl.sys on every resume. It took me a long while to figure out the cause of the BSOD, but once I disabled this scheduled task on resume, I stopped getting BSOD.

It appears I need to wait some time after the resume to restart vmcompute to prevent BSOD.

This really needs to be fixed!

what a terrible operating system windows is. Pathetic they cannot invest to make things just work like in other more worthy OSes

mannharleen commented 2 years ago

Summarizing for the sake of wrapping this up (I hope). Any one of the following should work:

rawrspace commented 2 years ago

Summarizing for the sake of wrapping this up (I hope). Any one of the following should work:

  • Restarting the service called Hyper-V Host Compute Service (vmcompute) // manually
  • gpupdate /force // on cmd prompt
  • powershell restart-service vmms // on cmd prompt
  • Restart-Service vmcompute // on powershell
  • PowerShell -Command "Get-Service vmcompute | Restart-Service -Force" // on cmd prompt

These are only temporary solutions. Many people, myself included, have to setup jobs to run these on a schedule to keep things working.

Ownkel commented 2 years ago

I'm experiencing the same issue and I seem to have found the cause of it:

We have setup the security setting "Log on as a service". If I set this setting to "Not Defined" the above issue seems to be resolved. I can do gpupdate /force and wsl will work without restarting the vmcompute service.

I'm still looking into what we need to set in the Policy for it to work with the policy enabled.

edit: This policy restricts all users to log on as a service, except the set whitelist in this policy. I think if we manage to find what user needs to be put on the whitelist there would be no need to disable it completely.

farchide commented 2 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

powershell restart-service vmcompute

NPhMKgbDNy1M commented 2 years ago

Same here on corporate computer with group policies. powershell restart-service vmcompute as admin helps out.

ericsmacedo commented 2 years ago

Having the same issue on corporate computer.

widsinga commented 2 years ago

Had the same problem. Restarting vmms service resolved the issue, but after reboot same problem. Changing service logon setting to "Allow service to interact with desktop" resolved my issue permanently. image

bjmi commented 2 years ago

Had the same problem. Restarting vmms service resolved the issue, but after reboot same problem. Changing service logon setting to "Allow service to interact with desktop" resolved my issue permanently.

I cannot confirm this. For both services vmcompute and vmms Allow service to interact with desktop was activated but after some days

Logon failure: the user has not been granted the requested logon type at this computer.

occured again.

calle2010 commented 2 years ago

Had the same problem. Restarting vmms service resolved the issue, but after reboot same problem. Changing service logon setting to "Allow service to interact with desktop" resolved my issue permanently.

I did the setting on vmcompute only. Before I had the error multiple times a day, so far I haven't seen it anymore. So for me it seems to be at least a big improvement.

calle2010 commented 2 years ago

Unfortunately, I'm back at multiple occurrences of this problem per day even with "Allow service to interact with desktop". I really can't recommend WSL2 to my colleagues with this issue.

Here is an article that describes the same symptoms. But the cure is not available to me as I'm not the Domain Administrator. Annoying things like this scare developers away from Windows.

forrep commented 2 years ago

In my case, I solved the problem by simply registering a shortcut to wsl2 in the startup folder. The problem seems to occur if time passes without starting wsl2, so if I keep wsl2 started at the same time as OS startup and do not close it, the problem did not occur again after that.

Another solution is to install Docker Desktop, which will always start wsl2 on the backend, so the problem will not occur anymore.

widsinga commented 2 years ago

Had the same problem. Restarting vmms service resolved the issue, but after reboot same problem. Changing service logon setting to "Allow service to interact with desktop" resolved my issue permanently.

I cannot confirm this. For both services vmcompute and vmms Allow service to interact with desktop was activated but after some days

Logon failure: the user has not been granted the requested logon type at this computer.

occured again.

I can confirm that Changing service logon setting to "Allow service to interact with desktop" is not the solution to the problem. It seems this is quit a difficult problem for Microsoft to solve. The workaround I use now is a scheduled restart every morning at 6:00AM. No manual intervention anymore. For test environment good enough. Keeps you wondering though why the entire world is using these cr... features and pay for it

ajkessel commented 2 years ago

"Allow service to interact with desktop" did not fix it consistently for me either. The only reliable solution seems to be sc stop vmcompute && sc start vmcompute. I've reverted to WSL 1 for now since this is so bothersome.

thecoldwine commented 2 years ago

Same here on corporate computer with group policies. powershell restart-service vmcompute as admin helps out.

Does work for me quite often. Normally, I see this error when the time comes to change the password and it seems the old credentials being cached somewhere deep in the system.

AdamMcArdle commented 2 years ago

I've been struggling for months with having to restart the vmcomput service, but I found a proper solution today.

Start > Turn Windows Features on or off

Then ensure Hyper-V is ticked. For me it was completely unticked.

Click OK, restart.

Terminal now logs onto wsl fine, even after a restart.

SIGSTACKFAULT commented 2 years ago

gpupdate /force does the following for me, and doesn't fix anything: image

however, rebooting does. interesting.

adejonghm commented 1 year ago

Restarting the vmcompute service worked for me. From an elevated PowerShell (close WSL2 first though!):

wsl --shutdown

Get-Service vmcompute | Restart-Service

And then run WSL2 again.

ericsmacedo commented 1 year ago

After updating to Windows 11 22h2, an update appeared for me when I started WSL. After the update, I am not seeing the issue anymore. Seems to have been fixed.

kodsnutten commented 1 year ago

I've silently followed this issue for over a year to see if a permanent solution was found in place of the workround to restart VMMS service. I finally got "fed up" with restarting the VMMS service, so took a deep look at my logs and found the problem described in this Microsoft article.

To answer the OP's question, the special group "NT VIRTUAL MACHINE\Virtual Machines" (Well known SID S-1-5-83-0) needs to be added to the GPO that modifies the "Log on as service" privileges on your computer (talk to your domain admin). In my case it was the "Default Domain Policy" that modified the privileges. The special group has to be added to the GPO from a server/computer that has the Hyper-V feature enabled!

PWM-BIA-TPA-PIE commented 1 year ago

I have verified that "NT VIRTUAL MACHINE\Virtual Machines" is being applied at the domain level. However, I continue to get this error intermittently after rebooting. The only workaround that works consistently is to execute these commands elevated (run as administrator):

net stop vmcompute
net stop LxssManager
net start LxssManager
net start vmcompute
max-hassani commented 1 year ago

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

thanks @bjmi. Your response saved me from restarting over and over again. Now I only start powershell as adminstrator and run:

restart-service "Hyper-V Host Compute Service"
Ochuwa-sophie commented 1 year ago

Running gpupdate while connected to the office internet and then restarting fixed this for me.

ajkessel commented 1 year ago

If I can't override my GPO to add "NT VIRTUAL MACHINE\Virtual Machines" to "log on as a service", is there any other solution short of restarting the wsl service every time this happens? On Win10 22H2.

K2ouMais commented 1 year ago

Yes, we need informations from Microsoft, so that we can inform our domain admins on how to fix this permanently. We are also on a AD and get this error, almost every time after a restart. The only way to get around this has been to run "restart-service vmms" on powershell, but I am looking forward for Microsoft to come around with a way how our admin can fix this for us without unprivileged rights.

ajkessel commented 1 year ago

The article linked above suggests a "method 1" that maybe doesn't require domain admin access?

Place the computer account for the Hyper-V Host in an Organizational Unit (OU) that doesn't have any policies applied, that manage user rights, and then run gpupdate /force command or reboot the computer. It should remove the user rights applied by policy and allow user rights defined in the local security policy to take effect.

Am I interpreting that correctly or does that still require domain control?

DontNeedNoGit commented 1 year ago

If I can't override my GPO to add "NT VIRTUAL MACHINE\Virtual Machines" to "log on as a service", is there any other solution short of restarting the wsl service every time this happens? On Win10 22H2.

Has anyone tried modifying the local security policy? If the domain admins aren't overriding your settings with GPO, then you changing this locally may help.

o secpol.msc o Expand to Local policies\User Rights Assignment o Open Log on as a service o Click Add user or Group button o Paste: NT Virtual Machine\Virtual Machines

ajkessel commented 1 year ago

Has anyone tried modifying the local security policy? If the domain admins aren't overriding your settings with GPO, then you changing this locally may help.

This setting is grayed out for me, even when I execute secpol.msc as administrator. I assume this means something in GPO is locking me out of the setting.

ajkessel commented 1 year ago

Is there another solution such as having the VM run as the logged-in user or local admin rather than a system service? I have local admin rights so it seems like there should be some way to separate WSL from any domain issues.

For example, could the VM run as a different local user?

ajkessel commented 1 year ago

I just noticed I have NT VIRTUAL\MACHINE\Virtual Machines enable in gpedit.msc->Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment->Log on as a service, even though I can't set it in secpol.msc. This does not seem to fix the problem.

sv222 commented 1 year 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.

"Restart-Service vmcompute"

fixed and worked for me from the administrator PowerShell.

ajkessel commented 1 year ago

I recently tried adding this to a PowerShell script run as admin at logon

$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

I haven't seen the error since then, although it seems to be somewhat random so perhaps too early to say it really fixed it.

Add-WindowsRight can be added to PowerShell from here

fartbagxp commented 12 months ago

"Restart-Service vmcompute" in an admin shell is the workaround that works for me!

ajkessel commented 12 months ago

I recently tried adding this to a PowerShell script run as admin at each logon

$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

After another week, this seems to have held up as the best fix I've found so far.

K2ouMais commented 12 months ago

It might be some fixes here but we still need something from Microsoft to fix this permanently. Not everyone has admin rights on the Maschine.

Sieboldianus commented 7 months ago

o secpol.msc o Expand to Local policies\User Rights Assignment o Open Log on as a service o Click Add user or Group button o Paste: NT Virtual Machine\Virtual Machines

I got the

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

issue with WSL2, but NT Virtual Machine\Virtual Machines is already added to the above policy!

trallnag commented 5 months ago

@ajkessel, what is this script doing? For me Restart-Service vmcompute seems to be enough

ajkessel commented 5 months ago

@ajkessel, what is this script doing? For me Restart-Service vmcompute seems to be enough

My script is intended to avoid ever having to restart vmcompute. It eliminates 99% of the problem when run at sign-on.

aleon1220 commented 5 months ago

I recently tried adding this to a PowerShell script run as admin at each logon

$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid

After another week, this seems to have held up as the best fix I've found so far.

i am under a corporate laptop and even though I have admin permissions I dont have access to certain policies. What works for me is the order in which i open the applications.

  1. Wait 5 minutes for Teams to load
  2. Open OnePassword
  3. Open VsCode or the Windows Terminal with WSL as the default
  4. wait 3 minutes

Doing it in that order and waiting always works for me.

trallnag commented 5 months ago

@ajkessel, since your post I've switched to your method (adding service logon right) instead of restarting vmcompute and it has been working fine. Thanks for that.

But I have no idea why it works. Checking the group S-1-5-83-0, it already has the correct permissions. Maybe it has something to do with how these policies are rolled out and applied on corporate devices. On my personal devices I'm not seeing this issue.

webstey commented 4 months 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.

This worked for me!