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

[nd368park]

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]

etl trace indicates an exception was thrown from

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

[craigloewen-msft]

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

[fangxy]

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]

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

[fangxy]

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

I tried but IT has no idea.

[nd368park]

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.

[Chuli2k]

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]

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]

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]

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

[Stat-Kaya]

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

[Chuli2k]

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

[ksalm]

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

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

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

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]

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]

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]

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

[GutierrezDev]

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]

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]

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]

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

[augustsix]

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]

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

[sejapou]

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]

Restarting VMMS service via Powershell worked for me.

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

[swebs]

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

[julianonunes]

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.

[Sieboldianus]

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]

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

[ajkessel]

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

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]

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

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!

[aleon1220]

Everyone please read this thread.
Most useful solution is to

Restart-Service vmcompute

• What works for me that i am on a corporate laptop is to reboot and start up Windows Terminal at start up time. I wait for about 7 minutes for MSTeams, Windows terminal, WSL and the ubuntu instance to load.
• I noticed the corporate laptop fetches some policies from the server. It needs internet for this. If the laptop has no internet, things tend to break. Annoying and slow but once is running is pretty stable.

[ajkessel]

Everyone please read this thread.

Most useful solution is to

Restart-Service vmcompute

My suggestion also provides a durable solution that doesn't require the user to do anything manually. Assuming you have the rights to add log-on scheduled tasks and can run those commands as admin, you shouldn't see this issue anymore.

[Ownkel]

@ajkessel did you modify your GPOs as well after implementing your fix? As per my findings, the crash only happens when a GPO is applied that modfies the "Log on as a service" Permission (SeServiceLogonRight).

[ajkessel]

@ajkessel did you modify your GPOs as well after implementing your fix? As per my findings, the crash only happens when a GPO is applied that modfies the "Log on as a service" Permission (SeServiceLogonRight).

No, I didn't do anything other than run that snippet of code as a logon task. Nothing else.

[Ownkel]

Did you have a GPO in place that modifies "Log on as a service" permissions when the issue started? And if so, do you still have it active even after your fix? I disabled this setting completely and put something simliar to your script into the staging process of new clients (only once). That solved it for good.

[trallnag]

It is so weird. Got a new laptop and started to have this problem. At the same time on my older laptop it is working fine. Same Windows version.

[barbuslex]

Same issue on WSL2 and Windows 11 (x64) for me after long sleep (maybe group policy refreshing by it admins ?).
The Restart-Service vmcompute works for me.

[pa-0]

@aleon1220:

I'm also on a domain-joined machine here (Windows 11 Enterprise), but we do not use 1Password... Could you please shed some light on the connection (if any) between starting that program and getting WSL to work? ...not seeing the connection

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.

[pa-0]

@Ownkel, could you share the script you're using?

Did you have a GPO in place that modifies "Log on as a service" permissions when the issue started? And if so, do you still have it active even after your fix? I disabled this setting completely and put something simliar to your script into the staging process of new clients (only once). That solved it for good.

[Ownkel]

Sure, but this approach isn't as effective as the previously mentioned native PowerShell method.

function Add-ServiceLogonRight([string] $Username) {
    Write-Host "Enable ServiceLogonRight for $Username"

    $tmp = New-TemporaryFile
    secedit /export /cfg "$tmp.inf" | Out-Null
    (gc -Encoding ascii "$tmp.inf") -replace '^SeServiceLogonRight .+', "`$0,$Username" | sc -Encoding ascii "$tmp.inf"
    secedit /import /cfg "$tmp.inf" /db "$tmp.sdb" | Out-Null
    secedit /configure /db "$tmp.sdb" /cfg "$tmp.inf" | Out-Null
    rm $tmp* -ea 0
}

Add-ServiceLogonRight "*S-1-5-21-XXXXXXXXXXXXXXXXXXXXXXX"

[ajkessel]

Sure, but this approach isn't as effective as the previously mentioned native PowerShell method.

Is this equivalent to my solution except it allows you to specify the username?

[Ownkel]

@ajkessel I think your solution would also allow the specification of the username (as SID) but you're using the group "NT VIRTUAL MACHINE\Virtual Machines" instead. Are you adding the end users to this group?

[ajkessel]

@Ownkel I'm not adding users to the group. This is just on my own box, and I'm in groups Administrators and Users, no others. wslservice and vmcompute run as system, not as the user, so I wouldn't think the end user would need to get the SeServiceLogonRight for WSL to run. I don't have a deep understanding of any of this, though, I just arrived at my solution through some trial and error.

[pa-0]

Seems like Microsoft might stand to benefit from open sourcing WSL at this point...

[aleon1220]

@aleon1220:

I'm also on a domain-joined machine here (Windows 11 Enterprise), but we do not use 1Password... Could you please shed some light on the connection (if any) between starting that program and getting WSL to work? ...not seeing the connection

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.

hi sure,
that was for my previous laptop. Using that flow ensured that everything worked. Doing things in a different order would NOT work for me. I didnt have the time to debug and find out why. I requested a new cool laptop with a fresh windows11 OS and WSL with ubuntu22 and i no longer have that issue.

[Sieboldianus]

Add-WindowsRight -Name SeServiceLogonRight -Account $sid

This gives me an error, telling me that Add-WindowsRight was not found (elevated ps).

[trallnag]

@Sieboldianus, the function comes from the following package https://www.powershellgallery.com/packages/psprivilege/0.2.0.

[Sieboldianus]

Thanks. After a few days, I can says that this does not work.

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

I still need to run:

Restart-Service vmcompute

... once, after booting Windows, to be able to start WSL2.

[ajkessel]

I believe the WindowsRight command needs to run before WSL launches. I have it set as a scheduled task triggered by login.

It might depend on how your domain's group policy is applied.

[Sieboldianus]

The issue is back - is it possible thatthe system identifier S-1-5-83-0 changed with a recent Microsoft Windows Update?

I added

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

.. to a powershell script that is executed after system boot and the issue disappeared for the last two months. Now it starts appearing again.

[davhsantos]

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.

This solution solved it for me. At least for now

[KarakayaFSM]

Thanks. After a few days, I can says that this does not work.

Install-Module -Name psprivilege
$sid = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-83-0")
Add-WindowsRight -Name SeServiceLogonRight -Account $sid
I still need to run:

Restart-Service vmcompute
... once, after booting Windows, to be able to start WSL2.

this worked for me