9

I have a Windows 10 with WSL2 inside.

Whenever I create a symlink in the linux side, I expect it to be seen from the windows side (as it happens for example in a server with samba). But I cannot manage to see it from windows.

I would appreciate any help in seeing the linux symlinks in the windows side

Practical example of what I do

In linux bash, it works

If I create a file named a/hello.txt and symlink b pointing to a, I can cat b/hello.txt and see it:

mkdir test
cd test/
mkdir a
echo "Hello, world!" > a/hello.txt
ln -s a b
ls -l
# See b pointing to a in the output
cat b/hello.txt
# See the file's contents in the output

Snippet in linux

In gitbash, broken

When I go to the windows side, the symlink is broken.

In gitbash:

Snippet in windows gitbash

In CMD, broken

In CMD (UNC \\wsl$\Ubuntu-20.04 mounted in W:):

Snippet in windows cmd

In the file explorer, broken

In the Windows Explorer b appears as a file, not a folder:

Windows Explorer UNC

Question

What am I doing wrong? What should I do to see b as a browsable folder in the windows side?

PD: Relates to this (unsolved) question in SO: https://stackoverflow.com/questions/64489501/wsl2-linux-relative-symlinks-broken-when-accessed-from-windows-only-for-the - The question was closed last month and suggested to be moved to SuperUser.

3 Answers3

4

It doesn't appear that it's possible to access WSL (Linux) symlinks from Windows using the \\wsl$ syntax, according to this issue on GitHub. This bridge uses a 9P server and it appears that there's a bug preventing it from working correctly.

In some cases, it may work to store the data on Windows and use a Windows symlink, then access it from Linux. If your goal is to access it from a graphical program, then you may be able to run that program from Linux instead. Otherwise, you'd just need to watch that issue and see when it's fixed.

bk2204
  • 2,716
  • 1
  • 7
  • 7
2

It seems you can mount and use symlinks but not over SMB. And not between filesystems. Yet, anyway
See this post on GitHub

Basicly you can make WSL faster and symlinks better using a direct bind mount (i.e. C:\ <-> /mnt/c) rather than using a fake network like \\wsl$ <-> / (or \\wsl.localhost\ <-> /) Then you can use symbolic links, from either OS, both sides. Though, as far as I can tell, the symlink source and target must be on the same filesystem, which makes sense as Windows does not yet natively mount EXT4.

Using the method in the above link. It is possible to share common locations between Windows and WSL if the files and symlinks are physically located on e.g. /mnt/c/folder/... aka C:\folder\.... I would avoid 'special' windows folders, e.g. OneDrive as that may have odd behaviour.

If you want Windows files physically on WSL (so symlinks between file systems) then it may be possible using a symlink from a SMB mount in windows, with corresponding bind mount in Linux but I've not tried that.

The only issue I have, is that it seems the same mount method does not provide access to C:\... via \\wsl$\mnt\c\... (I get permission denied) even though I can access \wsl$\mnt\home... My guess this is due to permissions applied to the 'fake' SMB share behind this mechanism, as the linux file permissions are the same.

At the moment I don't see this as a real issue but I can't say it's 100% OK for everybody.

Perhaps this could be because, in WSL, looking in the (now mounted) /mnt/c I see a bunch of 'special' NTFS files that are gibberish or 'Permission Denied' and Windows (ironically) is interpreting those isolated errors as an error within the entire folder, and bailing, rather than just ignoring data in a "foreign language", so perhaps it is just "lost in translation". Perhaps the Win11 version of WSL is different?

Jay M
  • 178
1

I worked around this shortcoming by creating a symbolic link within wsl and then in windows explorer creating a shortcut to the same destination with the same name. The shortcut appears in the unix shell as the name with .lnk on the end. The result is the path becomes the same when you reference it whether your in explorer/cmd or bash. You just need to ignore the other file when your viewing in explorer or doing an ls in bash - if I have a shortcut named Documents.lnk and a symbolic link named Documents then cd'ing to Documents works in bash and double clicking Documents in explorer or cd Document in cmd.exe both then work.

gsalerni
  • 11
  • 1