What’s new in WSL in Windows 10 Fall Creators Update


Similarly to the Windows 10 Creators Update, the Windows 10 Fall Creators Update (FCU)  delivers a large number of improvements and features in the Windows Subsystem for Linux (WSL) .

Note: For fans of our sister project, Windows Console, please also read our post on "What's New in Windows Console in FCU".

We've been documenting many of these new features and improvements on this blog over the last few months, but we've often been asked for a single document listing all the new improvements, and with FCU (version 1709, build 16299.15) shipping on October 17th 2017, we thought it was time to publish a list these improvements!

We're excited about all the WSL team has accomplished leading up to the Fall Creators Update. Here's the list of updates we'll discuss in this post:

  • WSL is no longer a Beta feature
  • Install Linux distros via the Windows Store
  • WSL now runs multiple Linux distros
  • WSL no longer requires developer mode
  • WSL comes to Windows Server & Microsoft Azure VM's!
  • WSL now supports USB/serial comms
  • Miscellaneous fixes and improvements
  • Deprecating the name "Bash on Windows"
  • So, what's next?

First, some background on "Building Windows"

Before we get started on WSL and Console features, we've seen lots of confusion in the community about what Insiders builds are, and how we release Windows, so we want to briefly outline the process through which we build and release Windows.

As many of you know, Microsoft has gone from delivering a new Windows release once every 3-4 years down to once every ~6 months! Actually, this isn't quite true: In fact, we deliver Windows every week via our Windows Insider Program! The Insider program delivers regular beta-quality builds of the next version of Windows as it's being built. Thus, the Insiders builds released over the last several months were snapshots of the Fall Creators Update that ships on October 17th 2017.

Note: "Fast Ring" Insider builds ship approximately once per week, and "Slow Ring" Insider builds release once every 4-6 weeks. Because this more rapid release cycle, some undiscovered or low-impact issues occasionally get released in Fast Ring builds, but are usually patched within a week. Slow Ring builds incorporate fixes to issues that may have slipped out into Fast Ring builds, and tend to be more stable. This is why we do NOT recommend installing Fast-Ring builds as your primary OS on your main/only machine.

But why is this important to WSL & Console users? Well, our first piece of news, is that…

WSL is no longer a Beta feature!

We first shipped an early beta version of WSL in Windows 10 Anniversary Update (), followed by major improvements in Creators Update (March 2017), though WSL remained a beta feature.

In Fall Creators Update (shipping 17th October 2017) WSL will become a fully supported OS feature.

This means that if you run into unexpected issues or problems with WSL, you can contact Microsoft Support to file a support ticket that will be managed through the normal channels.

Alternatively, the engineering team & community continue to provide support via the WSL Github Issues Repo and Feedback Hub.  We greatly appreciate all the support that the community provide via these channels.

Install Linux distros via the Windows Store

In Windows 10 Anniversary and Creators Update, an Ubuntu image was downloaded and installed when "Bash on Ubuntu on Windows" (bash.exe) was first run.

In Fall Creators Update, we now enable you to install one or more Linux distros from the Windows Store. Currently, you can install Ubuntu, openSUSE and SUSE Linux Enterprise Server (SLES). Fedora and other distros will arrive in the store in the coming months.

First, enable the Windows Subsystem for Linux feature in the "Turn Windows Features on or off" dialog and reboot … and yes, the reboot is required - WSL will not work until you've rebooted!

After rebooting (you did reboot after enabling WSL, right?), search for "Linux" in the Store, and click the button in the Linux banner:

Then, click your favorite distro(s)…

…and hit the Install button on the product page:

A minute or two later, your distro(s) will be installed and you'll be able to run your favorite Linux distros and tools on WSL.

Note: When you first run your distro, we expand the distro onto your PC. This can take a couple of minutes so please be patient the first time you run a newly installed distro.

So, now you have one or more distros installed, you can run them ...

WSL now runs multiple Linux distros

Perhaps the biggest improvement to WSL in Fall Creators Update is its ability to not only install one or more Linux distros from the Windows Store but to be able to run them side-by-side, simultaneously!

Now you can install and run Ubuntu, openSUSE, and SUSE Linux Enterprise Server alongside one another, and alongside all your favorite Windows tools, and shells including Cmd and PowerShell.

