People are stil asking how to do this in forums today; presumably mostly dual boot uses that want to look at their Linux partiton.
This post is primarily for EXT4 filesystems as those are the ones used when installed supplied (–online) images into WSL2.
So there are two use cases. (1) Those that have a dual boot environment on a single machine, (2) those that wany Windows to remote mount filesystems from remote Linux machine.
Local mounting, everything on the one machine
For users with dual boot systems on the same physical hard drive
Trying to mount a ext4 partition from Windows on a dual boot machine when the linux partition is on the same HDD/SSD as the Windows partition seems to have limited optiions.
- Commercial: Paragon software offers ExtFS for Windows. It allows you to read and write ext2 ext3 and ext4 from all Windows OS versions ( ref: http://www.paragon-software.com/home/extfs-windows/ )
- Free and Commercial: Linux Reader from Diskinternals, that can mount all ext, HFS and ReiserFS too, but read-only in the free version at least ( ref: http://www.diskinternals.com/linux-reader/ ). You can copy files off, writing back may need the PRO cmmercial version
- Free (GPL) solutions for “read only” on github, https://github.com/bobranten/Ext4Fsd which is a fork of the earlier https://github.com/matt-wu/Ext3Fsd/releases/tag/Ext3Fsd-0.69
Obviously none of the above or similar options will work if you have wisely LUKs encrypted that Linux partition.
For users with dual boot systems with Linux on a second hard drive
Can be done from WSL which can mount physical disks (entire disks, not partitions).
You can use WSL to mount entire disks formatted with ext4, but not individual partitions, so currently that is not an option for when you have a a linux partition on the same HDD/SSD as your windows OS, but if you Linux environment is on a seperate disk you can mount it into a WSL instance.
There is microsoft documentation on how to do this at https://learn.microsoft.com/en-us/windows/wsl/wsl2-mount-disk.
Also a Youtube tutorial on doing it at https://www.youtube.com/watch?v=aX1vH1j7m7U.
However this has both pros and cons
- pro: WSL virtual disks (and anything mounted onto them) are visible via a Windows File Explorer “Linux” tab if they exist making them easy to navigate, they are read-write so you can open and edit shell scripts with notepad for example
- pro: the WSL Linux system is a full linux system so you can install the crypt utilities and use this method to mount LUKs encrypted partitions if they are on a sperate physical disk
- con: if you are going to install a Linux system under WSL anyway do you really need a dual boot environment (the answer of course is yes if you intend to use it rather than play with it, ie: if you are going to store data on it it should be LUKs encrypted which I do not thing WSL supports for its virtual disks
But… if you just want to play with Linux just install into WSL which takes only a few commands and is much easier than having to partition disks and manually install an OS and edit the bootloader etc. so the issue will not exist. An example is shown below where a installed Ubuntu image is viewed using Windows File Explorer from the “Linux” tab.
Note: I assume Windows has some sort of API into WSL virtual disks to manage the ext4 file systems (a “mount” command within a WSL instance shows they are ext4 so may be all they support) and will not magically recognize a external disk with a ext4 file system that is just plugged into a USB port. I have not tried that as all my external disks are LUKs encrypted which it does not handle. I might try with a dying USB stick one day by making that ext4 to see if it does handle it.
Remote mounting, the filesystem is on a remote machine
Again multiple ways of doing this. It depends on your environment. Both options I would consider involve a lot of work.
If you want to avoid using WSL alltogether really your only option is SMB/NMB (SAMBA). Anyone who has been playing with Linux servers for a while (long before Windows10/WSL) and still has some Windows clients will have gone down this path. However while that may make it easy from a Windows user point of view as they will (should after a lot of effort) show up as available networked devices setting up Samba on your Linux servers is not trivial; you do not want to do that on a lot of machines. It also tends to break with every upgrade and need rework.
If you have an old USB attached printer on one of those remote servers then Samba and CUPS may be the only option for using the printer; with newer ip printers not so much
That solution suits an environment with very few Linux servers and a lot of Windows clients, where whoever is on the clients has no interest in knowing that the filesystems are served from a unix server. However you need to setup users on the Linux server(s) for each Windows client user, decide on a domain server, and generally do a lot of work on the Linux server side.
For someone that just wants to mount an ext4 filesystem for single use that is overkill.
The second option, if you are a lone developer with a single windows client, is to use WSL on the Windows10 machine and just NFS mount the remote filesystem you want to work with onto a directory in your WSL imstance so it shows up under the Windows File Explorer “Linux” tab as just another directory to walk into.
That also requires some work on the remote servers to setup the NFS exports; plus a few commands within the WSL instance to mount them. and never mount a directory that has symbolic links and expect it to work… for example you may think creating an exports entry of /mnt/shareme on the remote machine and placing in it symbolic links such as /mnt/shareme/marks_homedir pointing to /home/mark on the remote machine… the actual behaviour when that is mounted is that references to /mnt/shareme/marks_homedir will indeed reference files under /home/mark on the local machine not the remote one. Yes a nasty trap; do not use links.
It should be noted that the issue of symbolic links causing problems is not limited to NFS mounts; while that exact trap should not confuse Samba (which should map exact directories and not links as well anyway; but in a reference mapping case Samba would cope). I doubt there is a unix admin alive anywhere that has not done a “du -ks dirname” to check space in a directory and found it used say 100Mb then done a recursive copy “cp -rp dirname newplace” and found the target disk 100% full after a few 100Gbs of data were copied… because somewhere in the directory structure was a link pointing up a directory level which was faithfully followed up a level, reached again and followed up a level, repeat until out of disk space. (now even if mapped by Samba trying to copy the directory and everything under it would have the same loop condition).
Basically try and avoid mounting any remote directory that has symbolic links under it.
I will not discuss Samba, setting that up is a never ending task. To implement NFS mounts to a WSL instance however is simple.
- start a powershell session
- “wsl –list” to see what you have installed
- if nothing then “wsl –list –online” to see what is available and “wsl –install -d nameofoneofthem” to install one
- Always “wsl –update” to get the latest kernel
- simply use “wsl” to drop into it
- then “sudo apt install nfs-common”, and you have everything you need to mount remote exported filesystems which when mounted to WSL are read/write available to Windows vie the “Linux” tab in Windows File Explorer
On the remote server to make for example /home/mark available, /etc/exports would contain
/home/mark *(rw,sync,no_subtree_check,no_root_squash,insecure)
The * before the ( should be replaced by the ipaddr of the machine running WSL (not the ip assigned to the WSL instance as it is NAT’ed via the host machine so it is the host machine ipaddr that is presented to NFS on the remote machine); but * works if you don’t care who connects.
If you change or add mountpoints to /etc/exports on the remote machine you must “systemctl restart nfs-mountd.service” on the remote machine to pick up the changes.
Under WSL simply “mount -t nfs xxx.xxx.xxx.xxx:/home/mark /some/local/dir/mountpoint”. From Windows File Explorer under the “Linux” tab, under the WSL insance, it is available under /some/local/dir/mountpoint as fully read-write.
