In the latest Windows release "Fall Creators Update" it is possible to mount UNC paths, or any other filesystem that Windows can access, from within WSL.
You can do this with the mount
command as usual, with the filesystem "drvfs
" provided by WSL:
sudo mount -t drvfs '\\server\share' /mnt/share
Single quotes are useful around the UNC path so that you don't have to escape the backslashes. You can mount on an arbitrary directory; I've used /mnt/share
as an example here, but any empty directory will do.
All files will show up with full a+rwx
777
permissions. The real access rights will be checked when you try to access a file, and you can get an error at that point even if it looks like the operation should succeed. Every readable file will be treated as executable.
For locations that require credentials you have three options:
- Prior to mounting, navigate to the location using Windows' File Explorer and authenticate. WSL will inherit your credentials and permissions. This is the easiest way for a one-off.
- Use the
net use
command from a cmd prompt, or net.exe use
from inside WSL (cd /mnt/c
first to suppress a warning). You'll need something like net.exe use \\server\share <PASSWORD> /USER:<USERNAME>
. You can use '*'
for the password to be prompted instead. Other configurations are shown with net.exe help use
.
- Use the Windows Credential Manager to set up a stored credential. I've never done this one.
I understand that Samba proper can be made to work under WSL as well, but since the host provides the same functionality I would use the built-in version from Windows when it's available. smbclient
is primarily for FTP-style access to SMB servers and retrieving/putting individual files, and it should work when appropriately configured as usual.
As laktak explained, WSL will not translate the file path from Unix pathing to Windows pathing. I just wrote a Gist on how I handle this, reproduced below:
Make sure you have WSL with the Windows 10 Fall Creators Update installed. Ranger uses rifle
as a file handler and you need its config file, rifle.conf
. If you dont have it (should be in ~/.config/ranger/rifle.conf
), run the command ranger --copy-config=rifle
, then edit the resulting file.
To run Windows applications from Ranger, we will use cmd.exe /C start "" <file>
, which works after the Fall Creators Update. We will solve the pathing issue by using sed
to translate the path.
Add below code to your rifle.conf
and you will be able to run Windows applications for the chosen file extensions.
ext docx?|xlsx?|pptx?|pdf = echo "$@" | sed -e 's;/mnt/\(.\);\1:;' -e 's/.*/"&"/' -e 's:/:\\:g' | xargs cmd.exe /C start ""
start
should be able to run applications associated with file extensions implicitly, but if for some reason it doesnt work, you can also explicitly tell start
which executable to run. Just remove the ""
and add one of
excel
, winword
, powerpnt
, AcroRd32.exe
, etc. Note that in this case you will need one line in rifle.conf
for each application. As an example:
ext docx? = echo "$@" | sed -e 's;/mnt/\(.\);\1:;' -e 's/.*/"&"/' -e 's:/:\\:g' | xargs cmd.exe /C start winword
ext xlsx? = echo "$@" | sed -e 's;/mnt/\(.\);\1:;' -e 's/.*/"&"/' -e 's:/:\\:g' | xargs cmd.exe /C start excel
Additional Reading
Best Answer
Why has this happened?
Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.
When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.
The official WSL advice is
for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your
lxss
directory. You can modify regular Windows files from inside Linux through the/mnt/c/...
DrvFS filesystem, but not the reverse.However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.
What can I do to fix it?
If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.
To do that, you'll need to:
AppData\Local\lxss
directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.ls
to check.Check the file you moved out: run
to see the original contents of the file.
If everything's worked so far, you can now copy that file back into the place you expected it to be:
The
cp
command will cause WSL to restore the necessary hidden attributes on the file.These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.
How can I avoid this in future?
Never manipulate any files within the
lxss
directory from Windows. Instead:If you have a file you want to access from both Windows and Linux, store it outside the
lxss
directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the/mnt/c
directory contains all of the files from your C: drive, and they can be read and written from Linux.Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run
then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like
\\wsl$\Ubuntu\var\www
: the\\wsl$\
part sends file access through an alternative, safe, path.If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.
If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:
This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).
Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal.
nano
,vim
, andemacs
are all readily available and work well under WSL, though they all have their quirks.If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from
/mnt/c
afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.