Install/Access Distro for All Users?

[Convincible]

Hi, is it possible to install the Linux distro for all users on the machine? Currently as it is now a Windows Store app I believe this means it is installing specific to the user account, presumably in the User directory?

I jump between a couple of user accounts on my machine but need to access Ubuntu/bash from all of these and essentially it needs to be the same Linux system I am accessing. Is there a way to do this?

Thanks.

[benhillis]

@Convincible - unfortunately there is currently no way to do this. Each distro is per-user.

[Convincible]

'Tis what I feared! Any chance of a way around this now or in future?

[benhillis]

Nothing currently planned but never say never. Probably a good request for our user voice. Closing since question has been answered.

[RichardBronosky]

This a pretty drastic shortcoming!

[littlehill]

Any updates regarding this you know about @benhillis ? We thought about copy-on-login workaround.

[bielawb]

Now that WSL is present on servers too, not being able to install it for all users makes it almost useless IMO. Any chance to have something like shared/default distro in the future?

[giuliov]

I have an interesting scenario: As a dev/devops I would like to use WSL commands from my build scripts on a Server 2019 running my build agent as NetworkService.

It is quite disappointing that a build script mixing Powershell, cmd and bash works on a Win10 client but not on a build server.

[jvollme]

WSL is an incredibly important improvement that has been long overdue. But not being able to install and manage it globally in a multi-user environment is extremely frustating. I desperately need a scenario where i can activate WSL for all users of a single machine, but optimally also be the only admin for that distro (all users just beeing normal users without root-access).

[benhillis]

Please don't do what @Biswa96 is suggesting...

[tareqtms]

I badly need this! :(

[Pbasnal]

@giuliov have you found a way to do this? I have the exact same scenario. One way that i figured out, is to run the agent manually via run.cmd and not as a service.

[giuliov]

@Pbasnal I think there is a way, but not something I would recommend: you need a well know user and launch the step(s) as that user. This will not work on a hosted agent scenario, only if you run agents on your hosts. I do not recommend as you have to manage credentials, issues with process logging and termination and so on. I commented on this issue because the only solid solution can come from Product group.

If you have a mixed shell script scenario, explore using MinGW on Windows or Powershell Core on Linux. It is a sounder path with less headaches. It will have limitation (missing commands and modules) but is currently the best choice.

[kristjanvalur]

Concur. Trying to use WSL as part of a TeamCity build step, which runs as a specific non-login user. Annoying to have to reinstall a separate instance from the store.

[zanfilip]

Badly need this feature. My use case is I need to install WSL ubuntu on a server where several operations users logon to provide app support. A shared installation is what is needed, since i) costly on diskspace and time to have each support user install their own instance ii) custom built support scripts have to be copied/linked locally & sourced each time ... Dissapointing :(

[k1nger]

+1

[IPetrik]

+1 as well

[Ayush6849]

+1 as well

[maxtimbo]

Doesn't seem to be a solution here, so:

+1

[chriszuercher]

+1 as well

[v1sper]

I have solved a similar problem in a VDI environment, although I'm not sure it would be exactly as OP describes it regarding accessing the same virtual Linux kernel.

Anyway, I used the "LxRunOffline" utility (its on github) to install the distros on the Administrator account, and then once a new user logs in and a profile is generated, a script runs that registers the already installed Linux distros into WSL. No Windows Store needed.

Works just fine for my case, but again I'm not sure about OP's exact scenario.

[annant05]

Please add the multi-user feature.

I have the exact use case as @zanfilip

[vincentbonnet]

I have solved a similar problem in a VDI environment, although I'm not sure it would be exactly as OP describes it regarding accessing the same virtual Linux kernel.

Anyway, I used the "LxRunOffline" utility (its on github) to install the distros on the Administrator account, and then once a new user logs in and a profile is generated, a script runs that registers the already installed Linux distros into WSL. No Windows Store needed.

Works just fine for my case, but again I'm not sure about OP's exact scenario.

Hello @v1sper ,

Could it be possible to get the full procedure ? Or should I assume that moving the Distro under Admin is sufficient, and that a general mechanism of profile-scripting take place automatically (in the Microsoft world... I doubt... since IT were not able to thnik about such a basic usecase) ? I will try but awaiting response.

Besides, and whatvere, thanks for this tips !

This is for a student who could require WSL2 for Data Science activities but for which I administrate his HighPerf-Laptop and all infrastructure devices 👍 :-)

Vince

[laggingreflex]

I think I've managed to make same WSL¹ Ubuntu distro be used different users, but I still have an issue that two users can't access WSL simultaneously. When one of them is logged in and another user runs wsl it gives this error:

The requested operation cannot be performed on a file with a user-mapped section open.

Here's what I did:

1. Install LxRunOffline (for both users).
2. Find out the directory in which the current distro is installed. LxRunOffline get-dir I personally moved it elsewhere as well where both users could access it without permission issues, but this is probably optional. LxRunOffline move
3. In the other user's CMD use LxRunOffline register command to register the above directory as a distro for this user.

That should allow both users to use the same distro. But alas both users aren't able to use it simultaneously. When one of them is logged in and another user runs wsl it gives this error:

The requested operation cannot be performed on a file with a user-mapped section open.

Note: I'm (still) using WSL 1. Not sure if this'll work (and my problem will be solved) in WSL2..

Edit: Just tried on WSL2, similar error:

The process cannot access the file because it is being used by another process.

[rbreaves]

Imo since dealing with the permissions issues created by Plan9 or 9P/Lx mess it is easier to use sshfs than \\wsl$ which is only exposed to the one user running WSL.

Install these apps https://github.com/billziss-gh/sshfs-win/releases https://github.com/billziss-gh/winfsp/releases

Then as a normal user you can then run this.

net use X: \\sshfs\user@127.0.0.1!22

And as admin run this if you need a symlink type thing going on.

mklink /d C:\Users\user\Documents\git-projects X:\git-projects

Of course setting up additional users and ssh access in your distro is pretty simple and I am not going to lay that out. This method also has the added benefit of working symlinks appearing in your Windows filesystem.. where as WSL$ would have ignored that outright.

There is also a potential of hanging up your system should the ssh session ever be broken. I have seen sshfs cause Windows to go unresponsive - so I'd only do this in very local situations - not remotely. SSHFS is a bad idea remotely or where latency is an issue.

Not sure if the users in this thread are even wanting this solution tbh - but adding a start up script to Powershell to ssh into your distro is probably pretty easy to do.. this part however is actually kinda difficult.

[qdba]

Running wsl for multiple users is so important.!!

In may case for security reasons I'm working as a unprivileged user. Now I should mount a virtual disk to the linux distro on wsl. The command wsl --mount is only working as privileged user. So when I run powershell (as Administrator) I cannot mount because the ws linux distro is not available for the administrator user.

No way to work as non privileged user.

To add the user to administrator group ist no option.

[DonFlymoor]

For security reasons, I run as a normal user most of the time. It's frustrating to have to manage two different instances linux, one for mounting disks and using usb pass-through, and one for everything else.

[yoshi-kim]

Don't know if anyone's found a solution to this but I use runas to open cmd as the user with the distros installed.

ex: runas /user:domain\user "%SystemRoot%\system32\cmd.exe" enter your pw wsl -l -v (if you have multiple distros) wsl -d distro name

just put the runas command into a batch file

[DanKaplanSES]

runas /user:domain\user "%SystemRoot%\system32\cmd.exe"

Unfortunately, this command doesn't seem to exist in Windows 10 Home

[Holzberg]

Why is this not a top priority?

[rismoney]

Please re-open. This is a much needed and requested capability. What is the bottleneck here?

[rbreaves]

Tbh I think the solution is to setup a specific user just for a WSL instance under a single account and then from there initiate that instance and let it run in the background. You can then ssh into that WSL session flawlessly. Some of the use cases mentioned in this thread really veer off from what the OP wanted, but even in those cases - it would do those users a world of good to actually learn Linux, how to connect it to domain, and setup multiple user accounts in the singular WSL2 instance. Many things can be accomplished with a little bit of effort and proper ssh configuration. You can even setup shares across UNC (SMB) and mklink's.

Otherwise every user can have their separate instances and use up more space than what is really needed as it currently is. I get users might want Microsoft to "do it for them" but A) Windows isn't unix based, get a mac if you want that and B) You can actually do it yourself with some effort - aka scripting and testing.

[rismoney]

The issue becomes one of user context. If you manage endpoints using configmgmt tooling, such as puppet, ansible, etc. it is not possible to provision WSL to users of that box. The SYSTEM account context isn't going to help per user. There is a reason why there are multiple scopes of management, ie HKU vs HKLM. There are many use cases where per user is just the wrong approach. While I agree people articulated their needs differently and some can use hackish workarounds or other approaches to mitigate this shortcoming, the underlying premise of not giving choice on install is just not tenable for many use cases. As such I requested a revisit to this capability.

[rbreaves]

The issue becomes one of user context. If you manage endpoints using configmgmt tooling, such as puppet, ansible, etc. it is not possible to provision WSL to users of that box. The SYSTEM account context isn't going to help per user. There is a reason why there are multiple scopes of management, ie HKU vs HKLM. There are many use cases where per user is just the wrong approach. While I agree people articulated their needs differently and some can use hackish workarounds or other approaches to mitigate this shortcoming, the underlying premise of not giving choice on install is just not tenable for many use cases. As such I requested a revisit to this capability.

Still not clear on what you are wanting, reprovision an existing WSL, or a new one? Again you are talking about MS paradigms that don't really translate at all under Linux. Need to understand both and yea create a "hackish" workaround or maybe even just use hyperv and provisioning/mounting scripts instead and drop the idea of WSL altogether - it really isn't that necessary and you can still build your own method for integrating and mounting files back and forth.

[rismoney]

A new WSL. Want to activate WSL for whoever the user is of a single machine.

As someone else mentioned: I would like to use WSL commands from my build scripts as NetworkService or the localAdmin and have it apply to whoever uses the node (1 person, but unknown) at build time, only at delivery time (which isnt relevant)

