Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P9 Explorer Integration not working #4027

Open
bushidocodes opened this issue May 10, 2019 · 21 comments

Comments

@bushidocodes
Copy link

commented May 10, 2019

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

Please fill out the below information:

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

  • 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.)

Based on the recent WSL blogs, I expect to see WSL as a network drive in Explorer or to be able to open my active WSL directory by typing Explorer.exe .

When I enter the Explorer command from anywhere in the Linux filesystem, it opens my Windows Documents folder in Explorer

When I try to manually navigate to the path suggested by the blog posts, I get a 0x80004005
image

However, I can navigate to that directory from Powershell.
image

If it's relevant, here is a snapshop of my network devices. I've got some VPN stuff and Hyper-V V Switches, including for Docker for Windows.

@jonitis

This comment has been minimized.

Copy link

commented May 14, 2019

Might be similar to #3995

@shinji257

This comment has been minimized.

Copy link

commented May 22, 2019

I've updated to 1903 18362.30 as of yesterday and I'm noticing this issue as well. What I've noticed is this.

  • dir //wsl$/Ubuntu works
  • explorer.exe . inside a /mnt point works fine. Explorer.exe comes up to the expected path location
  • explorer.exe . anywhere in the linux rootfs (outside of /mnt points) ends up at the user Documents folder instead of the expected translation to a point inside the P9 path.
  • Can't access //wsl$/Ubuntu directly inside File Explorer

All tests done while Ubuntu is running. Did a clean install of the Ubuntu "app".

@benhillis

This comment has been minimized.

Copy link
Member

commented May 22, 2019

@SvenGroot - Could you please take a look into this?

@bushidocodes

This comment has been minimized.

Copy link
Author

commented May 24, 2019

After getting the final official 1903 build (I've previously been on 1903 as an insider), I went blew away both of my Pengwin-based environments and fully disabled and re-enabled the WSL feature. This seems to have resolved this issues for me on both of my systems. Since I has having this problem consistently on both machines, this suggests that something might have misfired in applying an update to an existing WSL install.

@SvenGroot

This comment has been minimized.

Copy link
Member

commented May 24, 2019

Anybody who's still in this state, can you please give me the output of the following commands:

dir %windir%\System32\p9np.dll
reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s
reg query HKLM\SYSTEM\CurrentControlSet\Services\p9np /s
reg query HKLM\SYSTEM\CurrentControlSet\Services\p9rdr /s

That would be very helpful in diagnosing this issue.

For those who are interested, here's the reason why it works in cmd or PowerShell, but not in explorer.exe. \\wsl$ is essentially treated by the system as a network file system (even though it isn't really), which consist of two components: a redirector driver, and a network provider DLL. The former handles actual file system requests, while the latter provides information about connections and paths to the system. This DLL also implements things like "share" enumeration (distribution enumeration in WSL's case), and "map drive" functionality.

The network provider DLL is not used when applications just try to create a file using a \\wsl$\distro path, which is what cmd and PowerShell do. Explorer on the other hand always tries to get information about a UNC path from the network provider DLL, and won't issue a file system call unless that's successful. So in the situation described in this thread, the redirector driver is fine, but the DLL is not working as intended for some reason.

@hazzanz

This comment has been minimized.

Copy link

commented May 24, 2019

Turning off and on WSL worked for me. I didn't need to delete the instance.

@shinji257

This comment has been minimized.

Copy link

commented May 25, 2019

Anybody who's still in this state, can you please give me the output of the following commands:

dir %windir%\System32\p9np.dll
reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s
reg query HKLM\SYSTEM\CurrentControlSet\Services\p9np /s
reg query HKLM\SYSTEM\CurrentControlSet\Services\p9rdr /s

That would be very helpful in diagnosing this issue.

As requested.

C:\Users\shinj>dir %windir%\System32\p9np.dll
 Volume in drive C has no label.
 Volume Serial Number is 6473-A230

 Directory of C:\WINDOWS\System32

05/23/2019  01:51 AM           101,688 p9np.dll
               1 File(s)        101,688 bytes
               0 Dir(s)  50,341,449,728 bytes free

C:\Users\shinj>reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder
    PROVIDERORDER    REG_SZ    RDPNP,LanmanWorkstation,webclient

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    PROVIDERORDER    REG_SZ    RDPNP,LanmanWorkstation,webclient

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
    LanmanWorkstation    REG_DWORD    0x7d0
    RDPNP    REG_DWORD    0x3e8
    webclient    REG_DWORD    0xbb8
    P9NP    REG_DWORD    0x1f4


C:\Users\shinj>reg query HKLM\SYSTEM\CurrentControlSet\Services\p9np /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9np
    Description    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-101
    DisplayName    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-100

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9np\NetworkProvider
    DeviceName    REG_SZ    \Device\P9Rdr
    DisplayName    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-100
    Name    REG_SZ    Plan 9 Network Provider
    ProviderPath    REG_EXPAND_SZ    %SystemRoot%\System32\p9np.dll


C:\Users\shinj>reg query HKLM\SYSTEM\CurrentControlSet\Services\p9rdr /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9rdr
    DependOnService    REG_MULTI_SZ    RDBSS
    Description    REG_SZ    @%SystemRoot%\System32\drivers\p9rdr.sys,-101
    DisplayName    REG_SZ    @%SystemRoot%\System32\drivers\p9rdr.sys,-100
    ErrorControl    REG_DWORD    0x1
    ImagePath    REG_EXPAND_SZ    System32\drivers\p9rdr.sys
    Start    REG_DWORD    0x3
    Type    REG_DWORD    0x1
@SvenGroot

This comment has been minimized.

Copy link
Member

commented May 28, 2019

@shinji257 Thanks, that's very interesting.

It appears that P9NP is missing from the comma-separated list under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order and HwOrder. It's present in ProviderOrder, but that doesn't do anything by itself if the value is not in the comma-separated list. This will cause Explorer and any other application that uses the network provider DLL to not consider our provider at all.

You should be able to work around this by just adding P9NP as the first entry in the comma-separated list under both keys (in your case, this would be "P9NP,RDPNP,LanmanWorkstation,webclient"). You might need to restart for that change to take effect.

This suggests there's some bug in the upgrade logic for this particular registry key. We'll investigate further and I'll keep you updated.

@shinji257

This comment has been minimized.

Copy link

commented May 29, 2019

Thank you. I've checked and verified that was indeed all that was needed to workaround for this issue and it updated both Order and HwOrder at the same time when I did that.

EDIT: Restarting the system, relogging, or even reloading explorer.exe was not needed. The effect was immediate.

@danluca

This comment has been minimized.

Copy link

commented Jun 3, 2019

Have a similar issue but on the worse side - just updated to Windows 1903, had the legacy lxrun distro installed (Bash on Windows). Have wiped it out and started fresh, enabled WSL feature and installed Ubuntu distro from MS store.

The distro launches fine, but none of the "\wsl$" integration works for me - neither command prompt, nor explorer.
Looking at the output to the command checks posted by shinji257 - my output looks correct, the P9NP is in the right places:

D:\> cmd /c ver
Microsoft Windows [Version 10.0.18362.145]

D:\> cmd /c dir %windir%\System32\p9np.dll
 Directory of C:\WINDOWS\System32
06.02.2019  12:18 AM           101 688 p9np.dll
               1 File(s)        101 688 bytes

D:\> reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder
    ProviderOrder    REG_SZ    P9NP,RDPNP,LanmanWorkstation,webclient
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    ProviderOrder    REG_SZ    P9NP,RDPNP,LanmanWorkstation,webclient
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
    LanmanWorkstation    REG_DWORD    0x7d0
    RDPNP    REG_DWORD    0x3e8
    webclient    REG_DWORD    0xbb8
    P9NP    REG_DWORD    0x1f4

D:\> reg query HKLM\SYSTEM\CurrentControlSet\Services\p9np /s
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9np
    Description    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-101
    DisplayName    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-100
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9np\NetworkProvider
    DeviceName    REG_SZ    \Device\P9Rdr
    DisplayName    REG_EXPAND_SZ    @%systemroot%\system32\p9np.dll,-100
    Name    REG_SZ    Plan 9 Network Provider
    ProviderPath    REG_EXPAND_SZ    %SystemRoot%\System32\p9np.dll
	
D:\> reg query HKLM\SYSTEM\CurrentControlSet\Services\p9rdr /s
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p9rdr
    DependOnService    REG_MULTI_SZ    RDBSS
    Description    REG_SZ    @%SystemRoot%\System32\drivers\p9rdr.sys,-101
    DisplayName    REG_SZ    @%SystemRoot%\System32\drivers\p9rdr.sys,-100
    ErrorControl    REG_DWORD    0x1
    ImagePath    REG_EXPAND_SZ    System32\drivers\p9rdr.sys
    Start    REG_DWORD    0x3
    Type    REG_DWORD    0x1

Any ideas what to look for next?

@RoguePointer80

This comment has been minimized.

Copy link

commented Jun 17, 2019

Similar issue here.

Microsoft Windows [Version 10.0.18362.175]

C:\Users\frivard>reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder
    ProviderOrder    REG_SZ    P9NP,RDPNP,LanmanWorkstation,webclient

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    ProviderOrder    REG_SZ    P9NP,RDPNP,LanmanWorkstation,webclient

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
    LanmanWorkstation    REG_DWORD    0x7d0
    RDPNP    REG_DWORD    0x3e8
    webclient    REG_DWORD    0xbb8
    P9NP    REG_DWORD    0x1f4

So it appears the order is correct. The other two queries are the same as @danluca .
With Windows Explorer, going to \wsl$, I can see my distro correctly (Ubuntu-16.04). It is currently running bash.
Trying to access \wsl$\Ubuntu-16.04 in Windows Explorer gives "Attempt to access invalid address".

With cmd:

C:\Users\frivard>dir \\wsl$\Ubuntu-16.04
The remote computer refused the network connection.

With Powershell:

PS C:\Users\frivard> dir \\wsl$\Ubuntu-16.04
dir : Cannot find path '\\wsl$\Ubuntu-16.04' because it does not exist.
At line:1 char:1
+ dir \\wsl$\Ubuntu-16.04
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (\\wsl$\Ubuntu-16.04:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Similar to other users, after upgrading to Windows 1903, I deleted my old distros, and installed a fresh one; installed a bunch of tools inside it, then I did an export of it. I remember at that point I was able to access the Linux files because I copied a file in it.
Shutdown my computer, next day install a bunch of Windows updates, reboot computer...
That's when I tried to use my new distro and noticed I could no longer access the Linux files with the 9P integration. I rebooted the computer again, but it did not fix the issue.

Any idea how to diagnose this? I had a look at the Windows Event Logs, but could not see anything related to WSL.

@SvenGroot

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

Can you post the output of running dmesg in WSL? If the server encountered any problems when starting, it should be in there.

@RoguePointer80

This comment has been minimized.

Copy link

commented Jun 17, 2019

index@WKS-000837:~$ dmesg
[    0.020411]  Microsoft 4.4.0-18362.1-Microsoft 4.4.35
[    0.120460] <3>init: (1) ERROR: LogException:23: FS: Could not start file system server. Operation not permitted @.\plan9.cpp:33 (TranslatePath)

Ah! you're right, the server on the Linux distro simply did not start.
I see TranslatePath... does it matter that I disabled the /mnt/c in my wsl.conf?

Here is my wsl.conf. If I screwed up, I'm sorry.

index@WKS-000837:~$ cat /etc/wsl.conf
[automount]
enabled = false
mountFsTab = true

[network]
generateHosts = true
generateResolvConf = true

[interop]
enabled = false
appendWindowsPath = false
@SvenGroot

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

Yes, that would be it. :)

The \\wsl$ file system access communicates with the Plan 9 server running in WSL's init using a Unix socket, and that socket is created in in a directory under /mnt/c. So yeah, you need to enable automount for this to work (or at least explicitly mount your C: drive in fstab).

Note that this is not the case in WSL 2, since in that case we communicate over a Hyper-V socket instead.

@RoguePointer80

This comment has been minimized.

Copy link

commented Jun 17, 2019

@SvenGroot Thank you for your quick reply. Also I wanted to let you know, Thank You to all the WSL team, it is a great product and I use it everyday. And especially that 9P thing, it is super-awesome work. Keep it up!

@SvenDowideit

This comment has been minimized.

Copy link

commented Jun 21, 2019

@SvenGroot had to add P9NP to the Order registry key on 2 systems - both were upgraded from WSL i1 n the last week
👍 :)

