File System Improvements to the Windows Subsystem for Linux


This is part of a series of blog posts on the Windows Subsystem for Linux (WSL). For background information you may want to read the architectural overview, introduction to pico processes, WSL system calls, and WSL file system blog posts.

Posted on behalf of Sven Groot

Summary

In the latest Windows Insider build, the Windows Subsystem for Linux (WSL) now allows you to manually mount Windows drives using the DrvFs file system. Previously, WSL would automatically mount all fixed NTFS drives when you launch Bash, but there was no support for mounting additional storage like removable drives or network locations.

Now, not only can you manually mount any drives on your system, we’ve also added support for other file systems such as FAT, as well as mounting network locations. This enables you to access any drive, including removable USB sticks or CDs, and any network location you can reach in Windows all from within WSL.

Mounting DrvFs

In order to mount a Windows drive using DrvFs, you can use the regular Linux mount command. For example, to mount a removable drive D: as /mnt/d directory, run the following commands:

$ sudo mkdir /mnt/d
$ sudo mount -t drvfs D: /mnt/d

Now, you will be able to access the files of your D: drive under /mnt/d. When you wish to unmount the drive, for example so you can safely remove it, run the following command:

$ sudo umount /mnt/d

Mounting network locations

When you wish to mount a network location, you can of course create a mapped network drive in Windows and mount that as indicated above. However, it’s also possible to mount them directly using a UNC path:

$ sudo mount -t drvfs '\\server\share' /mnt/share

Note the single quotes around the UNC path; these are necessary to prevent the need to escape the backslashes. If you don’t surround the UNC path with single quotes, you need to escape the backslashes by doubling them (e.g. \\\\server\\share).

WSL does not have any way to specify which credentials to use to connect to a network share. If you need to use different credentials to connect to the server, specify them in Windows by navigating to the share in File Explorer, using the Windows Credential Manager, or the net use command. The net use command can be invoked from inside WSL (using net.exe use) via interop. Type net.exe help use for more information on how to use this command.

Volumes mounted on empty NTFS folders

If your system has any volumes that do not have drive letters but are instead mounted on an empty NTFS folder, you are now able to mount those as well. WSL only automounts volumes with drive letters, so up to this change volumes mounted on a directory could not be accessed.

To now mount such a volume in WSL, simply use the path to its mount point:

$ sudo mount -t drvfs 'C:\mountpoint' /mnt/myvolume

Note that the path you specify must be a mount point; you cannot use an arbitrary directory as the root of a drvfs instance. If you wish to accomplish this, you can already do so using bind mounts.

DrvFs behavior for different file systems

The way drvfs behaves may be slightly different depending on the underlying file system. Certain features may not be available with all file systems. For example, the FAT file system is not case sensitive, and does not support hard links or symbolic links.

With network file systems, DrvFs does not set the correct Linux permissions bits on a file; instead, all files are reported with full access (0777) and the only way to determine if you can actually access the file is by attempting to open it. Network file systems are also not case sensitive and do not support symbolic links.

 


Comments (32)

  1. Eric L. Frederich says:

    Bring back the videos 😉 … I really enjoy them.

  2. Riley says:

    I guess my next question is how about mounting samba shares from linux machines? Can you do that directly without going through drvfs? Which would then having the correct permissions etc?

    The community was close to getting it working here:
    https://github.com/Microsoft/BashOnWindows/issues/764

  3. Wacky says:

    This is all fine. But what about the slow file system in general. 2 months ago with the insider’s version I had bench marked simple tasks as:
    – tar/uncompress software packages (e.g. FFmpeg, samba)
    – Running simple programs e.g. launcing Apache server, some binaries that accessed a handfull of files
    – H.264/HEVC encoding/decoding
    Compared to a VM running on the same system (Surface Book), the first 2 tasks were done many times slower by WSL (by a factor of 4-5). Only native encoding and decoding were slightly faster on WSL (10-15% faster). But given the shortfalls, why would one go into all the trouble where many things have rough edges? Shortly speaking, I abandoned using WSL; back to good old VM.

    1. Yale Zhang says:

      Same slow disk for me. I tried WSL for compiling Inkscape and a no change make (which just checks dependencies) takes > 1 minute while inside VirtualBox, it only takes 30s.

      Could it be:
      Overhead of read & write system calls?
      Double caching? VirtualBox by default disables the host disk cache for accessing the disk image
      NTFS not designed to handle all those small files?

    2. John Doe says:

      WSL I/O performance will always be limited by the I/O performance of the underlying Windows kernel and filesystems.

      My perception is that Windows has always been slower than Unix when working with lots of small files. Creating/writing small files is particularly expensive on Windows compared to Unix. You can really see the difference when extracting archives. I believe it has something to do with the different cache strategies (file level vs. block level).

      Process creation is also more expensive on Windows vs. Unix. Programs designed for Unix often create many short-lived processes, and these run relatively poorly on Windows Programs designed for Windows tend to use threads.

  4. rewen says:

    I arrived here from the Feedback Hub where an item is now marked as completed, but it doesn’t look like it was actually completed.

    I am really hoping to be able to mount a remote linux filesystem within WSL.

  5. Carlos says:

    What about the MAX_PATH value?

  6. I had to use:
    $ sudo mkdir /mnt/d

    1. Jack Hammons says:

      Good catch. I have updated the instructions.

  7. wsl user says:

    This is great. Still after fuse support however 🙂

  8. Poliakoff says:

    Ok that’s a great feature but what about the support of USB serial devices, This was the original request. We need USB serial ports to access sensors, robots, eprom programmers,… Are those supported?

    1. Deepu Thomas says:

      Yes USB serial devices are now supported https://aka.ms/b0o8l9

  9. Deepu Thomas says:

    Yes USB serial devices are now supported in insider builds. More details in the blog post https://aka.ms/b0o8l9

    1. Paul Stejskal says:

      Is NFS supported? I don’t see that it seems to be working?

  10. L. says:

    Oh, that’s very good! Except for the final part: “all files are reported with full access (0777) and the only way to determine if you can actually access the file is by attempting to open it. Network file systems are also not case sensitive and do not support symbolic links.” This is going to be slightly painful. Hopefully you will improve this soon. Is it possible to pass umask=??? to mount so that something other than full access is reported?
    What about symlink interop between wsl and win32? Any change?
    @wsl user; yeah, fuse would be nice. Moreover, it would make it possible to work around many limitations of the current implementation (e.g. cygwin-like tricks could be used to emulate symbolic links on network drives).
    @Paul Stejskal: Good question, I hope they answer it (and maybe talk a bit about future plans for NFS). I would guess that currently NFS is handled as any other (meaning, cifs/smb2/smb3) network filesystem, with the limitations described in the post.

  11. Angelo says:

    Is there a trick to read/write pendrive mounted as D:, E:,… without waiting for the next Windows upgrade? I am not an insider and it is very annoying every time to put data on C: and the to or from USB..

    I don’t understand why the WSL developers haven’t implemented this from the first release… It is the first thing to do otherwise WSL is an isolate, closed, uncommunicating system…

  12. Robert Oeffner says:

    This is awesome. Makes WSL on my laptop so much more usable as the second hard drive is mounted to an empty NTFS folder on the primary C: drive. Until now that was inaccessible to WSL.
    Keep up the good work!

  13. Pavel says:

    I don’t seem to be able to access (read) files which do not have execute flag set..
    I have shared disk mounted, i create a file – i can access it. Then with ssh to Linux machine if i do chmod a-x on it, i can’t read it anymore from WSL (from Windows itself file is still good).

  14. alystair says:

    Hmmm maybe you could make a proper NTFS solution for linux to compete with Tuxera on routers using a unix base 😛

  15. @davikes says:

    What about NFS volumes from unix/linux? How do you manage permissions between windows and linux? can you easily control which gid/uid that you are using?

  16. Aritra Jana says:

    When is Ubuntu 17.04 coming for wsl or should I use the in official way

    1. Ben Hillis says:

      You are welcome to try doing a release upgrade to 17.04 but you may run into things that do not work. Our current focus is on making sure 16.04 is rock solid.

  17. Rodrigo Lopez says:

    sorry, I’m not getting this to work at all:

    sudo mount -t drvfs D: /mnt/d
    mount: unknown filesystem type ‘drvfs’

    what am I missing?

    I’m running:
    lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description: Ubuntu 16.04.2 LTS
    Release: 16.04
    Codename: xenial

    1. Ben Hillis says:

      What Windows build are you running? (type ‘ver’ in a Windows command prompt)

  18. Rodrigo Lopez says:

    AH! UFF! I’m not running Windows Insider builds. Ah! Uff! Must wait until this is released aftr Version 1703, OS Build 15063.138, which is what I’m running.

  19. Vladimir says:

    oh, it’s perfect!
    can somebody tell me – is it possible to automount networkdrive using fstab? What options has drvfs?

  20. Bob Rodriguez says:

    Thanks for adding this feature. I’ve had good results with it so far. I second the suggestion for Fuse support, especially for something like sshfs, which seems to be there in the Windows Ubuntu build, but not available due to lack of kernel support.

  21. Melvin Backus says:

    It seems like mounting non-Windows file systems, particularly the more common ones like EXT2, etc., should be high on the list. After all, if I’m wanting you use a *nix BASH command line, I probably have lots of *nix disks to access as well. Any timeline on that ability? Is there another way to mount it under Windows directly so it will show up?

  22. Ben says:

    Is there a technical reason why mount/drvfs doesn’t have the option to do translation from forward slash to backslash when providing a mount path? It is strange to have to different method of delineating directories given in the same command.

    Is DrvFs support for CDFS limited to UDF/Joilet or will it present Rock Ridge extensions such that the file names and permissions appear the way expected in a bash environment?

    Does Drvfs finally add any concept of a loop mount against a flat file as a file system? Does this have the ability to mount/modify a Windows Imaging (WIM) file similar to the WAIK ImageX command?

    Lastly, is the source code available?

  23. Thanapong says:

    Great work!!

    I am wondering how could I apply this build to my machine?

    1. Ben Hillis says:

      You can access pre-release builds of Windows by joining the Windows Insider program.

Skip to main content