How to get wsl files from windows

wsl$ mount point did not work for me so well, it has multiple issues, and many Windows applications fail because they see it as a network drive. For my usecase, it is Rclone what helped to solve the problem to properly mount Linux filesystem so it behaves without any issues, practically the same way as a local disk.

It is free and open source. It works with sftp remote filesystems (like sshfs), so it can mount network drives both on Linux and Windows (running sshd service).

Example command how to run it, assuming remote point «server» is already configured and rclone.exe is in PATH environment variable:

rclone mount server:/ Z: --file-perms=0777 --track-renames --track-renames-strategy=modtime,leaf --metadata --vfs-cache-mode=full --sftp-disable-hashcheck --volname drive_name

For the first time, you need to configure new remote point by running:

rclone config

To find out location of the config file you have just created, run:

rclone config file

Also, you may need to install WinFsp first, if not already intalled. The best thing about it, everything just works the same way like with local disk (assuming if you provide --vfs-cache-mode=writes or --vfs-cache-mode=full option, since without it, many applications will fail to work correctly, please read the documentation to understand why). Option --file-perms=0777 is necessary to allow running .exe files. Even though --vfs-cache-mode=writes may be enough for most applications, but —vfs-cache-mode=full is important for good performance with large files. For the same reason --track-renames-strategy is limited to only modtime and leaf strategies, because if haenter code heresh strategy is used, it will be obviously slow with large files, and --sftp-disable-hashcheck is necessary to prevent rclone from running md5sum, otherwise it will run it even when trying to read a file.

To register Rclone as a system service, edit and run the following command (do not run as is, please see below how you need to edit it first):

New-Service -Name Rclone -BinaryPathName 'C:Program FilesRclonerclone.exe mount server:/ Z: --vfs-cache-mode=full --track-renames --track-renames-strategy=modtime,leaf --metadata --volname drive_name --config="C:Program FilesRclonerclone.conf" --log-file="C:Program FilesRclonerclone.txt" --file-perms=0777 --sftp-disable-hashcheck --no-console'

Obviously, you need to replace «server:/» with your actual remote point name and path, also replace drive_name with any name you like, and of cource you may need to edit paths to rclone.conf, rclone.log and rclone.exe, if you installed it in a different location.

Note: in my case running as a system service caused some permission issues (for example, when trying to save Excel files), and I did not figured out why yet, so I ended up creating startup .bat file to run Rclone as a user, since it works perfectly this way. I will update this answer if and when I figure out how to make running as a service to work as good as running as a user.

Even Windows software which does not like network drives, just works with RClone drives. All is needed, is to setup sshd in the remote system (which in this case is not really a remote syset, but in WSL distribution installed on the same PC). This how to setup sshd in WSL distribution: https://www.hanselman.com/blog/how-to-ssh-into-wsl2-on-windows-10-from-an-external-machine. And here is how to make WSL IP address static: https://github.com/ocroz/wsl2-boot, so you can have sshd running always at the same IP address.

I’ve been getting a few questions from Windows users about accessing WSL files in Windows and vice versa. I was originally going to wait with this for the next labs, but since this might actually make things a little clearer for some, I’ll just post the information here instead. If anything’s unclear, just wait for the second lab and I’ll probably be able to explain things better in person.

The WSL distributables (i.e. Ubuntu) are kind of like another machine running within your computer. It just features a Unix command-line interface (that’s the terminal, i.e. the bash shell), so the development tools and experiences are pretty limited. You can run vim, nano, or even emacs (might need to be installed) in the terminal to edit your files, but if you want to use a full-fledged IDE you’ll normally have to edit the files on the Windows side and then transfer them over to the Linux environment in WSL.

When we start working with Python, R and jflap, you can probably just solve the exercises on Windows, since you don’t need Linux to write Python or R code. Of course, you can always install python3 in Ubuntu, but you won’t have access to an IDE (unless you follow the guide in the last part of this post).

Accessing your WSL files in Windows

If you are using WSL 1, this should probably work fine most of the time. However, if you are using WSL2, it probably won’t. WSL2 doesn’t like it when we edit files in both Linux WSL and in Windows. WSL1 doesn’t like it either, but it’s possible to do, and I’ve tried so myself many times now without issues.

To access your Linux files in Windows, open the Ubuntu terminal and type explorer.exe . (include the punctuation mark). This will open the linux directory in Windows Explorer, with the WSL prefix “wsl$Ubuntu-18.04homeyour-username”.

Now, you’ll notice that Windows treats your Linux environment as a second network. This is because, as I’ve stated earlier, the Linux environment is completely separate from the Windows environment and transferring files between these environments is very similar to transferring files between computer networks. I always recommend that you copy the file you want over to a Windows folder before editing it, so that you won’t mess up the original if the file gets corrupted.

