What’s new for WSL in Windows 10 version 1903?

Craig Loewen

The next Windows update is coming soon and we’re bringing exciting new updates to WSL with it! These include accessing the Linux file system from Windows, and improvements to how you manage and configure your distros in the command line.

Accessing Linux files from Windows

In the past, creating and changing Linux files from Windows resulted in losing files or corrupting data. Making this possible has been a highly requested and long anticipated feature. We’re proud to announce you can now easily access all the files in your Linux distros from Windows.

Linux Files inside of File Explorer

The best way to get started with this feature is to open your Linux files in File Explorer! To do this, open your favorite distro, make sure your current folder is your Linux home directory, and type in:

explorer.exe .

This will open a File Explorer window, showing the files located inside of your Linux distro’s filesystem:

Accessing Linux distro filesystem from Windows

From here you can access whatever Linux files you would like, just like you would any other file through File explorer. This includes operations such as: dragging files back and forth to other locations, copy and paste, and even interesting scenarios like using the context menu to open VSCode in a WSL directory!

Accessing Linux distro files via VSCode

Improvements coming soon to the File Explorer experience

When using this feature you’ll notice the distro files are exposed through the path: \\wsl$\. This is due to the way Windows accesses the files inside of each distro (which you can learn the details of in the following section!) The WSL team is actively investigating ways to improve the discoverability of your Linux files inside of File Explorer.

In command line

WSL is primarily a command line tool, and so of course this feature also works in the command line. You can find your distro’s files by accessing \\wsl$\{distro name}\ where {distro name} is the name of a running distro. Here’s what it looks like to access Debian with PowerShell.

How it works

To put it briefly: a 9P protocol file server facilitates file related requests, with Windows acting as the client.

We’ve modified the WSL init daemon to initiate a 9P server. This server contains protocols that support Linux metadata, including permissions. A Windows service and driver that act as the client and talks to the 9P server (which is running inside of a WSL instance). Client and server communicate over AF_UNIX sockets, since WSL allows interop between a Windows application and a Linux application using AF_UNIX as described in this post.

Known issues

This is a new feature, and some pieces of it may not work perfectly. Here are some known issues that we want to make you aware of when using this feature:

  • Currently, the distros files will only be accessible from Windows when the distro is running. Since the 9P file server runs inside of each distro, it is only accessible when that distro is running. The team is looking into ways to help resolve this.
  • Accessing Linux files is treated the same as accessing a network resource, and any rules for accessing network resources will still apply e.g: When using CMD, cd \\wsl$\Ubuntu\home will not work (as CMD does not support UNC paths as current directories), however copy \\wsl$\Ubuntu\home\somefile.txt C:\dev\ will work
  • Do NOT access your Linux files via the AppData folder! If you try to access your Linux files through your AppData folder, you are bypassing using the 9P server, which means that you will likely corrupt your Linux files!

Where to file feedback

Our team is keen to hear your feedback. In fact WSL itself was created based on our great community feedback! Please file any issues you that you may find on our Github page: https://github.com/Microsoft/WSL and we will do our best to address them.

We can’t thank the community enough for helping make WSL an amazing tool!

Improved wsl.exe command line experience

We’ve also improved the command line experience in this latest update by consolidating our commands to wsl.exe and adding more command line functionality. You can now use wsl.exe to perform all the necessary commands you would need to configure and control WSL on your machine. You can always check all the commands you can run from wsl.exe by running wsl.exe –help

New commands

We’ve also added some new commands that will give you more functionality when using wsl.exe.

You can now run commands as different users, terminate running distributions, and even export and import different distros! Exporting a distro is accomplished by passing in –export as an argument and will output a tar file of your current distro. For example, you could use this functionality to share your distro setup with other people. Additionally, if you pass in –import as an argument you can import a tar file that contains the root file system of a Linux distro, which allows you to import any distro you’d like, with any configuration you’d like.

Here is the full list of commands that we’ve added to wsl.exe.

  • –user, -u Run as the specified user
  • –export Exports the distribution to a tar file. The filename can be – for standard output.
  • –import Imports the specified tar file as a new distribution. The filename can be – for standard input.
  • –terminate, -t Terminates the distribution.

Consolidated commands

The commands that existed inside of wslconfig.exe have been added to wsl.exe to allow you to configure your distros more easily. Our goal is to consolidate how you interact with WSL to a single binary.

Commands Added to wsl.exe from wslconfig.exe

  • –list , -l Lists all distributions available on your machine Can also contain further options: –all Lists all distributions, including distributions that are currently being installed or uninstalled –running Lists only distributions that are currently running
  • –setdefault, -s Sets the distribution as default.
  • –unregister Unregisters the distribution
  • –upgrade Upgrades the distribution to the WslFs file system format.

Console improvements

The Windows Console team has also made some improvements that you’ll notice when using WSL. The Console team will soon post an update of what’s new in Windows 10 version 1903. Stay tuned!

Thanks and feedback

As always, we want to thank you for providing your feedback and encourage you to keep doing so! You can file issues on our Github at Microsoft/WSL or reach out to Craig Loewen @craigaloewen on Twitter.