Each distro runs independently of one another, but can access Windows' host filesystem, networking stack, etc. It's also important to remember that WSL does not use VM technology, and only consumes the memory required to  load and execute the Linux binaries that you choose to run!

This ability to run different Linux distros allows you to use the same tools, package manager/ecosystem, and environment that your production code will be running in. This results in less time wasted tracking down hard to find errors when it comes time to deploy your code.

This allows you to, for example, use Edge/Chrome/Firefox on Windows, to view a website hosted on Apache on Ubuntu, that talks to a REST service running on openSUSE … without having to punch holes through the firewall when testing locally, because all these processes run above the firewall, alongside one another!

Note: If you've previously installed WSL on Anniversary or Creators Update, your existing "legacy" Ubuntu instance will continue to work just fine, but it is considered deprecated. We recommend that you migrate your files off the legacy instance and replace it with a store-delivered instance, so that you receive the support of Canonical and Microsoft moving forward.

WSL no longer requires developer mode!

If you read through the installation guide above, the observant among you will already be throwing your hands in the air saying "but you forgot to point out step 2 - enable developer mode"

Well, in FCU, Developer Mode is no longer required to run WSL! This eliminates an extra step from the installation process outlined above, and prevents the need to permit side-loaded apps to run on your machine.

WSL Comes to Windows Server & Microsoft Azure VM's!

As we originally outlined in our similarly titled blog post on this subject, WSL is coming to Windows Server and to Microsoft Azure Windows VM instances.

Using WSL, Windows Server administrators, devops engineers, developers, etc., will be able to run their favorite Linux tools, apps, and scripts, alongside their favorite Windows admin tools. This will make it easier than ever before to automate, control, manage, and deploy an ever broader portfolio of technologies & tools atop Windows Server.

Note that, just as on Windows 10, WSL is for running your favorite Linux distros & tools for local interactive use, not for hosting production Linux workloads. If you want to deploy your production Linux workloads on Windows Server, we strongly recommend hosting Linux VMs in Hyper-V and/or containers in Docker for Windows.

WSL now supports USB Serial comms

We heard from many of you, especially those who work with IoT/embedded/etc. devices that communicate via USB/serial, that WSL was unable to talk to serial comms ports.

So, in FCU, we added serial device support, as outlined in the original announcement post.

WSL supports mounting of USB storage devices and network shares

Another common ask from many WSL users was for WSL to support mounting of USB-attached storage devices, and network shares. In build 16176, USB and UNC paths (network shares) was added, and several improvements were added in the subsequent few builds.

It's important to note that because WSL utilizes the NT filesystem IO infrastructure, it currently only supports mounting FAT/FAT32/NTFS formatted storage devices. If you would like us to consider *NIX filesystem support, please upvote and/or comment on the associated UserVoice ask.

Miscellaneous fixes and improvements

Along with the big-ticket improvements above, there were also many smaller fixes, improvements, many of which can be found in the WSL release notes for the builds from 16170 - 16288.

Some of these improvements include:

  • Improved TCP socket options inc. IP_OPTIONS, IP_ADD_MEMBERSHIP, IP_MULTICAST, etc.
  • /etc/hosts will now inherit entries from the Windows hosts file
  • xattr related syscalls support
  • Fixed several filesystem features and capabilities
  • Improved PTRACE support
  • Improved FUTEX support
  • “chsh“ now works
    • This enables you to use your favorite shell directly. (This feature was not available in legacy instance.)
    • Shell startup file other than “.bashrc” will now execute.

Also, the following notable syscalls were added for the first time during the FCU cycle:

  • Prlimit64
  • getxattr, setxattr, listxattr, removexattr

Deprecating the name "Bash on Windows"

Originally, the name "Windows Subsystem for Linux" generally referred to the Windows kernel infrastructure that runs Linux binaries. We wanted to convey what this meant from and end-user-experience, so, we referred to the end-user feature as "Bash on Ubuntu on Windows", or more simply "Bash on Windows".
While this naming-scheme has helped us convey at least the essence of what WSL delivers as a feature, "Bash on Windows" doesn't really describe what WSL is and does, and doesn't make sense now that more distros are coming aboard.

