permission denied reading /mnt/c/Users/<user>/Cookies

[ricardojrgpimentel]

On bash when i try to do the command ls i get the following message:

ls: cannot read symbolic link '<Folder Name>': Permission denied

Im on version 10.0.16299.125

[therealkenc]

Please post your reproduction steps.

[danarth]

@therealkenc I get the same issue as @ricardojrgpimentel . The only steps I take are:

• cd /mnt/c/Users/<my username>
• ls

This gives me the following output:

ls: cannot read symbolic link 'Application Data': Permission denied
ls: cannot read symbolic link 'Cookies': Permission denied
ls: cannot read symbolic link 'Local Settings': Permission denied
ls: cannot read symbolic link 'My Documents': Permission denied
ls: cannot read symbolic link 'NetHood': Permission denied
ls: cannot read symbolic link 'PrintHood': Permission denied
ls: cannot read symbolic link 'Recent': Permission denied
ls: cannot read symbolic link 'SendTo': Permission denied
ls: cannot read symbolic link 'Start Menu': Permission denied
ls: cannot read symbolic link 'Templates': Permission denied

I am running a fresh install of Windows 10, and Ubuntu is the Linux distro I am using.

[therealkenc]

You don't have access to those on Windows either. Go to Windows Explorer, paste C:\Users\you\Cookies.

Interestingly enough though, ntfs-3g appears to get this right under an analogous scenario on Real Linux. So yeah.

[WSLUser]

Is this UserVoice worthy as it might considered a new feature. I know I would love to see this capability. Learning NTFS-3G can do it sounds to me like it's a simple reach out to that team to get the repro steps for implementing it and making any possible tailoring to make it more specific to Windows 10. I'm actually now curious to see about running NTFS-3G inside Ubuntu on WSL to test this scenario out. Maybe when I have more time for it.

[therealkenc]

Is this UserVoice worthy as it might considered a new feature.

Whether something is UserVoice worthy is in the eyes of the upvotes over there.

curious to see about running NTFS-3G inside Ubuntu on WSL

No that won't work per an oft-requested but currently unavailable feature, which I won't mention out loud because it doesn't have to do with the ask in the OP. But it starts with an F.

[WSLUser]

Well thanks for the enlightenment. Thanks for your hint about the unavailable feature. I had upvoted that already due to other things awhile ago. Hopefully it's addressed by fall this year but I won't be holding my breath either.

[shoffmeister]

Why is this issue not resolved as "working as designed" / "not a bug"?

If a user gets permission denied on the Windows side, why is there an expectation that the same user ("Windows identity") does not get the same permission denied from LInux?

One of the key differences between a real-life Linux and WSL here is that a real-life Linux simply does not offer any security on reading NTFS, while WSL has a fully integrated identity system. If someone wants to break the identity / security system, using Linux in a virtual machine and then mapping the raw disk into that virtual machine would appear to be the right thing?

[therealkenc]

Provisionally because you do technically have Windows permissions to resolve the link. You get reasonable behavior in Cygwin for example. There is no particular reason why the link shouldn't resolve in WSL as well. No identity system is "broken" by doing so. And, since this Permission denied error is the first thing people see in cd /mnt/c/Users/<my username>, and that is where folks land by default in Windows Store WSL Ubuntu, the present situation is less than ideal. There are no cases (or common cases that I can think of) in Real Linux where a you'd get a cannot read symbolic link error out of ls. At worst, if you don't have permission to the followed path, then the pathname is helpfully displayed in red with ls -l --color. That WSL does not behave the same one could argue is a bug/diverge. I haven't looked at the source, but I suspect that error message comes from a defensive "huh, how'd that happen" error path in ls.

