Store WSL isn't accessible from Session 0

[OneBlue]

Version

Multiple versions are affected

WSL Version

• WSL 2
• WSL 1

Kernel Version

No response

Distro Version

No response

Other Software

No response

Repro Steps

Store WSL currently isn't accessible from session 0 contexts.
This means that it's not possible to interact with WSL from remote sessions such as ssh or psremote.

If wsl.exe is called from session 0, it will exit and display:

Access is denied.

on stdout.

[yanorei32]

I think this issue is already tracked internally.
However, this problem continues even now.

Release Notes for Windows Subsystem for Linux in the Microsoft Store

...

Known Issues:

• Launching Windows Subsystem for Linux from session zero does not currently work (for example from an ssh connection).

https://learn.microsoft.com/en-us/windows/wsl/store-release-notes#known-issues

[benhillis]

Known issue, we're working on a solution.

[bagong]

This is a deal breaker for some. Would be nice to get notice when it is solved. Thanks!

[vakata]

Please fix this - I cannot remotely login to WSL using the builtin OpenSSH server, my scheduled tasks also stopped working.

[brentmjohnson]

Impact of this issue is complicated by the fact the store packaged version appears to now be required on the latest windows 11 insiders build (10.0.25267). Still looking for workarounds...

#9355
#9373

[enachi]

Please fix this - I cannot remotely login to WSL using the builtin OpenSSH server, my scheduled tasks also stopped working.

I had to uninstall store version of WSL to be able to run ssh server at system startup again

[bagong]

If policies make it difficult to enable Windows openssh to run WSL, an alternative/workaround might be to run a second openssh server (using a different port) within WSL. At the moment this seems not to be possible. But maybe that possibility can be enabled?

[rfc2119]

I am surprised by this. By default, I can access wsl from the native OpenSSH server by setting HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH to C:\Windows\System32\wsl.exe. I am using the store version with Ubuntu LTS 22.04

My problem is actually this: every time I initiate a SSH connection, I get a new WSL shell. I am unable to return back to the same session in case of disconnection events; all my background processes are gone. Each connection is therefore a new WSL instance.

Should I open another ticket for this ?

[bagong]

I am surprised by this. By default, I can access wsl from the native OpenSSH server by setting HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH to C:\Windows\System32\wsl.exe. I am using the store version with Ubuntu LTS 22.04

I've tried it back and forth on different installs several times, and it never worked. It's a few months ago - should it be fixed and noone here knows? Many have the issue, and it's even acknnowledged by MS... Weird!

My problem is actually this: every time I initiate a SSH connection, I get a new WSL shell. I am unable to return back to the same session in case of disconnection events; all my background processes are gone. Each connection is therefore a new WSL instance.

Should I open another ticket for this ?

I don't think so: interrupted ssh sessions are like logoffs, like closing a terminal emulator (historically speaking closing a terminal emulator is like logging off ;-) ) - you wouldn't expect to get your jobs back there, right... You want to look into tmux or something alike. They keep processes running wile you're off, and you can attach back to them from another shell...

[rfc2119]

I've tried it back and forth on different installs several times, and it never worked. It's a few months ago - should it be fixed and noone here knows? Many have the issue, and it's even acknnowledged by MS... Weird!

This looks weird indeed. Let me know if any of you would like more details. I just installed the "Ubuntu" app in the store using a local account.

You want to look into tmux or something alike. They keep processes running wile you're off, and you can attach back to them from another shell

It's exactly that! I don't find my tmux sessions when I log back in. In fact, I don't find the tmux process at all!

[bagong]

It's exactly that! I don't find my tmux sessions when I log back in. In fact, I don't find the tmux process at all!

I have no experience with tmux in WSL, so I can't comment from experience. But I'd think about whether your WSL - instance keeps running all the time, or wheter it has had a "reboot" in your time off - even tmux doesn't survive that ;-) Though maybe it can be made to autostart and continue processes? Dunno. I know that WSL's wakeup behavior from suspend is broken (it was in my version) - maybe another reason why tmux might vanish?

Or maybe you need to start your tmux processes in a local shell and let that run? Maybe you can then attach to running tmux from ssh and not shut WSL down by logging off?