PS: To copy the file, run cp [filename] [destination], like this: console cp file.txt /backup/new_file.txt

Accessing your Windows files in the WSL terminal

Similarly, you can also open your Windows files in the Linux environment. Just use the cd command to navigate to your WSL root folder, then navigate into the mnt folder to access your C: drive. See the example below for more details. As you can see, I managed to access my Documents folder. Make sure to enter your own username when you try this yourself.

I recommend you to use the cp command to copy the files you need from Windows to your Linux environment, so that if anything should get corrupted you’re not going to mess up the original file.

Working in WSL with VScode

VScode is a full-fledged IDE from Microsoft, which has very recently released support for editing Linux files remotely. This means that you can open VScode from the Ubuntu terminal, run it in Windows, but edit the files in Linux while also being able to access the Linux terminal and viewing pathnames and home directory correctly. I’ve tried it out today, and… it just works!

So if you insist on using an IDE to edit your Linux files directly, even though you won’t really need to in this course, you can do it by installing the Remote — WSL extension for VScode. See the documentation and guides here.

VScode editor with WSL-remote enabled

If I read your post literally, there may be a few different questions there:

• Where is your WSL Ubuntu instance installed on your machine?
• (Presumably based on the first question) How do I access files in WSL2 from Windows?
• «How do I access files in my Windows machine from WSL2?» (sort of the opposite question of the first two)

Where is your WSL Ubuntu instance?

Short answer: In your case, given the basic installation, the actual files are in a virtual disk named ext4.vhdx. You really don’t need to worry about the «where» at this point (since it’s a virtual drive), but you’ll typically find it under %userprofile%AppDataLocalPackagesCanonical...LocalStateext4.vhdx. Your %userprofile% is typically something like C:Users<username>.

More Detail:

That’s for a default installation. You can have multiple distributions installed, and even multiple instances of the same distribution. One of the great things about WSL is the ability to quickly copy a distribution, test something out, and throw away the test. This keeps you from polluting your «good», daily distribution with packages, tests, or other things that may create «cruft» over the long-term.

To see all the distributions you have installed, go to PowerShell and run:

Get-ChildItem "HKCU:SoftwareMicrosoftWindowsCurrentVersionLxss" -Recurse

In your case, you’ll probably see something like:

{cff9bfd6-39db-42af-a85b-d6fca State              : 1
94beff8}                       DistributionName   : Ubuntu
                               Version            : 2
                               BasePath           : C:UserskrutikAppDataLocalPackagesCanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgscLocalState
                               Flags              : 15
                               DefaultUid         : 1000
                               PackageFamilyName  : CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc
                               KernelCommandLine  : BOOT_IMAGE=/kernel init=/init
                               DefaultEnvironment : {HOSTTYPE=x86_64, LANG=en_US.UTF-8, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games, TERM=xterm-256color}

I have quite a few more, in various locations.

How do I access files in WSL2 from Windows?

But the title of your question, «where», doesn’t really matter much unless you need to do something with the ext4.vhdx file (like perhaps reclaim space).

To access files in WSL from Windows, use the \wsl$Ubuntu path (or whatever your distribution is named). Here, you’ll find \wsl$Ubuntuhomenkp68, where you can safely copy in and out files.

Updated note: Under Windows 11, \wsl$<distro_name> still works, but there is also a new \wsl.localhost<disro_name> path as well. Both work the same, but wsl.localhost should be a bit more robust in certain situations.

How do I access files in my Windows machine from WSL2?

If you are in Ubuntu and need access to a file on a Windows drive (e.g. C:), then you’ll find those are (by default) auto-mounted for you:

ls /mnt/c/Users
ls /mnt/c

There are some nuances in working with files on a Windows drive from within WSL, especially around permissions and performance. You’ll typically want to keep any project files inside the Ubuntu ext4 filesystem (e.g. under your /home/nkp68 directory). But you can certainly access, copy, and move files around between the drives as needed.

Where is the WSL feature located?

The title of the question could be interpreted to mean that you want to know where the actual WSL feature is installed. I know that wasn’t the case for you, the original poster, but the question has come up from others, so I’ll add it here in case they find this based on the title.

The WSL feature itself has been installed with Windows itself since at least Windows 10 21H2 (and perhaps before). That doesn’t, however, mean that it is enabled.

When you enable it, the applicable binaries are found under C:WindowsSystem32lxss. You’ll rarely need to worry about this folder, but there are some times when it comes in handy.

The WSL2 kernel is also located in this folder, and you can back up older kernels if you want to rollback more than one release.