[The "provisionally" caveat is because one can call anything as-designed by fiat. This issue isn't tagged one way or another.]

[shoffmeister]

Interesting.

cygwin bash:

$ pwd
/cygdrive/c

$ ls -la Documents\ and\ Settings
lrwxrwxrwx 1 SYSTEM SYSTEM 17 Jul 10  2015 'Documents and Settings' -> /cygdrive/c/Users

Powershell:

PS C:\> pwd

Path
----
C:\


PS C:\> Get-ChildItem  -Attributes Hidden '.\Documents and Settings\' | Format-List
Get-ChildItem : Access to the path 'C:\Documents and Settings' is denied.
At line:1 char:1
+ Get-ChildItem  -Attributes Hidden '.\Documents and Settings\' | Forma ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (C:\Documents and Settings\:String) [Get-ChildItem], UnauthorizedAcces
   sException
    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

I am my normal user self in both cases.

[shoffmeister]

And, again, powershell, this time on Ubuntu:

pwsh-preview

PowerShell v6.1.0-preview.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/pscore6-docs
Type 'help' to get help.

cd /mnt/c
PS /mnt/c>  Get-ChildItem -Attributes hidden './Documents and Settings' | Format-List

    Directory: /mnt/c

Name           : Documents and Settings
Length         : 0
CreationTime   : 7/10/15 2:21:38 PM
LastWriteTime  : 7/10/15 2:21:38 PM
LastAccessTime : 7/10/15 2:21:38 PM
Mode           : -----l
LinkType       : SymbolicLink
Target         :
VersionInfo    :

[therealkenc]

Nice experiments. In that last one (pwsh in Linux), whoever did that part of the port just opted for silence on "Target" rather than erroring out like ls. Getting into the weeds, I think (?) it is expected that on Linux, if a symlink node is returned by getdents() at all, then readlink() ought to succeed. But you'd have to pick apart the fine print of the LDP or POSIX docs to say for sure (or in reality read the Linux kernel source for the filesystem in question, since neither of those docs is actually authoritative). In a nutshell that is why this issue remains uncategorised, as opposed to being closed with the hard hammer of by-design judgement. Again, this is mostly about the present behaviour being "less than optimal" for newbies who just want to ls their landing directory. For now just enjoy the sound of the chirping crickets. Plenty of other open issues representing ambiguous edge cases to go around.

[cwebster2]

To add to the issue here is an excerpt from strace output from running ls -l My\ Documents:

lstat("My Documents", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
lgetxattr("My Documents", "security.selinux", 0x7fffda5797f0, 255) = -1 EOPNOTSUPP (Operation not supported)
readlink("My Documents", 0x7fffda5790b0, 1) = -1 EACCES (Permission denied)

the return value from lstat() is 0, indicating success. ls then looks for selinux attributes and finally calls readlink() , which should resolve the path My Documents is pointing at but instead returns EACCESS indicating "search permission is denied for a component of the path prefix". The man page path_resolution(7) details how this works.

I believe the behavior here to be incorrect. The readlink() implementation by WSL should be able to resolve the path, then walk it to determine if EACCESS is warranted (e.g. the link truly resolves to somewhere you don't have access to read), but in the general case where C:\Users\user\My Documents points to C:\Users\user\Documents, there is no access issues walking that path.

The detail that the My Documents is not truly a symbolic link and has underlying dependency on registry keys for resolving its destination is something that should be abstracted away in the readlink call.

Alternatively, the permissions for these files should be presented as 000, l--------- to indicate the user has no permission to the file.

[therealkenc]

Alternatively, the permissions for these files should be presented as 000, l--------- to indicate the user has no permission to the file.

I was going to suggest that but I think I lost by train of thought at the time I wrote my post. Thanks for framing the behavioral change request in concrete terms. I think abstracting it further might run into separation of concerns problems. For now it would be enough if WSL didn't cause ls to crap the bed. Someone will probably open a bug eventually asking why the perms on Cookies is "wrong", but that's a bridge that can be crossed another day.

[duhd1993]

@therealkenc is there a way to hide the error message? I know this is caused because ls is trying to accessing information without permission when doing the coloring. as long as I can hide the error message, i think it's fine. thank you!

[therealkenc]

is there a way to hide the error message?

Not without resorting to relatively extreme measures. Recompiling ls would be the most obvious approach. One could even make a case that ls might be better off being more tolerant of (or call it pretty about) an unexpected EACCES out of readlink(). It could even be upstreamed in principle.

[duhd1993]

@therealkenc I actually find a way to do that, by alias ls='ls 2>/dev/null'. I'm leaving it here in case someone searches for a workaround. Thank you anyway.

[therealkenc]

That's not a bad blunt instrument actually, since any other errors ls could (even hypothetically) spit out probably aren't in practice worth seeing either. Good answer, thanks. My mindset was in a "fix it" mode instead of a "kill it with fire" mode.

[realchrisolin]

It's worth noting that this bug indirectly breaks Jupyter Notebook when run from a user's home directory. Documented workarounds can found in the issue thread, but unlike this issue as it manifests with the ls command, it is causing a "hard fail" with Jupyter. Combined with @cwebster2's comment, this issue is clearly a bug and if Microsoft is serious about WSL, it needs to be fixed.

[JustAShoeMaker]

It's a bug. If its attached to my files system (in my case, a cryptomator mounted folder on the Windows side) and they are in all ways mine, I should be able to list it.

[rkitover]

I am using my windows home folder as my WSL home, I made this ls function for ~/.bashrc if anyone is interested:

ls() {
    ls_opts="-h --color=auto"

    if [ $# -eq 0 ]; then
        if [ "$PWD" = "$HOME" ]; then
            ls_opts="$ls_opts --hide='ntuser.*' --hide='NTUSER.*'"
        fi

        eval command ls "$ls_opts" '"$@"' 2>/dev/null
        return 0
    fi

    eval command ls "$ls_opts" '"$@"'
}

this makes this behavior more pleasant to deal with.

[YantCaccia]

I am using my windows home folder as my WSL home, I made this ls function for ~/.bashrc if anyone is interested:
ls() {
ls_opts="-h --color=auto"

if [ $# -eq 0 ]; then
    if [ "$PWD" = "$HOME" ]; then
        ls_opts="$ls_opts --hide='ntuser.*' --hide='NTUSER.*'"
    fi

    eval command ls "$ls_opts" '"$@"' 2>/dev/null
    return 0
fi

eval command ls "$ls_opts" '"$@"'

}
this makes this behavior more pleasant to deal with.

how to use that?

[rkitover]

Just paste the function into your ~/.bashrc

[rkitover]

You might want this too:

# remove background colors from dircolors
eval "$(dircolors -p | \
    sed 's/ 4[0-9];/ 01;/; s/;4[0-9];/;01;/g; s/;4[0-9] /;01 /' | \
    dircolors /dev/stdin)"

[Maissacrement]

On ~/.bashrc you can just make an alias for output:

Firstly create the file: touch /var/log/.ls-error
In a second time make you privilege on this file : sudo chown $USER:$USER /var/log/.ls-error

In ~/.bashrc:

# ls alias redirect output to /var/log/.ls-error
alias ls='ls $@ 2> /var/log/.ls-error --color=auto'

[therealkenc]

Thanks for pinging this one. I was hoping this would resolve itself in WSL 2 with the new 9p /mnt/c. Alas no joy.

But now that we have Linux CIFS for reals, it did make me wonder how the Windows SMB server deals with those symlinks. Rather than present the files as "l---------" as suggested last summer, the entries just don't appear... because SMB never serves them up, and on the Linux side, getdents(2) never returns them. Which is along the lines of my earlier comment here.

So I guess a reasonable new ask is: "make 9p behave like SMB."

[therealkenc]

Ever?

Just 'sayin.

Practical work-around for now remains redirect 2>/dev/null. Someone motivated might also consider an upstream patch to Ubuntu's coreutils to make ls(1) more tolerant of the bug WSL's alternative filesystem semantics.

[therealkenc]

From #4104 (message)

Something similar started happening to me, but it is only when ls --colors=auto

That's actually a half-interesting data point. It isn't colors. It happens any time the readlink(2) + stat(2) combo is evoked. Which doesn't happen in a bare ls(1), which only needs the name out of getdents(2). You'll get the same EPERM with:

$ "ls" -l     # <--- EPERM fail, with or without the ls colors alias

[therealkenc]

The EPERM on those legacy (if that is the word) Windows symlinks such as /User/<username>/Cookies has been addressed in 18980. Works in both WSL1 and WSL2. Very awesome 💯.

[onuryurdupak]

I am using my windows home folder as my WSL home, I made this ls function for ~/.bashrc if anyone is interested:

ls() {
    ls_opts="-h --color=auto"

    if [ $# -eq 0 ]; then
        if [ "$PWD" = "$HOME" ]; then
            ls_opts="$ls_opts --hide='ntuser.*' --hide='NTUSER.*'"
        fi

        eval command ls "$ls_opts" '"$@"' 2>/dev/null
        return 0
    fi

    eval command ls "$ls_opts" '"$@"'
}

this makes this behavior more pleasant to deal with.

I know this is old but...
This is a nice workaround.
I had this problem with WSL when using Terminator via X Service.
But naming the function "ls" caused a syntax error so I worked around it by giving the function another name and defining an alias for it like this:

ls_override () {
    ls_opts="-h --color=auto"

    if [ $# -eq 0 ]; then
        if [ "$PWD" = "$HOME" ]; then
            ls_opts="$ls_opts --hide='ntuser.*' --hide='NTUSER.*'"
        fi

        eval command ls "$ls_opts" '"$@"' 2>/dev/null
        return 0
    fi

    eval command ls "$ls_opts" '"$@"'
}
alias ls=ls_override