And just to let others know: I did install the MS Store update again, and was immediately cut out of ssh-ing in. Fortunately it is enough to uninstall via the App-Icon that appears after the update, and the previous state returns... (i.e. no total reinstall of WSL required)

And yes, if I started tmux in a local shell and kept it running, I can ssh in and out multiple times and see that tmux live on happily...

Final remark for others like me who didn't realize (what for again others is likely self-evident): if it's just about ssh-ing into a running WSL from the outside (i.e. not about actually "booting" wsl): that is possible with the store version of wsl too. You access the host into a shell that doesn't depend on wsl, and from there you ssh into the running wsl: ssh -p n localhost. I guess sshd inside wsl needs to listen on a different port (n) than "outer"-Window's sshd (edit /etc/ssh/sshd_config). For my requirements that's actually tolerable ;-) , and one might consider the inability to start/stop wsl in a ssh-schell a protection of running processes inside wsl.

[joes]

As @bagong mentioned it is possible to install and run a second OpenSSH server (using a different port) in your WSL instance as a workaround.

This can then be combined with using the ProxyJump directive to transparently connect to the second OpenSSH server by jumping through the win32 OpenSSH server. The directive can be added to the remote system's ~/.ssh/config:

Host openssh_win32
    Hostname your_computer.local
    User windows_username

Host openssh_wsl
   ProxyJump openssh_win32
   User wsl_username
   HostName localhost
   Port 2222

The above example assumes that the second OpenSSH server in wsl is running on port 2222.

Using this configuration it is then possible to connect to the wsl instance via the hostname openssh_wsl:

ssh openssh_wsl

[ParagDoke]

While it is possible to get inside the WSL instance based on the proxy jump idea from @joes, this issue still needs to be fixed for use cases such as attempts to install a new WSL distribution on a remote Windows system over SSH.

In other words anything involving the WSL executable besides getting into an instance.

[yo1dog]

My use case is accessing WSL remotely after a cold boot.

I can turn on the PC remotely via WOL and SSH into a win32 OpenSSH server, but cannot start WSL from said SSH connection (session 0). Nor is it possible to start WSL automatically on boot before a user logs in to Windows (also session 0?). For example, you cannot use Task Scheduler's "Run whether user is logged on or not" option to start wsl.exe.

My workaround has been to use RDP just to login remotely and start WSL (which is started automatically on user login by Task Scheduler). Then I can SSH directly into WSL.

---

Does anyone know of a solution for either remotely initiating a Windows user login or remotely obtaining session 1 without the GUI overhead of the RDP/Remote Desktop app? Ideally command-line only.

[ParagDoke]

@yo1dog In an entirely different context, I know of a solution (batch file) that runs from the command line with GUI overhead, but:

• No certificate prompt on RDP client (no blanket suppression, suppress only for the IP / FQDN of your server)
• No wait on prompt for things like privacy settings, etc ... some 6 radio buttons that appear on an OOB Windows deployment

This batch file uses openssl, sed to obtain, mangle and register the cert hash for a given server to avoid that cert warning.

On the server, I place a different batch file in the Startup folder (your idea uses Task Scheduler). This could use the timeout command to sleep for a bit, and then logoff from the server (to gracefully terminate the RDP client) after your WSL instance has started.

%1 is the IP / FQDN of your server.

openssl s_client -connect %1:3389 < NUL 2>NUL | openssl x509 -fingerprint -noout | sed -e 's/://g' > %TEMP%\%1-rdp-fingerprint.txt
for /f "tokens=2 delims==" %%a in ('type %TEMP%\%1-rdp-fingerprint.txt') do (
    reg add "HKCU\Software\Microsoft\Terminal Server Client\Servers\%1" /v CertHash /t REG_BINARY /d %%a /f
)
start mstsc /f /v %1

To avoid OOB prompts, this needs to run even before the logon:

reg add "HKLM\Software\Policies\Microsoft\Windows\OOBE" /v DisablePrivacyExperience /d 1

For the script to be run at logon, I believe you already have one.

cmdkey /generic:TERMSRV/<IP or FQDN> /user:<username> /pass:<passwd> will let you save the password for logging in using an RDP client automatically.

[gmax9803]

@benhillis Has the team made any progress on this issue? And if not is there any quick fix to make this work?

[arrmo]

Also curious here - this is a bit painful, can't execute a WSL (bash) script from a service (Session ID 0).