@danluca

This comment has been minimized.

Copy link

commented Jun 23, 2019

Still doesn't work for me, any suggestions on how to debug this issue further? How can I check whether the P9 server is running? I've attached the log files (captured with logman per the instructions) and the output of the ps aux is below:
lxcore.zip

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   8892   308 ?        Ssl  13:39   0:00 /init
root         8  0.0  0.0   8904   220 tty1     Ss   13:39   0:00 /init
dan          9  0.1  0.0  16792  3464 tty1     S    13:39   0:00 -bash
root        26  0.0  0.0  17272  2536 tty1     S    13:41   0:00 sudo -s
root        27  0.0  0.0  16688  3308 tty1     S    13:41   0:00 /bin/bash
root        39  3.0  0.0  17380  1920 tty1     R    13:42   0:00 ps aux

The dmesg produces a single line output - [ 0.007696] Microsoft 4.4.0-18362.1-Microsoft 4.4.35
Ideas?

@PureBasic

This comment has been minimized.

Copy link

commented Jul 7, 2019

Ubuntu and Debian are working fine, but I can't access the subsystem files at all, and P9 doesn't seems to be there at all... I surely messed something up during the install, but can't find a fix. I also tried going backward and made a clean install trough the MS Store, didn't worked.

Windows 10.0.17134