[tmax22]

to import image from other user make sure you have access to the vhdx disk image and them import it using wsl --import-in-place command.

wsl --import-in-place Ubuntu C:\<your-path>\ubuntu\ext4.vhdx

[naikrovek]

This is very old, and I'm sorry to notify everyone in this thread, but I would really like to understand the use case behind the original request. What would having a system-wide WSL2 instance offer you?

[rismoney]

Ability to deploy to all users of the system. This is a must for enterprise usage. Installations exclusive to users profile are a broken model for many orgs. Users never deploy their own software.

[maxtimbo]

This is very old, and I'm sorry to notify everyone in this thread, but I would really like to understand the use case behind the original request. What would having a system-wide WSL2 instance offer you?

Ability to deploy to all users of the system. This is a must for enterprise usage. Installations exclusive to users profile are a broken model for many orgs. Users never deploy their own software.

In addition to deploying for all users, all users should have access to the same subsystem, meaning whatever is installed in one instance is available for all users. An admin would log into their windows profile, do whatever they need to do with WSL, and hand the device back to the user. I think I originally gave this a +1 when I was writing some Linux specific python code I wanted to be able to run from a user account via the windows task scheduler. I think I have found better ways of accomplishing this goal, or abandoned it entirely.

I agree, though, that the main reason for installing for all users is as @rismoney said. In an org, users never install their own software.

[naikrovek]

Users never deploy their own software.

I work for the most paranoid and security-conscious company that I have ever heard of that is not a government contractor (and I know for a fact that we are more security conscious than some of those) and we allow users to install their own software in certain situations.

Are you saying "never" as in "they won't" or "they can't"?

[rismoney]

How is allowing an end user to install software in an enterprise "safe" or manageable? Who is responsible for keeping that software updated against vulnerabilities? Who in IT knows jabroni.exe is in his appdata? How is the source of that package validated from the source and sha256 verified? Delegating this responsibility to an end user means these things wont happen. Enabling uncurated store access, and having no insight into what lives in user profiles is untenable.

Software is deployed in nearly all enterprises by way of a service account or a service running as LocalSystem not by the end user.

[naikrovek]

Reality is not what it looks like on paper. "Only approved software" looks fantastic on paper but is not realistic in any way unless you intend to stay on very old versions of things.

If you are a large company and you intend to whitelist everything a developer can use, you will need as many people doing code reviews for 3rd party libraries as you have developers writing code using those libraries.

And if you don't have that many code reviewers working on that, you will only have versions which have known vulnerabilities available for use by your developers, because those were reviewed and approved at some point, and were later found to contain vulnerabilities. But the developers can't update because newer fixed versions have not been whitelisted.

The job of an engineer of any variety is to understand what reality is and then to deal with that reality in their work. The reality with these kinds of things is that 10,000 people could not code review npm package updates as fast as they come out, forget any other package ecosystems or tools.

[rismoney]

This is an orthogonal argument. There are many ways @naikrovek to mitigate risk and allow things such as using artifactory. We are not talking about that. If that was the case, noone would patch OS, because all other lines of defense in depth would take care of it.

The point here is l, there is a real use case for enterprise deployment and use of Program Files/ProgramData vs Appdata, and it shouldn't be dictated. This is not a new concept.

Lets face it, most folks who use UserApps have done it to circumvent them not having admin rights to Program Files. Its a broken design to allow executables in appdata and MS themselves abused the notion when they locked it down. It is preposterous of a design to have google chrome binaries installed in each users profile on a multi user pc. machine wide install is the way here.

[naikrovek]

This is an orthogonal argument.

You're right.

The point here is l, there is a real use case for enterprise deployment and use of Program Files/ProgramData vs Appdata, and it shouldn't be dictated. This is not a new concept.

Lets face it, most folks who use UserApps have done it to circumvent them not having admin rights to Program Files. Its a broken design to allow executables in appdata and MS themselves abused the notion when they locked it down.

Microsoft has long advised against machine-wide installation of software when it is not required, and the vast majority of end-user systems are multi-user systems with a single user. If a user can install and update all of their software without requiring administrative permissions, malware that they install inadvertently is extremely limited in what it can accomplish.

Software that installs to the user profile does so by design, following practices recommended by Microsoft. It is not done to evade anything, it is done so that administrative access to the local computer is not needed for day-to-day work, and is what Microsoft has recommended since Windows XP was released, if not before. It may have been Windows 2000 which introduced this recommendation.

I don't understand what a machine-wide installation of WSL would offer you that a standalone Linux virtual machine would not also offer you. I don't understand the need for a machine-wide WSL instance at all. Is it only that WSL installs into user profiles that you dislike, or is there something that a machine-wide WSL instance would offer the end user that per-user installs do not?

It is preposterous of a design to have google chrome binaries installed in each users profile on a multi user pc. machine wide install is the way here.

Machine-wide Google Chrome installers exist, if you didn't know. Most software used in the enterprise has machine-wide installers. To my knowledge, WSL has never been intended as anything more than a per-user software development tool.