Thanks!

[materigoprecitec]

For those who wan't to use WSL on a jenkins windows agent, here is my workaround.

Instead of connecting via a task scheduler to the jenkins controller, after the startup of the machine, I have a jenkins job running on a linux agent, which initiates a remote desktop connection to the windows agent.

In the windows task scheduler I have a task, which is started whenever a remote connection is made. This is then able to start the jenkins agent under a normal session, where wsl does in fact work.

The pipeline looks something like this:

pipeline {
    agent { label 'linux' }
    stages {
        stage('CheckAndStart') {
            steps {
                script {
                online_nodes = nodesByLabel 'windows'
                    if (online_nodes) {
                        echo "online, nothing to do"
                    } else {
                        echo "offline, therefore starting by connection with rdp"
                        sh "timeout 30 xvfb-run xfreerdp -v jenkins.agent.com -u user -p password -cert-ignore"
                    }
                }
            }
        }
    }
}

[LvffY]

From my side, seems like upgrading to wsl 2.0.6 (through wsl --update --pre-release) as made the issue disappear.

My setup :

• Remote connexion through SSH to my workstation
• run wsl -l -v
• Had the same result by the command run on my Windows workstation directly

(Will try other tests, but it's encouraging !)

[arrmo]

OK, this is really screwy. I previously ran wsl --update --pre-release, no issues. Tried it today, to get the latest, but now --update doesn't seem to be an available option for wsl?!?!

Thanks!

[ToeKneeFan]

OK, this is really screwy. I previously ran wsl --update --pre-release, no issues. Tried it today, to get the latest, but now --update doesn't seem to be an available option for wsl?!?!

Thanks!

@arrmo Are you running in an elevated terminal?

There is more than one wsl.exe binary. Perhaps try pointing directly to "C:\Program Files\WSL\wsl.exe" instead of just wsl.

[arrmo]

@arrmo Are you running in an elevated terminal?

Yep!

Very odd ... but I had to --install (again), then could update. Weird. Thanks!

[kitty-eu-org]

Is there any progress on this issue? I still can't use wsl with ssh

[LvffY]

From my side, seems like upgrading to wsl 2.0.6 (through wsl --update --pre-release) as made the issue disappear.

My setup :

• Remote connexion through SSH to my workstation

• run wsl -l -v

• Had the same result by the command run on my Windows workstation directly

(Will try other tests, but it's encouraging !)

Just to precise my answer : I found that this seems to work on all W11 workstation but only on some W10 ones.

So the issue seems not resolve for every configurations 😒

[kitty-eu-org]

从我的角度来看，似乎升级到 wsl 2.0.6 （通过wsl --update --pre-release）使问题消失。
我的设置：

• 通过 SSH 远程连接到我的工作站
• 跑步wsl -l -v
• 直接在我的 Windows 工作站上运行命令得到了相同的结果

（会尝试其他测试，但这是令人鼓舞的！）

只是为了准确回答我的问题：我发现这似乎适用于所有 W11 工作站，但仅适用于某些 W10 工作站。

所以这个问题似乎并不能解决所有配置的问题😒

I run wsl --version,get:

WSL 版本： 2.0.9.0
内核版本： 5.15.133.1-1
WSLg 版本： 1.0.59
MSRDC 版本： 1.2.4677
Direct3D 版本： 1.611.1-81528511
DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows 版本： 10.0.22621.2715

but this problem still exists.

[litian1992]

This is my setup:
wsl --version
WSL version: 2.0.11.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.2715

I tried:

1. Explicitly calling 'C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps\wsl.exe' or 'C:\Windows\System32\wsl.exe'
2. DISM.exe /Online /Cleanup-image /Restorehealth
3. Hit 'reset' and 'repair' buttons in WSL2 app
   which did NOT work.

What actually WORK for me:

1. Explicitly call 'C:\Program Files\WSL\WSL.exe'
   OR 2. Upgrade from 2.0.9 to pre-release 2.0.11

[rgl]

@litian1992 upgrading to 2.0.11 and executing c:\windows\system32\wsl.exe from within an ssh interactive session did not work here. calling C:\Program Files\WSL\WSL.exe worked, for 2.0.9 and 2.0.11.

still, there's use-case that is not working here. using an ssh client from linux to remotely invoke wsl as ssh Administrator@192.168.1.23 '"c:/Program Files/WSL/wsl.exe"' does not work here, it never shows the bash shell prompt that should be running inside the wsl distro. thou, when running ssh Administrator@192.168.1.23 to open a cmd.exe shell and then calling "c:/Program Files/WSL/wsl.exe" works, so something funky is still going on.

[montvid]

@rgl New install after upgrade to 2.0.11 works fine with microsoft ssh server - 2.0.9 does not work. Connecting from Linux with ssh -t administrator@ip "wsl ~" or with ssh administrator@ip and executing wsl ~.

[rgl]

@montvid ah, without -t it seemed not to work because there is no shell prompt for some reason, but typing a command does in fact work (e.g. ssh Administrator@192.168.1.23 '"c:/Program Files/WSL/wsl.exe"' --version). thanks for pointing that out!

[bayeslearner]

Here is a summary of a method I've been experimenting with to access WSL remotely via SSH, particularly effective post-reboot. Hopefully, this might be helpful for others:

1. Update to the Latest WSL Version (Dev Channel): Ensure you're running the latest WSL version from the dev channel for better compatibility and features. Check this with wsl --version. Example output should include 'WSL version: 2.1.0.0' and relevant kernel and Windows versions.

2. Configure WSL with NSSM: I've configured WSL to start under a specific user account using NSSM (Non-Sucking Service Manager). The command I used is something like -d Ubuntu -u root service dbus start. This helps in keeping WSL operational and accessible after your machine restarts.

3. SSH into Windows and Access WSL: After remotely connecting to the Windows host via SSH, I execute the wsl command to switch to the WSL shell. This method assumes WSL is continuously running in the background.

[pedrohgmacedo]

Here is a summary of a method I've been experimenting with to access WSL remotely via SSH, particularly effective post-reboot. Hopefully, this might be helpful for others:

1. **Update to the Latest WSL Version (Dev Channel):** Ensure you're running the latest WSL version from the dev channel for better compatibility and features. Check this with `wsl --version`. Example output should include 'WSL version: 2.1.0.0' and relevant kernel and Windows versions.

2. **Configure WSL with NSSM:** I've configured WSL to start under a specific user account using NSSM (Non-Sucking Service Manager). The command I used is something like `-d Ubuntu -u root service dbus start`. This helps in keeping WSL operational and accessible after your machine restarts.

3. **SSH into Windows and Access WSL:** After remotely connecting to the Windows host via SSH, I execute the `wsl` command to switch to the WSL shell. This method assumes WSL is continuously running in the background.

Using wsl to access the shell makes your terminal throughput 100x slower because of conpty.

[renhiyama]

Here is a summary of a method I've been experimenting with to access WSL remotely via SSH, particularly effective post-reboot. Hopefully, this might be helpful for others:

1. **Update to the Latest WSL Version (Dev Channel):** Ensure you're running the latest WSL version from the dev channel for better compatibility and features. Check this with `wsl --version`. Example output should include 'WSL version: 2.1.0.0' and relevant kernel and Windows versions.

2. **Configure WSL with NSSM:** I've configured WSL to start under a specific user account using NSSM (Non-Sucking Service Manager). The command I used is something like `-d Ubuntu -u root service dbus start`. This helps in keeping WSL operational and accessible after your machine restarts.

3. **SSH into Windows and Access WSL:** After remotely connecting to the Windows host via SSH, I execute the `wsl` command to switch to the WSL shell. This method assumes WSL is continuously running in the background.

Using wsl to access the shell makes your terminal throughput 100x slower because of conpty.

I oppose your point.
According to what @bayeslearner told us (thanks btw bayes!), u need to run just a simple command about service/systemctl to start a normal service. The command he suggested us will not output anything much.

However, my wsl installation (arch linux) doesn't seem to have service, instead I have systemctl. I used his idea to run the sshd server: wsl -u root systemctl start sshd should be working flawlessly I bet.

---

EDIT:
one should login directly to the linux sshd server, change wsl settings to make network mirrored, and change some windows settings to allow outer network to access this wsl instance.

[renhiyama]

I am looking at a simple bash function that would run this above mentioned command, and then go into some forever sleep state for that shell that wsl boots up, so wsl isnt killed and restarted continously.

[renhiyama]

@bayeslearner anyways, shouldn't this work? What user are u trying to run that service under?
I am trying to log into the same local account I use

[renhiyama]

Guys, I think I have found the final solution, thanks to @rgl for letting me know the absolute path of proper wsl file, and @bayeslearner about this NSSM cli :)
I guess I shouldn't credit myself, but the last missing piece was as simple as using a sleep infinity only, not even needing systemctl or sleep commands too.
Here's the guide:

• install NSSM, probably by choco install nssm in admin terminal.
• type nssm install wsl, and write this stuff:
  
• goto log on, and select "this account", get your username by typing whoami in another terminal if you dont know ur proper username, and put in your password u use to login too.
• click save button, and then type in nssm start wsl, it should show smt like this:
  

now you can see your task manager, wsl will be running 24/7 regardless whether there's any open terminal or not. It also starts this service on boot 👍

I now just need to find why wsl uses so much cpu and disk even when idle...

[brucmao]

@renhiyama you can use autoMemoryReclaim=gradual in .wslconfig to reduce cpu usage.
https://devblogs.microsoft.com/commandline/windows-subsystem-for-linux-september-2023-update/

[kundeng]

Here is a summary of a method I've been experimenting with to access WSL remotely via SSH, particularly effective post-reboot. Hopefully, this might be helpful for others:

1. Update to the Latest WSL Version (Dev Channel): Ensure you're running the latest WSL version from the dev channel for better compatibility and features. Check this with wsl --version. Example output should include 'WSL version: 2.1.0.0' and relevant kernel and Windows versions.
2. Configure WSL with NSSM: I've configured WSL to start under a specific user account using NSSM (Non-Sucking Service Manager). The command I used is something like -d Ubuntu -u root service dbus start. This helps in keeping WSL operational and accessible after your machine restarts.
3. SSH into Windows and Access WSL: After remotely connecting to the Windows host via SSH, I execute the wsl command to switch to the WSL shell. This method assumes WSL is continuously running in the background.

Just to emphasize that it is IMPORTANT to configure nssm service on the logon tab with the windows user account that has access to the WSL distribution (and not system local).

Another thing to add is that if you ARE going to directly connect to WSL ssh on port 22 (and optionally run windows ssh on another port), I noticed that WSL ssh disconnects very randomly. I suspect this is a bug. So you need to put

ClientAliveInterval 60
ClientAliveCountMax 5

into your wsl distro's /etc/ssh/sshd_config. Changing client side config didn't help.

[aki-k]

@kundeng Did you remove local Administrators group rights from the user that you defined in NSSM to start WSL ?

[kundeng]

@kundeng Did you remove local Administrators group rights from the user that you defined in NSSM to start WSL ?

No, but I noticed that running as system (instead of an actual user who configured that WSL distro) will not prevent WSL from exiting once all the terminal windows are closed. Maybe there is a reason for that.

[aki-k]

@kundeng I had to remove the local Administrators group membership from the user that starts the WSL 2 VM/instance on boot.

[whitetiger264]

I attempted the nssm solution recommended by @renhiyama Unfortunately, it does not seem to work on our Windows Server 2022 Standard via administrator user in logon settings. It simply does not want to start up WSL after I reboot the server.

Is there no way I can keep WSL booting automatically at server reboot, without needing me to log in, as we mainly access the server via RDP. Once I sign out, it closes the WSL app. Right now we are force-killing RDP just so we can "keep it running". But is not reliable.

Any tips will be appreciated.

[kundeng]

I attempted the nssm solution recommended by @renhiyama Unfortunately, it does not seem to work on our Windows Server 2022 Standard via administrator user in logon settings. It simply does not want to start up WSL after I reboot the server.

Is there no way I can keep WSL booting automatically at server reboot, without needing me to log in, as we mainly access the server via RDP. Once I sign out, it closes the WSL app. Right now we are force-killing RDP just so we can "keep it running". But is not reliable.

Any tips will be appreciated.

See the comment earlier by @aki-k , he had to REMOVE administrator group rights from that user who is configured to start WSL in order for this method to work, and if this is true, then your current method would fail. I didn't test it, as I run my system as a user (myself) with admin rights on Windows 11 and it seems work just fine.

You can try both and see which way works for you. I attached some screenshots