Symbolic Links: Operation not permitted

[shayne]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.18917.1000]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

I use scoop and as such there are paths in my Path environment variable that include Windows symbolic-links.

WSL2 cannot follow these symbolic links.

Using the fish shell, for example spews errors when trying to search for commands under these paths.

Additionally... if you were to try and follow a Windows symbolic link you get operation not permitted.

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

Ideally, Windows would allow non-elevated processes / shares to access symbolic links / paths. I do have Developer Mode enabled, as I understand that can allow symlink access without UAC elevation.

shayne@desktop:/mnt/c/Users/Shayne/scoop/apps/gcc$ ls
ls: cannot read symbolic link 'current': Operation not permitted
8.1.0  current
shayne@desktop:/mnt/c/Users/Shayne/scoop/apps/gcc$ ls current
ls: cannot access 'current': Operation not permitted

Fish example (note current/ is a symlink):

shayne@desktop:/mnt/c/Users/Shayne/scoop/apps/gcc$ fish
Welcome to fish, the friendly interactive shell
<W> fish: Error while searching for command
'/mnt/c/Users/Shayne/scoop/apps/nodejs/current/bin/__fish_command_not_found_handler' 
access: Operation not permitted
<W> fish: Error while searching for command
'/mnt/c/Users/Shayne/scoop/apps/nodejs/current/__fish_command_not_found_handler'
access: Operation not permitted
...

[trondhindenes]

Can repro, noticed when I ran ls while in my Documents folder. The Windows symlinks for "Music", "Videos" etc give access denied errors in WSL2.

[SvenGroot]

Unfortunately, WSL 2 does not currently support NT symlinks that have an absolute target. This is something we're working to address.

In the mean time, either recreate the symlink with a relative target if possible, or recreate it from inside WSL (which will create a WSL symlink which won't work in Windows, unfortunately).

@trondhindenes That is actually not the same problem; those are back-compat symlinks with weird permissions on the Windows side, and WSL can't read them at all. That issue also exists in WSL 1 and probably won't be solved.

[akulbe]

@mscraigloewen When I attempt the workaround you suggested in #4125 I get an error in both PS and PSCore. Doesn't know about mklink. Does this require some other module?

I found this but I'm sure if there's supposed to be a built-in module I use first, or not.

[craigloewen-msft]

@akulbe I'll follow up in #4125 so we can keep our conversation there

[therealkenc]

Can repro, noticed when I ran ls while in my Documents folder. The Windows symlinks for "Music", "Videos" etc give access denied errors in WSL2.

That is actually not the same problem; those are back-compat symlinks with weird permissions on the Windows side, and WSL can't read them at all. That issue also exists in WSL 1 and probably won't be solved.

Never?

[bbulkow]

Something similar started happening to me, but it is only when ls --colors=auto , which is the default in Ubuntu. And, it's only hidden symlinks in Windows, ones that aren't in the directory ( ie, only in my home directory ). If I do an 'ls' without color, I don't see the symlinks at all. And strangely, after giving an error, it does actually put the directory in the LS list ( which no other command line tools do - CMD and Powershell don't try to list them ). If I run as administrator, I still get the errors.

Maybe this is a different issue and should be split out?

To recap:

• The symlinks are a strange Windows kind that aren't really there ( don't show up in CMD with a DIR or Powershell). There are about 10 of them in my home directory.
• A standard 'ls' command does the right thing and doesn't show the links and doesn't error
• an 'ls --color=auto' ( default Ubuntu ) shows a set of errors, AND shows these simlinks which it shouldn't.

Examples are 'Cookies' 'Templates' 'Recent' 'NetHood' ... in my user directory. No other directories that I can find have these annoying kinds of directories.

Happens in WSL1 and WSL2.

[therealkenc]

Maybe this is a different issue and should be split out?

It is, #2779.

[koyae]

Microsoft Windows [Version 10.0.18362.592] / 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01 16:53:00 PST 2019 x86_64 x86_64 x86_64 GNU/Linux

Confirming; links created using CMD's mklink which point to e.g. other drives are not understood by ls -l or cd under WSL (Ubuntu in my case). As an experiment, I also tried using the "Change Drive Letters and Paths" dialog to mount a storage-device into an empty directory on C:\ then use mklink to point to that so I'd have a relative link that could be used in WSL, but this fails since WSL can only understand the first link, but is unable to make the second jump to the D:\ drive (or wherever)

As an aside, Cygwin also creates "fake" links that only it can understand when its ln is called. Briefly jumping out to CMD to use mklink however creates pointers that both Cygwin and Explorer can follow just fine. Even an arrangement like that would be an improvement, even if using ln doesn't ultimately wind up as a wrapper for mklink.

I'd assume not, but am wondering... is there currently a way to arrange or express a drive/folder not at/below C:\ as a relative link that both WSL and Windows Explorer can understand? I know ln won't, so I'm guessing mount won't yield anything that's accessible in Explorer at the moment either.

[ivan2214]

You need to enable Windows Developer Mode so that Preconstruct can create symlinks - https://www.howtogeek.com/292914/what-is-developer-mode-in-windows-10/

This works for me 🫡