Windows 10 logon failure: the user has not been granted the requested logon type at this computer

Replies

6 suggested answers

·

4 replies

Add heading textAdd bold text, <Ctrl+b>Add italic text, <Ctrl+i>

Add a quote, <Ctrl+Shift+.> Add code, <Ctrl+e>

Insert Link

Add a bulleted list, <Ctrl+Shift+8>Add a numbered list, <Ctrl+Shift+7>Add a task list, <Ctrl+Shift+l>

Directly mention a user or teamReference an issue or pull request

Add heading textAdd bold text, <Ctrl+b>Add italic text, <Ctrl+i>Add a bulleted list, <Ctrl+Shift+8>Add a numbered list, <Ctrl+Shift+7>Add a task list, <Ctrl+Shift+l>

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?

Chuli2k, bobchaos, psprogis, JanRK, KineticTheory, DrakezulsMinimalism, jamestharpe, bruno-brant, FauxPrada, rosti-il, and 5 more reacted with thumbs up emojiristo-mononen reacted with eyes emoji

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

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

• CreateInstanceBegin
• CreateInstanceEnd
• CreateVmBegin
• Error
  -VerboseLog

lxcore_kernel = empty

lxcore_user

Microsoft.Windows.Subsystem.Lxss

• LxssException

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

That immediately solved the problem for me.

JonoGWhite, Mikecom32, AadamZ5, swebs, sergeyfrontier, ard0gg, jasonpugsley, elicutler, Hans-Seek, nickosh, and 33 more reacted with thumbs up emojiAadamZ5, darrenmonahan, curd0, Aqirito, bigtyre-isaac, and bsaavedrabo reacted with hooray emojiKarloZKvasin, fennovj, Aqirito, thomazmoura, JavierOlazaran, mberz, and bsaavedrabo reacted with heart emojistephen-miller-noaa, bevanj, and bsaavedrabo reacted with rocket emoji

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

alaincao, pengzh9666, vdsbenoit, karoldeland, kayu1, cbrwflo, EvilCat108, DrMagPie, AlexandreHetu, FahadHussain, and 56 more reacted with thumbs up emoji

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

andrewspencer, danielmcmillan, lectricas, savbace, enhsaihan-d, BOCbMOU, orrishu, badjr, Catfoodman, zodiake, and 21 more reacted with thumbs up emoji

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

GutierrezDev, Aebian, JanRK, lectricas, enhsaihan-d, BOCbMOU, orrishu, Catfoodman, colawebrunner, durakk1, and 8 more reacted with thumbs up emojidurakk1 reacted with hooray emojidurakk1 reacted with rocket emoji

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.

byrontuckett, MavAlpha, tlofgren, djadeja, emilhe, baskeville, ksy101, pattarika, jessiewestlake, durakk1, and 25 more reacted with thumbs up emojidurakk1, AbdullahGheith, antonioestival, harbutler, feamelo, luiseduardosc, mannharleen, and GHMeyer0 reacted with hooray emojifeamelo, luiseduardosc, and mannharleen reacted with heart emojidurakk1, gregbown, AbdullahGheith, antonioestival, feamelo, luiseduardosc, mrcomoraes, mannharleen, and CoDen256 reacted with rocket emoji

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.

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.

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?

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!

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.

• Mounted ISO files become inaccessible while in use by the VM
• VMs wont start because the files become inaccessible
• Various paths cannot be used because the Hyper-V service has no access to them
  I also suspect the Windows Subsystem for Android will end up with these type of issues

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.

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

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

Restart-Service vmcompute this worked on windows

Windows 10 Enterprise
OS Build 2021.12.17.26246216

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!

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

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

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.

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.

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

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

Having the same issue on corporate computer.

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.

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.

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.

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.

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.

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

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

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.

What has not been granted the requested logon type?

How do I grant allow log on locally permissions to domain user accounts?

What is a logon Type 10?

What is logon failure?