WSL treating symlinks as win32 junction (redux)

[therealkenc]

• Your Windows build number: (Type ver at a Windows Command Prompt)

19555 WSL 2 Ubuntu-18.04

• What you're doing and what's happening

Repro from #4867 is how I noticed:

$ echo hello > /tmp/foo
$ ln -s /tmp/foo /tmp/bar
$ cd /mnt/c  # quash interop warning
$ cmd.exe /c dir '\\wsl$\Ubuntu-18.04\tmp\bar'

Looks like this was brought up in October 2019, but no one inc myself would notice in a long closed issue.

• What's wrong / what should be happening instead:

Regress #353 (message). They were win32 symlinks (contrast junctions) as of 17046, as long as the user possesses SE_CREATE_SYMBOLIC_LINK_PRIVILEGE, which (quoth) "normally requires you to launch wsl.exe elevated), unless Developer Mode is turned on."

It is possible the definition of "developer mode" changed somewhere along the lines.

• Strace of the failing command

The syscalls succeed, natch.

[therealkenc]

It is possible the definition of "developer mode" changed somewhere along the lines.

Setting aside "Developer Mode", it might be possible we've lost "launch wsl.exe elevated" around the time WSL2 was released to Insiders. If WSL is started (invoked while in the stopped state) from an Admin cmd.exe, symlinks also appear as junctions on the win32 side. [Will spare the screencap, it looks the same.]