So, moving forward, we'll no longer be using the feature name "Bash on [Ubuntu on] Windows"!

Instead, we'll use "Windows Subsystem for Linux" (WSL) to refer to the Microsoft-side of the technology stack, including the kernel and Windows tools that enable Linux binaries to run on Windows. The distros will simply be known by their own names - Ubuntu, openSUSE, SUSE Linux Enterprise Server, etc.

So, in future, conversations will go something like: "Linux runs really well on Windows/WSL", or "I run Ubuntu on WSL", or "have you tried openSUSE on WSL". We think you'll agree this is simpler, cleaner, and requires FAR less talking and typing.

So, what next?

Many of you have taken advantage of the Windows Insider rapid-release mechanism to upgrade to newer Windows builds in order to run the latest features and improvements as early as possible. This was particularly valuable to WSL users because we were making rapid and dramatic improvements to WSL during the Creators Update and Fall Creators Update product cycles.

The WSL engineering team continue doing the same: We have a long list of improvements and new features lined up for future releases and have already begun work on several of them!

If you're keen to continue to run the latest and greatest WSL bits, and keep the feedback coming to our WSL and Console issue repo's: We depend on feedback from you, our amazing community, and use your asks and issues to help prioritize the features and fixes that we work on, so keep the feedback coming!

Sincerely,  the WSL and Windows Console engineering teams.


