Automount additonal filesystems from fstab

[deveth0]

With the latest update the new functionality to mount e.g. a sd-card came into the WSL (using drvfs).

While this works fine when performing a manual mount, it would be very helpful to have a possibility to automount devices (e.g. through an entry in fstab).

I added the following line to fstab and can now mount the sd-card using mount -a:

    D:         /mnt/d        drvfs      defaults     0    0 

Is there any undocumented functionality to allow an automount or is there a place, where I can add a script that helps? .bashrc might be an idea, but this would require some messing around with the sudo command as I don't want to be asked for the password on startup (but mount -a requires su).

Thanks in advance!

Microsoft Windows [Version 10.0.16299.19]

[therealkenc]

#511 #994 et al. User Voice is here. You've basically got the present situation. Work around with .bashrc wizardry and sudoers on mount, same as everything startup related while we wait for support. Alternately check if the mount exists in the script and keep a session live, so you're only prompted the once. Which isn't too offensive.

[deveth0]

Great, thanks for the info!

[SvenGroot]

Thanks for the suggestion. This is definitely on our radar, and we're looking into the best ways to address this.

[leongrdic]

Just a little sidenote, I wrote a script that gets around this problem so you might find it useful: https://github.com/leongrdic/easyWSLbash

[n3rd4i]

/etc/sudoers command template:
<yourusername> ALL=NOPASSWD: <command1>, <command2>

adding the mount command"
<yourusername> ALL=NOPASSWD: /bin/mount, /bin/umount

returns the following message"
mount: only root can use "--types" option

so this workaround is not working?

[deveth0]

did you specify the mountpoint in /etc/fstab? If so, it should be sufficient to simple add mount /mnt/d or mount -a into your .bashrc

[VibroAxe]

I got fustrated with not being able to automount removable usb drives so I wrote this:
https://github.com/vibroaxe/wsl_automount
Any suggestions more than welcome

[SvenGroot]

Please stand by, support for this is coming soon!

[VibroAxe]

@SvenGroot brilliant news, keep us posted

[WSLUser]

It's out now for build 17093

[VibroAxe]

Patch notes for build 17093 doesn't appear to include support for removable drives which is what the above script does.

[dgadelha]

I'm not sure how can I automount a partition mounted as empty directory from Windows on WSL.

I added in my fstab:

'C:\SomeFolder\MyFolder'        /mnt/MyFolder    drvfs   defaults        0 0

But when I call mount -a (to simply test the mountFsTab = true in wsl.conf), I get this:

mount: wrong fs type, bad option, bad superblock on 'C:\SomeFolder\MyFolder',
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Mounting it manually also works fine:

# mount -t drvfs -o defaults 'C:\SomeFolder\MyFolder' /mnt/MyFolder
# mount
...
C:\SomeFolder\MyFolder on /mnt/MyFolder type drvfs (rw,relatime)

If needed, I'm on 17093.

[WSLUser]

Just how far does fstab support go? Could I mount my cd drive without a cd in it (empty directory) for example? This would be useful for doing things such as mounting iso files that you could then run to install. (Getting the Windows side mount iso option available in WSL would be acceptable for that particular use case.)

[benhillis]

@DarthSpock - We are running 'mount -a' so anything you can do on native Linux with /etc/fstab you should be able to do (provided we support the filesystem type).

[benhillis]

Marking as fixed in 17093.

[WSLUser]

Looking forward to when there is more filesystem support starting with "F" then.

Edit: There's a uservoice for it that's not related to this issue.

[SvenGroot]

@dgadelha I don't think you can escape backslashes using single quotes in fstab. You need to either double the backslashes, or use forward slashes (which are now also accepted).

[dgadelha]

@SvenGroot Thanks! That fixed the mount -a, but it doesn't get mounted with mountFsTab = true when starting bash :/

[VibroAxe]

The main issue for me on this new support is that only works at wsl startup. @SvenGroot is there anything in the pipeline for proper automount support (similar to my wsl_automount above) so that when a drive is inserted, if a wsl session is running and it's in the fstab it gets mounted/unmounted?

[therealkenc]

so that when a drive is inserted, if a wsl session is running and it's in the fstab it gets mounted/unmounted

That's #560.

[cdenneen]

Microsoft Windows [Version 10.0.16299.309]

chris > sudo mount -t drvfs -o rw,uid=1000,gid=1000,umask=22,fmask=11 H: /mnt/h
mount: wrong fs type, bad option, bad superblock on H:,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.
 chris > sudo mount -t drvfs -o rw,umask=22,fmask=11 H: /mnt/h
mount: wrong fs type, bad option, bad superblock on H:,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

But no options works fine... just mounts as "root"

chris > sudo mount -t drvfs H: /mnt/h
chris > df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          466G   85G  381G  19% /
none            466G   85G  381G  19% /dev
none            466G   85G  381G  19% /run
none            466G   85G  381G  19% /run/lock
none            466G   85G  381G  19% /run/shm
none            466G   85G  381G  19% /run/user
C:              466G   85G  381G  19% /mnt/c
H:              466G   85G  381G  19% /mnt/h
chris >

[WSLUser]

@cdenneen fstab and extended metadata attributes aren't in 16299. You will need to be on Insiders or wait for the next stable release coming soon and upgrade.

[cdenneen]

@DarthSpock yeah sorry I meant to post that I was going to pull down latest insider shortly to confirm... was hoping would have been released by now but stable is still < 17xxx for a while now... maybe fixes... so I'll start using insider. Thanks

[cdenneen]

