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:
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!
Improvements coming soon to the File Explorer experience
When using this feature you’ll notice the distro files are exposed through the path: \\wsl$\
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
- 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
LOVE this new admin file share. Can this be made available for remote systems as well?
For example, \\SERVER\wsl$\
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...
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..
It works for me. This blog post was written before WSL2 was announced.
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?
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
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?
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...
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...
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!
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?
Strange,but for me,nothing changed. Written issue on github for that.
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...
For those whch are facing \\wsl$ is not reachable issue, try this:https://github.com/Microsoft/WSL/issues/3861#issuecomment-471250032
Worked for me
This worked for me as well. Thanks!
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
Does this also mean that you can execute pushd \\wsl$\Ubuntu\home like you can with ordinary network shares?