PS C:\Users\Beubeuh> dir %windir%\System32\p9np.dll
dir : Impossible de trouver le chemin d'accès « C:\Users\Beubeuh\%windir%\System32\p9np.dll », car il n'existe pas.
Au caractère Ligne:1 : 1
+ dir %windir%\System32\p9np.dll
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Users\Beubeu...stem32\p9np.dll:String) [Get-ChildItem], ItemNotFound
   Exception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

PS C:\Users\Beubeuh> reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider /s

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder
    ProviderOrder    REG_SZ    RDPNP,LanmanWorkstation,webclient,Nfsnp

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    ProviderOrder    REG_SZ    RDPNP,LanmanWorkstation,webclient,Nfsnp

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
    LanmanWorkstation    REG_DWORD    0x7d0
    RDPNP    REG_DWORD    0x3e8
    webclient    REG_DWORD    0xbb8
    nfsnp    REG_DWORD    0xfa0

PS C:\Users\Beubeuh> reg query HKLM\SYSTEM\CurrentControlSet\Control\p9np /s
Erreur : Erreur : le système n’a pas trouvé la clé ou la valeur de Registre spécifiée.
PS C:\Users\Beubeuh> reg query HKLM\SYSTEM\CurrentControlSet\Control\p9rdr /s
Erreur : Erreur : le système n’a pas trouvé la clé ou la valeur de Registre spécifiée.
PS C:\Users\Beubeuh>

Also, wsl --shutdown yields a command not found error inside the subsystems.

@craigloewen-msft

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

@PureBasic it looks like you're using an older version of Windows that does not have the P9 feature. You need to upgrade your Windows version to 1903 or later (Windows Build 18362).

@PureBasic

This comment has been minimized.

Copy link

commented Jul 15, 2019

@mscraigloewen
Thanks, it worked after updating indeed !
I thought my system was up to date, turns out I had only the critical updates enabled.

@mjbright

This comment has been minimized.

Copy link

commented Sep 3, 2019

Thanks, the registry fix worked for me.

However, I still can't access anything under home, i.e. \wsl$\Ubuntu\home is empty
Why is that?

==> OK, just realized why
It's been a while since I switched to WSL,
I forgot that my home dir was a link to C:\tools\cygwin\home\windo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.