Confirmed bad option, bad superblock fixed in latest Microsoft Windows [Version 10.0.17127.1]

Looks like symlinks are not supported under drvfs?

 chris > ~ > df -h /home/chris
Filesystem      Size  Used Avail Use% Mounted on
H:              465G   97G  369G  21% /home/chris
 chris > ~ > pwd
/home/chris
 chris > ~ > ls -la .vim/vimrc
-rwxr--r-- 1 chris chris 2983 Mar  2 14:39 .vim/vimrc
 chris > ~ > ln -s .vim/vimrc .vimrc
ln: failed to create symbolic link '.vimrc': Operation not permitted
 chris > ~ >

[cdenneen]

@DarthSpock thanks... I tried the elevation and it didn't fix the symlink.
I have it set to Insider Preview Fast (from Slow) and getting 17133.1 now. Will open new ticket on symlink issue if still happening in 17133.1. Thanks again.

[SvenGroot]

What kind of file system is H:? Symlinks only work on local NTFS drives.

[cdenneen]

H: is mapped drive to \localhost\home which is C:\home

[SvenGroot]

@cdenneen That means you are using SMB for this mount, which has many more restrictions. Among other things, it does not support symbolic links, metadata, or case sensitivity. It's also much slower. Since you're mounting localhost, I would suggest using C:\home directly.

Since DrvFs won't let you directly mount a directory that's not the root of a drive, the way to do is to use a bind mount:
sudo mount --bind /mnt/c/home /home/chris

Or, in fstab (note you have to explicitly mount C: first since we process fstab before automounting DrvFs):

C:           /mnt/c         drvfs   rw,noatime,uid=1000,gid=1000,umask=22,fmask=11     0    0
/mnt/c/home  /home/chris    none    bind                                               0    0

I also recommend using the "metadata" option for this use case, as it allows chmod/chown to work.

[cdenneen]

@SvenGroot I don't have a C: in my fstab but it is mounted... here is what I have:

LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
# This was what I had before
#H:           /home         drvfs   rw,noatime,uid=1000,gid=1000,umask=22,fmask=11     0    0
/mnt/c/home      /home/chris   none bind 0       0

wsl.conf

[automount]
enabled = true
options = "metadata,umask=22,fmask=11"
mountFsTab = true

[network]
generateHosts = true
generateResolvConf = true

symlinks are working now... are there any other mount options I should have in wsl.conf or /etc/fstab

[SvenGroot]

You have to add C: to your fstab. We process fstab before we automount your drives, so with your current setup /mnt/c will not be mounted yet when we attempt to create the bind mount.

[cdenneen]

@SvenGroot thanks... i'll look to add to match above... i'm wondering how it's already there on all my WSL's ... thought it was a "given" rather than needing explicit addition to /etc/fstab

[benhillis]

@cdenneen - When /etc/fstab support was added we run mount -a before adding any DrvFs mounts. This allows you to customize your mount behavior instead of relying on our defaults.

[rainabba]

I've got fstab working as expected, but I need things mounted at /c and not /mnt/c given how WSL converts paths (which affects Docker users). I'm still getting the drives mounted at /mnt. To be clear (though I assume it has to do with WSL.conf), what controls if they're mounted at all and what controls the fact that they're mounted at /mnt?

[benhillis]

@rainabba - wsl.conf

To mount your drives at /, create an /etc/wsl.conf file that contains these lines.

[automount]
root = /

[Biswa96]

@benhillis May be it's time to apply @therealkenc's idea to create wsl.conf automatically with /init.

[rainabba]

@benhillis Thank you.

[benhillis]

@Biswa96 - It's not a bad idea, but as a rule we try to limit the number of filesystem changes we make to the user's root file system to things that are required for functionality (/etc/hosts, /etc/resolv.conf, etc).

[therealkenc]

limit the number of filesystem changes we make to the user's root file system to things that are required for functionality

Maybe generating wsl.conf automatically should be an optional setting.

No... wait.

[nickjj]

Is it possible to automount drives at multiple paths? If so, what are the exact steps to doing this?

Since 18.03 I've been using root = / so that Docker for Windows volumes work, but I really want to use VSCode's built in Git support which only works through WSL if the root mount is /mnt and unfortunately they're not keen on making it work for anything but /mnt.

So, as a work around, is there any way to set both / and /mnt as an automount root? I don't want to resort to binding them in my ~/.bashrc file again (I did that for like a year before 18.03).

The end result I'm looking for would be that /c and /mnt/c would end up resolving to the same path, and both would be accessible inside of WSL as real mounts. I tried symlinking /c to /mnt/c already but that's not enough to make VSCode's Git work.

[WSLUser]

You can add both mounts in fstab. In wsl.conf, set using fstab to yes. This will load it before loading the auto mount option. Straight from CLI, I can do an ls on both /c and /mnt/c and get the same results.

[nickjj]

@DarthSpock What would the wsl.conf and / or /etc/fstab file look like in that case?

[WSLUser]

It's literally a few posts above yours...not to mention wsl.conf

[nickjj]

I looked at those but it's not working.

I edited my /etc/fstab to look like this (based on your recommendation of "literally a few posts above yours"):

C:           /mnt/c         drvfs   rw,noatime,uid=1000,gid=1000,umask=22,fmask=11     0    0   

Then I ran sudo mount -a to reload the fstab file and it throws an error of mount: /mnt/c: mount point does not exist..

[benhillis]

@nickjj - Make sure that /mnt/c exists (mkdir /mnt/c).

[nickjj]

@benhillis Thanks, now it's working (both the mount and VSCode's Git integration).