If this theory is correct, then some other elevated WSL1 functionality went down with it (CLONE_NEWNET ref #3282 (message) comes to mind). Need more investigation to confirm if this is the case.

[Taytay]

I'm not sure that I'm adding much to this conversation, but I just wanted to note that we are running into this when cloning a git repo inside of Ubuntu. This repo contains some symlinks, and these symlinks are not readable by the Windows side of things. This means that git on the Windows side of things gives all sorts of errors like:

> git diff --summary
some_symlink: Function not implemented
another_symlink: Function not implemented

In addition, there are plenty of Input/Output errors when trying to read said files from the windows side of things:

> type '\\wsl$\Ubuntu-18.04\home\taytay\some_symlink'

type : The name of the file cannot be resolved by the system.
At line:1 char:1
+ type '\\wsl$\Ubuntu-18.04\home\taytay\some_symlink ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ReadError: (\\wsl$\Ubuntu-1...some_symlink:String) [Get-Content], IOException
    + FullyQualifiedErrorId : GetContentReaderIOError,Microsoft.PowerShell.Commands.GetContentCommand

My ideal is to do 99% of my work from the Linux side of things, but use some Windows Git GUI tools to manage these Git repos, and this sort of mismatch is throwing a wrench in those plans.
I'm including some of the above in hopes that googling for WSL, "Function not implemented", git, and WSL might turn up this issue, which took me a while to find. :)

[tychedelia]

Ran into something similar while debugging intellij-rust/intellij-rust#1171. In this case, Java totally fails to read the symlink on the WSL fs. I originally thought this might just be an upstream bug in openjdk, but it appears that there is weird behavior on the Windows side:

I've barely used Windows, so apologies if I misunderstand how symlinks work on the platform, but it looks to me like the file attributes correctly recognize that this is a symlink, but all the metadata is null. I imagine Java is using this and thus thinks the file doesn't exist / is unable to follow the link.

[PrasadTamgale]

Try these workarounds until this issue is patched.

1. Cygwin 3.1.5 or Above is capable of resolving these reparse points showing as "[JUNCTION]" & helps resolve symlinks.
2. Migrate from 9P server to Samba server is WSL2 & access the share from \\localhost\<share> which also resolves the symlinks.

[donalhunt]

my issue regarding file permissions under linux changing seems to be due to DrvFS having metadata turned off by default. 🙄

[xmontero]

Is this question https://superuser.com/q/1695779/324451 the same than this bug?

[blami]

This does not work also for symlinks created on drvfs. I use WSL2 with home directory redirected to /mnt/C/Users/my_windows_user (it's slow but I need that).

When I create symlink inside WSL with ln -s /home/a b where a is directory, on Windows side (e.g. in cmd.exe) it shows as 04/07/2022 09:49 PM <JUNCTION> b [...] and it is not accessible from explorer.exe (gives an error C:\Users\my_windows_user\b is not accesible). When link is relative Windows explorer.exe shows icon as directory with link overlay while if link is absolute (still pointing from drvfs to drvfs) it shows as unknown file even if it's a directory.

[audrenbdb]

+1

[the-moog]

I've had this problem since I started with WSL and thought it was just always broken.
But, after reading
#353
#2144

I realised that it worked for some and not for others and it's been like that for a while.
And noting some config differences, I managed to fix it (on my systems, anyway). Let me know what does/does not work for you and what incorrect assumptions and/or conclusions I am making.

So:
Turns out the trick is to mount C: with metadata and via drvfs+bind rather than the default, whatever that is? SMB??

Before doing ln -s in WSL created a symlink that had the l flag in Windows but says something like "Can not locate file"
And doing New-Item -type symlink in Windows made a regular file in WSL that was 0 bytes, so not a symlink or dir.

After this small change, New-Item and ln -s both work across platforms!! Very happy :)

NOTE 1: I did this with latest WSL2, a stock Ubuntu 22.04 distribution in Win10 Enterprise

NOTE 2: I don't think this works when the link source and target are on different filesystems. So (sadly) you can't link from e.g. /home/me to /mnt/c/users/me or the other way round, as those are different file systems. But (now, for me) link soure+targets that are created under /mnt/c/... from either OS will be correct for both Windows and Linux.

NOTE 3: It seems that I can't browse \\wsl$\c\... or \\wsl.local\c\... as I get permission error. I don't know the implications of that....

---

Here is what I did to get symlinks working.
btw: Is it me, or after changing the mounts do I notice that WSL is significantly faster listing folders etc.?

Edit /etc/wsl.conf
(for me no changes, but posted as perhaps your's is not the same)

[network]

[automount]
enabled = true
options = "metadata"
mountFsTab = true
crossDistro = true

[interop]
enabled = true
appendWindowsPath = true

[boot]
systemd=true

Edit /etc/fstab
The 2nd two lines were added, the first line is just the root file system for WSL

LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
C:      /mnt/c_drive    drvfs   rw,noatime,metadata,uid=1000,gid=1000,umask=022,fmask=011
/mnt/c_drive    /mnt/c  none    bind

Create a folder /mnt/c_drive to receive the mount

mkdir  /mnt/c_drive

Check my C:\Users\%USER%\.wslconfig

[wsl2]
memory=8GB
processors=4
guiApplications=true # Use WSLg on Win10 - yay!!

Reboot wsl using wsl --shutdown

Now /mnt/c points to C:\ (as does /mnt/c_drive).

I don't think you can use bind mounts with C: , hence the two mount steps.

[xparq]

Tried to reproduce Jay's (@the-moog) encouraging result, but no luck. Or, "not enough" luck: links created on Windows (10) work fine on the WSL side (Debian 12) [actually, I can't remember now whether they always worked...], but whatever I do in Linux (incl. copying existing ones created by Windows etc.), those links are just still incompatible with Windows. :-/

FTR:

$ mount -v | grep mnt/c
drvfs on /mnt/c-interop type 9p (rw,noatime,dirsync,aname=drvfs;path=C:;metadata;uid=1000;gid=1000;u
mask=022;fmask=011;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)
drvfs on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:;metadata;uid=1000;gid=1000;umask=022
;fmask=011;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)

• I haven't added the systemd entry to my wsl.conf, but that should make no difference.
• BTW, I also noticed some speed increase, but only a marginal one: 16s for a find . >/dev/null as opposed to 18s (over 3 consecutive runs), FWIW. But I don't know what that "listing folders" really meant, so this may be irrelevant to Jay's remark.

Also, a possibly related SE/su comment:

Creation of reparse point-based symlinks was implemented in ntfs-3g two weeks ago. Though it uses the WSL-specific reparse tag, not the native Windows 7–10 symlinks (possibly because those don't exactly match Linux semantics). –
u1686_grawity, Feb 8, 2021 at 20:13

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!