Comments (99)

  1. John Doe says:

    Notable improve not written in release notes.
    ・“chsh“ now work. We can use favorite shell directly. (This feature not available in legacy instance.)
    ・Shell startup file other than “.bashrc” will now execute.

  2. Eric Pellegrini says:

    Where is Fedora :'(

    1. Tara Raj says:

      It’s in the works – coming soon! Feel free to reach out to Matthew from Fedora (https://twitter.com/mattdm) in the meantime.

  3. Valery says:

    What about CUDA support?

    1. We’re looking closely at this work, but it is a gnarly problem to solve. We’ll post an update after our investigation completes.

      1. Meteorhead says:

        When you write the blog post, could you mention non-proprietary tech? I am specifically interested in the Khronos standards: OpenGL, OpenCL, SYCL and their interoperability.

        1. We are looking into how we might be able to support CUDA/OpenCL in future versions of Windows, but have no plans at this time to support graphical/UI technologies.

          1. JMas says:

            +1 for CUDA support. If ‘generic’ cuda support isn’t workable, perhaps contributions to the major open source projects to “work around” the issue could help.
            Most of MY reasons for wanting GPU support is for deep learning using TensorFlow, Theano and PyTorch (primarily). The reason for using the Linux versions of these is MOSTLY for compatibility with the rest of our workflow that scales out training or deploys models to production.

          2. We hear and fully understand your ask, but please upvote it & share your thoughts here: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/16108045-opencl-cuda-gpu-support

            Note that this isn’t a simple thing to implement and most CUDA-supporting OSS projects won’t (and nor should they) appreciate us trying to jam in some workarounds.

            It’ll be better for everyone if we “do the right thing” – please bear with us as we work through this.

  4. Yoshie says:

    Where Arch 🙁

    1. We have begun talking with the Arch team, but nothing concrete planned just yet. We’ll announce any additional distros here on this blog.

  5. How do you get rid of your old installlation of ‘Bash on Windows’ so we can start fresh?

    1. Tara Raj says:

      Thanks, Steven. The team has been working very hard!

  6. Sergei says:

    Do you now support raw sockets? It would be very useful for example, for nmap 🙂

    1. Only in limited cases right now. Please read this thread and upvote on the uservoice ask https://github.com/Microsoft/BashOnWindows/issues/1349

  7. Joe Perrin says:

    Does this update support the use of the Windows Firewall with WSL? Seems odd that there is an API which provides support for WSL and 3rd party firewalls but the 1st Party native built-in Windows Firewall doesn’t work with WSL yet. Would you please shed some light on this? Thanks.

    1. Because WSL relies on the NT Kernel’s networking, IO, etc. infrastructure, your Linux binaries run above the firewall so you don’t need to punch holes when testing apps & sites locally. If you want to remotely access a Linux service/endpoint, you’ll need to open a port through the firewall.

      We are looking at how we might safely, and securely make this process easier in the future, and will announce any changes on this subject here.

      1. Joe Perrin says:

        The problem I’m talking about is when the Windows Firewall is configured as a two way firewall. Meaning it blocks outbound connections as well as inbound. When outbound is enabled on Windows Firewall WSL cannot access the internet and creating outbound rules in Windows Firewall to allow WSL pico processes does not work. It is my understanding that some sort of API was created to allow 3rd party Firewalls to support these WSL pico processes. Some of these firewalls are taking advantage of the API and outbound rules for WSL pico processes are working in those firewalls as a result. It seems that for whatever reason the Windows Firewall isn’t yet updated in a similar way. When can we expect this to be resolved? Thanks!

  8. Yudhir says:

    Naming was an issue. How to find answers to wsl specific problems if i search for “bash on Ubuntu “

    1. That should become easier as we migrate to talking more about WSL.

  9. Stijn Herreman says:

    I’m not getting the banner in the store. Running build 16299.15

    1. Are you running Windows 10 x64?

      1. Stijn Herreman says:

        Yes.

        1. What does Cmd say when you run “ver”?

          1. Scott says:

            I don’t get the banner either, ver returns Microsoft Windows [Version 10.0.16299.19]

  10. Matt says:

    “We recommend that you migrate your files off the legacy instance and replace it with a store-delivered instance, so that you receive the support of Canonical and Microsoft moving forward.”

    How would one go about doing this?

    1. I’d recommend copying any files you want to keep to somewhere on your Windows filesystem, e.g.: `/mnt/c/temp/backups` and then copying them back into your new instance.

      1. L. says:

        Better tar them, so that permissions are not lost.

  11. James says:

    Loving WSL, I use it every day at work and even for some projects at home. Thanks for all the hard work. I am curious, will we see docker Linux containers working in WSL in the near future? Another feature I would love to see is FUSE file system support so I can natively use sshfs with Windows and WSL.

    1. Thanks James 🙂 Great to hear 🙂

      You can already drive Docker for Windows running alongside WSL on the same machine using `docker -h localhost: run foo` (or you can set the host env-var if you prefer not to type it repeatedly)!

      For FUSE, please upvote here: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

  12. Couple of interesting marketing thoughts. I’m struggling with a new laptop and new 960 Pro PCIe Gen 3×4 NVMe SSD where Windows is supported but Ubuntu is problematic. WSL allows you to get going right away with Ubuntu on WSL. Traditionally you would have to quad boot Windows, Ubuntu, Suse, Suse Enterprise but now you can run all 4 SIMULTANEOUSLY without rebooting. You could have had one main OS and 3 VM’s I guess but at huge up-front fixed RAM costs.

    Looking forward to learning Powershell’s way of putting notifications in system tray when converting existing bash scripts from Linux only to dual OS support. Some concerns about VcXsrv and getting bash dialog boxes (in Zenity and YAD) up and running but what is life without some challenges?

    Can’t wait to get new Win 10 laptop on kitchen table configured and hopefully it’s purring by Oct 17/17. BTW listing RAM requirements would be helpful.

    1. Thanks for sharing: Sometimes, you may need to run full-Linux, in which case, Hyper-V is ready and waiting for you. But as you point out, WSL helps you avoid the RAM & startup-time cost of running one or more VM’s.

      Re. RAM requirements: We don’t list any because, frankly, we don’t have any of note! If you don’t install WSL, we add no RAM footprint. If you do enable WSL, there’s a tiny 850KB driver loaded briefly, and then it shuts down until you start a Linux instance. At that point, you load /init which launches /bin/bash. This causes the 850KB driver to load, and creates PicoProcesses for init and bash. So, basically, WSL’s RAM requirements are pretty much whatever the RAM is that you need to run each Linux binary, plus around 1MB of working set in total – a miniscule amount!

  13. Pavel Rauš says:

    Can I expect some universal function to bridge any USB device to WSL ? Using smartcard reader by Gemalto or Security keys by Yubico in WSL will be great.

    1. We have yet to implement the mechanisms required to support USB security device classes – it is on our backlog and we do want to get around to it.

  14. Jim Doop says:

    Woo! It’s been great to see WSL become more and more useful over the past year. Now I could never live without it.

    1. Thanks for sharing. Glad we’re making your life easier 🙂

  15. Vosuram says:

    Can distros be installed/moved to a non-system drive?

    1. Not yet, but we are looking closely at enabling this.

  16. > we’ll no longer be using the feature name “Bash on [Ubuntu on] Windows”!
    > Instead, we’ll use “Windows Subsystem for Linux” (WSL)

    This is great news! It was getting hard to google bash/ubuntu/windows and actually find this feature. WSL should help.

    Now when is the GitHub repo going to be renamed? https://github.com/Microsoft/BashOnWindows

    1. We’ll be renaming the repo soon.

  17. Jani says:

    I’ve understood that the original Creators Update included the necessaries for Windows Firewall to support WSL/pico processes, yet Windows Firewall does not support them. Are there any changes coming to this issue or do you have any other related news?

    1. Could you elaborate on what you mean specifically?

      1. Jani says:

        Sure! My Windows Firewall is set to block everything outgoing unless whitelisted. Currently this means all Pico processes are blocked unless I explicitly allow them by their IP destination, but this also whitelists any other applications trying to access those IPs. What I would like to do is either target (allow) all Pico processes, or it would be even better if it’s possible control Pico processes by path as I can do with Windows’ .exe files.

        Quick google reveals these, so I think there is not going to be any improvements as these issues are still open:
        https://github.com/Microsoft/BashOnWindows/issues/722
        https://github.com/Microsoft/BashOnWindows/issues/1852

        Also this seems to be the comment about the API availability:
        https://github.com/Microsoft/BashOnWindows/issues/1852#issuecomment-291685457

        Thanks!

        1. Thanks. What firewall are you using? Built-in?

          We’ve not made any changes to auto-opening holes in the firewall for WSL apps. However, we were discussing this very subject just the other day so your feedback is valuable, along with others’ in the links you’ve listed.

          1. Jani says:

            Yes, the built-in “Windows Firewall with Advanced Security”.

            I’m glad to hear you’re aware of the issue!

  18. Jesus says:

    I know I can access all windows filesystem from linux, but what about access to all linux filesystem from windows explorer? Will you support it?.

    1. We are looking at how we can expose the Linux distros’ filesystems to Windows & Windows apps.

    2. Technically, you could always access the WSL filesystem from Windows if you knew where it was, but this isn’t recommended because you can easily break those files’ extended attributes that store Linux’s file permissions. I think it’s safe to just read the files, but beyond that you should use Bash commands to do anything else.

      All that said, the WSL file system is located in this hidden directory:
      %LocalAppData%\lxss

      And here’s a long post about the filesystem:
      https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

      1. I’ve also read that you can mount the WSL filesystem in Windows as a network drive if you enable WSL’s ssh daemon (sudo service ssh start) and use something like SFTP NetDrive or mess around with sshFS ports in Windows to connect to it.

        1. If you manually start sshd, you **IN THEORY** could access it via an ssh client or mount it using an ssh filesystem driver from one of several vendors. However, note that as soon as you close a given distro’s last remining console, we tear down all running processes for that distro, including background tasks.

          We’re working on improving this and other related scenarios moving forward, but for now, I don’t recommend this mechanism as a means of reliably accessing the Linux filesystem.

      2. Note that as of Fall Creators Update, when you install distros from the store, they’re no longer stored in %LOCALAPPDATA%\lxss.

        Plz. don’t go looking for them – they’re hidden for a very good reason, and doing so may end up with data loss and/or corruption.

        We are working to bridge this gap. Bear with us!

        1. Jane Doe says:

          > Plz. don’t go looking for them

          Stop taunting us ! By the way, where are those files hidden, just out of curiosity ? 🙂

          1. Not tellin’. Saving you from yourself!

  19. Giovanni Bassi says:

    Has the file system performance increased? It is slower to access a file in WSL than it is to do it in a VM running in the same machine.

    1. We’ve been able to make a few smaller perf improvements, but substantial improvements require some serious engineering which we are exploring for future OS releases.

      1. chris says:

        Is there a timeline on file I/O improvements? Sorry not trying to troll, but I think that’s seriously the only weakness of WSL right now.

        1. We’re working on it. Actively. It’s one of our highest priority things to improve, but it’s also one of the hardest things to improve, so please bear with us.

          1. Karoly Negyesi says:

            I am both a teddy bear collector and a Linux user for a quarter century now. All of us are bearing 😉 with you! Keep up the good work. Can’t wait for better git speed.

          2. I see what you did there 😉

  20. Roman says:

    I hope we will soon see some kind of simple permission interop for NTFS partitions. Copying all SSH keys is cumbersome, especially for Vagrant VMs. And all git repos currently have to ignore file permissions.

    1. ACL’s and DAC are philosophically incompatible. DAC lacks the ability to mirror the rich security mechanisms expressible via ACL’s.

      This said, we do honor Linux filesystem behaviors, semantics, permissions etc. within the Linux side of the filesystem. When you access your Windows filesystem from within Linux, we do try to synthesize DAC permissions that express the “effective permissions” that the user would have when accessing the requested files & folders.

      1. L. says:

        NFSv4 uses ACLs for Unix filesystems. I believe this is supported by FreeBSD and Solaris, and there is a patch for Linux (search for “richacls”). NFSv4 ACLs are very close to Windows ACLs (they were designed with interoperability in mind).
        IMHO, it would be a very good choice to implement ACL support in WSL by following NFSv4’s design.

  21. Mark Adamson says:

    When I ran lxrun /uninstall, it said it would preserve the home and root folder but they are now gone. It doesn’t actually bother me, but might affect others

    1. Mark Adamson says:

      My mistake, they’re still there. I hadn’t realised the lxss folder was hidden so didn’t see it in AppData\Local and assumed it had gone

    2. Ahmad Muhammad says:

      You have to run lxrun /uninstall /full in order to remove everything.

  22. Supriya Pan says:

    How can I Run gnuplot using WSL “Ubunto”

    1. How would you normally run gnuplot on an Ubuntu Server VM?

      1. Erkin Alp Güney says:

        gnuplot takes its parameters on the command line and exports an image. It is not a GUI application per se.

  23. Gatak says:

    Are you going to change the name of the git repository?

    1. Tara Raj says:

      Yes, we will be renaming the repo soon

  24. Any chance of getting CentOS 7?

    1. We’re working with several other distro vendors about getting their distro’s into the Windows Store in the future. Stay tuned for more news 🙂

      1. Erkin Alp Güney says:

        You will see RHEL(not unbranded CentOS) shortly.

  25. Nir says:

    Amazing!
    Does WSL fits the use-case of developing a JAVA app for ubuntu?
    Where would you run the IDE? Windows or WSL?

    1. Absolutely! If your Java source lives somewhere on your C: or D: drive, for example, you can edit that code using Windows editors/IDEs like Sublime/VSCode/Eclipse/gvim/etc., and then build & run it in WSL via the command line, or by configuring your editor/IDE’s build task to call, for example, bash.exe -c "build && run"

  26. Micah Culpepper says:

    How will you be able to interact with the WSL from a PowerShell script now?

    Currently, I can use lxrun to set the default user on the subsystem, and “bash -c ‘some command'” to execute commands in the subsystem from a PowerShell script. But now there is a potential to have multiple installed subsystems, so how can I get info about installed subsystems and execute scripts on each one? Will lxrun have some new options to return data about my installed subsystems? Will there be separate “bash” commands for each subsystem?

    1. In future, you’ll control default distro using `wslconfig`, and you can run bash.exe to run default distro, or wsl.exe to run given command directly on default distro (sans shell).

      Alternatively, you’ll be able to run distros specifically, by calling them directly. For example:

      C:\> ubuntu.exe -c "lsb_release -a"
      No LSB modules are available.
      Distributor ID: Ubuntu
      Description: Ubuntu 16.04.3 LTS
      Release: 16.04
      Codename: xenial

      1. Micah Culpepper says:

        Oh neat, thanks! Is there documentation on wsl and wslconfig? Or is that coming out with the update?

        1. Tara Raj says:

          We just added documentation for wslconfig.exe to manage multiple distros here – https://msdn.microsoft.com/en-us/commandline/wsl/wsl-config

  27. WindowsPowerUser says:

    Can we move the lxss folder to another drive now?
    I am running on a SSD and as I use WSL to add packages for development, I am running out of disk space 🙁
    https://github.com/Microsoft/BashOnWindows/issues/449

    1. Not yet. We need to do some work to make moving of distros reliable, safe, and secure. We’re working on this as I type.

      Plus, note that as of Fall Creators Update, WSL no longer expands a distro out into the lxss folder: On FCU, when you install a distro from the Windows store, it gets expanded out (elsewhere) into a per-user-per-distro folder.

  28. Juan Carlos Castro says:

    Hi, trying it right now, great work!
    in old linux subsystem I can access linux files in:
    C:\Users\\AppData\Local\lxss
    Is there a way to access the new ubuntu file system?
    Thanks

    1. While you **CAN** currently spelunk into the lxss folder, we **STRONGLY** encourage you not to: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

      In Fall Creators Update, the new store distros are expanded out into a different per-user-per-distro folder. Assume that you can’t currently see if from Windows (see blog above), but be patient with us: We’re working on improving this interop scenario!

      1. L. says:

        I wonder… maybe it’s already possible to work around this limitation, in a very hack-ish way. Would this work?
        1. Add a new, private IP to any network interface (maybe add a “loopback” interface?)
        2. Make sure the Windows Server service is not bound to this interface
        3. Run samba in WSL, bound to this IP
        4. Connect a network drive to he corresponding UNC path from Windows
        5. Profit
        Well, I don’t plan to try it out but maybe someone will.

  29. Erkin Alp Güney says:

    Can you add rolling release (Tumbleweed) of suse? It is made by Linux kernel maintainer Greg Kroah-Hartman.

    1. Important to note: Microsoft doesn’t ship Linux distros – please contact openSUSE and Greg and ask them 🙂

  30. frustrated says:

    Hi, is there an alternative way of getting WSL with Windows Store?
    I have been stuck at the “Unknown layout specified in manifest” errors for days whenever I try to launch Windows Store.

    1. If you’re seeing that error whenever you launch the Windows store, it sounds like something in your upgrade/install may have gone wrong – best fix that before going too much further. Please ping your error to https://twitter.com/Jenmsft

  31. Rory McCune says:

    This is all great stuff, loving the additions to WSL.

    One thing that would be super-useful for a lot of use cases is raw network support to allow nmap/wireshark et al to work.

    I know there’s been votes for this, so just wondering has it got a timeline on the roadmap as yet?

    1. We understand the ask, but we want to tread carefully here: Windows has a lot of network protections in place to prevent network borne [D]DOS and hacks from attacking a machine.

  32. rms-meme says:

    “Linux runs really well on Windows/WSL”
    If you are saying Windows/WSL then you should also call say GNU/Linux or RMS might interject you for a moment. 😉

    On a serious note, this just made me thinking, I guess Linux minus GNU possible now, I guess it will be once the /bash will be static which is currently in the insider builds if I remember correctly, so e.g. a pure busybox/toolbox/toybox system linked to something other than glibc (e.g. uclibc or musl) compiled using LLVM ought to run, maybe even console Android if such a thing exists…

    1. As long as your user mode binaries are ELF64, and only call the kernel via the POSIX/Linux SCI, then your libraryOS type system should work. Give it a try and let me know on Twitter 🙂 https://twitter.com/richturn_ms

  33. Devop supporter says:

    Can a way be provided to update the linux binaries for WSL without having to go to an Insider Preview build so that we can run WSL with more stability as updates are provided?

    1. You can (and should) keep your distro instances up to date following the distros’ normal update mechanism. For example, for Ubuntu, you’d run:

      $ sudo apt update && apt upgrade # To update your installed packages
      # sudo apt dist-upgrade # To update/upgrade your distro

      To update WSL itself, however, you’ll need to either subscribe to insider fast/slow, or wait for each official Win10 release (approx once every ~6 months). This is because WSL itself is deeply integrated into, and dependent upon, many Windows kernel features inc. networking, filesystem, etc.

Skip to main content