We’re looking forward to seeing the fantastic work that you’ll do with this update.

Sincerely,

The WSL Team

Q&A

  1. Why is the WSL resource name in the filepath called wsl$? Since wsl is a short acronym we realize that some resources on networks may already have that name. So we’ve added a dollar sign, since a machine name can’t have a dollar sign in it, which ensures that the name will be accessible with any existing network configuration.

Update Log:

[2019-02-15] Updated the ‘How it works’ section to detail that a P9 server is used, and not Plan 9

28 comments

Discussion is closed. Login to edit/delete existing comments.

  • Christopher Crawford 0

    I encountered the weirdest bug in WSL right after the automatic update to Windows 1903:  

    The CLI program for Google Drive (a Windows binary) stopped working in bash (WSL).  It still works when called with a relative path, but fails to work when invoked with an absolute path!  Example:

    cartan:~ 22:21$ src/bash/gdrive-windows-x64.exeNo valid arguments given, use ‘gdrive help’ to see available commandscartan:~ 22:21$ ~/src/bash/gdrive-windows-x64.exe cartan:~ 22:22$

    The first time, the program ran and gave an error because no files were specified.  The second time, it appeared to run, but didn’t because it gave no errors.

    A second bug:  I run emacs with X11 inside WSL, and used to be able to run windows commands in the shell (M-x shell)

    $ cmd.exe

    Now when I run windows programs, it just hangs.  However linux executables work fine.

    Both executables run just fine outside of emacs.  Again, it stopped working today after the 1903 update.

    Any thoughts on what might be happening?

    –Chris

    • Christopher Crawford 0

      Update:  it appears the problem is running binaries (but not scripts) from a path with a soft-link.  (I linked /home/user -> windows directory)

      I’m not sure whether it applies to all binaries or just Windows ones.  Anyone else see the same thing?

      • Trunov Sergey 0

        Have the same problem after update to 1903. In my case i have wsl emacs environment too and every atempt to run MSBuild.exe(but it seams every other exe file too) inside emacs fails miserably (its just hangs).Tried update filesystem of my wsl Debian distribution to new WSLFS – no succes. Tried to install new Ubuntu wsl distribution and results the same. Even encapsulating exe programm with bash script have no effect. But at the same time in simple terminal executing MSBuild.exe works just fine. I didnt linked my /home/user/ dir to some other dir but have link in user root ~ (at least .emacs.d -> emacs_configs/.emacs.d) and before update the was no issue with that.

      • Sergey Trunov 0

        Strange,but for me,nothing changed. Written issue on github for that.

    • Christopher Crawford 0

      OK, the issue seems fixed in with update KB4512508, or something else that happened last night while I was asleep and my computer rebooted on its own.  Thanks!

  • Martin Propato 0

    Hi, with the new upgrade to version 1903 I have lost the connectivity between the windows machine and a Linux machine in the same home network. In the linux machine I have connected a shared printer for all computers in the network, but now I can´t use the printer from my windows computer any more. The printer is not detected and there is no troubleshooting information on it. I have lost that functionality and I do not know how to have it again. I will appreciate some guidance on how to print in a linux shared printer,

  • Izik Warn 0

    What are the limits on filepath length for the P9 access? Does it vary by linux distribution we use?

    Will the AppData folder being stored on NTFS lead to corruption if filepaths are too long for NTFS?

  • Ershov Mikhail 0

    Please help to understand
    do I need to install app (Ubuntu for example) from Microsoft Store
    before/after using wsl –import from tar archive?

    Posted my question also here

  • Альебрт Бикеев 0

    Thanks a lot MS team! That sounds really cool!
    But what about performance? For example, if I compile my JVM application from the outside, how it would affect the performance?

  • Kharma Scribbles 0

    Does the P9 server work as well with WSL1?

    The reason I have decided not to upgrade to WSL2 is because I use the Bluestacks emulator for Android apps on a consistent basis and it is unable to run with any Hyper V features installed.

    WSL1 is good enough for my needs anyways, but I would be very much interested in accessing my Linux files safely via Windows..

    • Kartik Singhal 0

      It works for me. This blog post was written before WSL2 was announced.

  • Iman Sjamhudi 0

    Hello all. Late to join the conversation, but please bear with me. 🙂

    Just trying WSL2 with CentOS and Ubuntu (my staging/production server uses CentOS so..), and I have to say, Ubuntu works a lot better in WSL environment.

    There’s one issue that I need to confirm, and I have tried looking for answers but to no avail. You see my setup is following.. I work with Atom to code and I have Docker Desktop on my Windows host integrated with the guest. If I change files from Windows side, seems the change is immediately reflected on Linux side. But if I have a file modification in Linux side, I would have to refresh my Atom to see the change.

    Am I missing something..? Pls enlighten me, masters! Thanks a lot beforehand.

  • Chiramisu 0

    LOVE this new admin file share. Can this be made available for remote systems as well?
    For example, \\SERVER\wsl$\

Feedback usabilla icon