You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In windows I have SMB shared mapped to drive letters. On the WSL side, I only have physical drive letters (like C) and special driver ones (like google drive), normal SMB shares don't exist.
To Reproduce
Steps to reproduce the behavior: Create a windows share and map it to a drive letter.
Expected behavior
I expect the mapped drive letters to show up under /mnt/ just like the others.
This can be manually fixed with mounting with type drvfs in the filesystems config, but getting the filesystem options (like metadata and uid/gid) correct is error-prone.
The text was updated successfully, but these errors were encountered:
Additionally, when I do add the mount options to the filesystems configuration, it doesn't automount on boot (fails), yet, after boot, a sudo mount -a will mount it correctly.
I'm not aware that this works on any WSL distro, so I'd say this is a bug on Microsofts side and not introduced by us. At least I just tested it on Ubuntu and the network drives aren't present there either
I didn't even know that it's possible network drives through WSL at all, to be honest - so thanks for enlightening me
Bug description
In windows I have SMB shared mapped to drive letters. On the WSL side, I only have physical drive letters (like C) and special driver ones (like google drive), normal SMB shares don't exist.
To Reproduce
Steps to reproduce the behavior: Create a windows share and map it to a drive letter.
Expected behavior
I expect the mapped drive letters to show up under /mnt/ just like the others.
This can be manually fixed with mounting with type drvfs in the filesystems config, but getting the filesystem options (like metadata and uid/gid) correct is error-prone.
The text was updated successfully, but these errors were encountered: