Powershell: Set-Location \\wsl$\Ubuntu throws an error

Created on 15 Aug 2019  路  22Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

  • execute when wsl2 is up and running
    powershell Set-Location \\wsl$\Ubuntu

Expected behavior

  • successfully changes directory
PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu>

Actual behavior

  • throws an error
Set-Location : Cannot process argument because the value of argument "path" is not valid. Change the value of the "path" argument and run the operation again.                                                                                  At line:1 char:1
+ Set-Location \\wsl$\Ubuntu
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [Set-Location], PSArgumentException
+ FullyQualifiedErrorId : Argument,Microsoft.PowerShell.Commands.SetLocationCommand

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.2
PSEdition                      Core
GitCommitId                    6.2.2
OS                             Microsoft Windows 10.0.18956
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Note: Same behavior on 7.0.0-preview.2, but everything is working on Windows Powershell 5.1

Issue-Bug Resolution-Fixed WG-Engine-Providers

Most helpful comment

Cmd doesn't support UNC paths as far as i know. But powershell.exe (5.1) works.

All 22 comments

Because $ is used to denote a variable in PowerShell, try Set-Location '\\wsl$\Ubuntu' or Set-Location \\wsl`$\Ubuntu ~or Set-Location --% \\wsl$\Ubuntu~.

image
Didn't work unfortunately.

Set-Location "\wsl$\Ubuntu" also doesn't work

First one should work, I typo'd were the ' should be but I updated/fixed it above. The second one is interesting - would have expected that to work. Retracted the third one, --% is primarily for native exes.

image
Still throws an error.

Well, perhaps a real issue then. If you bring up cmd.exe, I assume you can cd to this dir, right?

It also seems that PowerShell is smart about not interpreting $ as the start of a variable if the next character is invalid in a variable name.

Cmd doesn't support UNC paths as far as i know. But powershell.exe (5.1) works.

Look like we can not parse UNC path if a computer name ends with $

Is it a computername, or is it a drive name? That syntax is usually UNC syntax for a drive... maybe try \\localhost\wsl$\... instead?

Is it a computername, or is it a drive name? That syntax is usually UNC syntax for a drive... maybe try \\localhost\wsl$\... instead?

image

I just checked and it can't Set-Location into directory, but Get-ChildItem works.

The same behaviour occurs if you try to set the path as a PSDrive (in Powershell Core 6.2.3):

PS C:\Users\yabea> New-PSDrive -Name WSL -PSProvider "FileSystem" -Root "\\wsl$\Ubuntu-18.04"

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
WSL                                    FileSystem    \\wsl$\Ubuntu-18.04                                                                                                                                                                        

PS C:\Users\yabea> cd WSL:
cd : Cannot process argument because the value of argument "path" is not valid. Change the value of the "path" argument At line:1 char:1
+ cd WSL:
+ ~~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [Set-Location], PSArgumentException
+ FullyQualifiedErrorId : Argument,Microsoft.PowerShell.Commands.SetLocationCommand

PS C:\Users\yabea> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.3
PSEdition                      Core
GitCommitId                    6.2.3
OS                             Microsoft Windows 10.0.18985
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

While it works as expected in Powershell as part of Windows Insider Preview build 18985.1:

C:\Users\yabea> New-PSDrive -Name WSL -PSProvider "FileSystem" -Root "\\wsl$\Ubuntu-18.04"

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
WSL                                    FileSystem    \\wsl$\Ubuntu-18.04

C:\Users\yabea> cd WSL:
WSL:\> ls

    Directory: \\wsl$\Ubuntu-18.04

----                 -------------         ------ ----
d-----        17/09/2019     09:34                home
d-----        21/05/2019     15:39                srv
d-----        24/09/2019     22:49                etc
d-----        21/05/2019     15:39                opt
d-----        23/09/2019     00:00                root
d-----        18/09/2019     14:36                lib
d-----        18/09/2019     13:34                mnt
d-----        21/05/2019     15:39                usr
d-----        24/09/2019     22:49                media
d-----        21/05/2019     15:39                lib64
d-----        24/09/2019     22:49                sys
d-----        24/09/2019     22:49                dev
d-----        17/09/2019     14:36                sbin
d-----        21/05/2019     15:42                boot
d-----        17/09/2019     14:36                bin
d-----        24/09/2019     22:49                run
d-----        24/09/2019     22:49                proc
d-----        23/09/2019     23:02                snap
d-----        24/09/2019     22:49                tmp
d-----        21/05/2019     15:42                var
d-----        10/04/2019     17:35                lost+found
------        01/01/1970     00:00              0 init

WSL:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.18985.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18985.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

I just checked and it can't Set-Location into directory, but Get-ChildItem works.

Get-ChildItem does not work for me, on 7.0.0-preview.2 or 7.0.0-preview.3.

It does work for me on 6.2.1, however (and 5.1, as described by others).

IMO this is a painful regression because it prevents you from using pwsh with the fancy new WSL2 feature that everybody wants to try out. We should really get it fixed for PSv7.

It's very easy to set up a repro for this--if you search for WSL2, there are lots of people talking about it and sharing the instructions to set it up. Here are the official instructions.

/cc @SteveL-MSFT for information.

I'm trying to repro this. Got WSL setup following the instructions by @jazzdelightsme, although the switches for wsl.exe have changed. Installed Ubuntu. \\wsl$\ubuntu doesn't work in WinPS 5.1. Need a working example in WinPS 5.1 to debug why it's not working in PS7.

I am very wonder why the format \\wsl$\ubuntu is used. It looks like \servername\share but naming convention does not allow "$" in DNS names and allow in NetBIOS names. https://support.microsoft.com/en-gb/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and
It seems NetBIOS deprecated. @SteveL-MSFT Can you ask WSL team about the strange name format?

Also the format assumes that PoweerShell will use remoting?

I believe the $ is specifically so that the name does _not_ conform to netbios conventions. The wsl filesystem handler is not SMB and so trying to look up the name via netbios will cause issues. The wsl filesystem is internally routed through a 9p server handled by the init processes. There is no network-accessible name as everything is within a single PC.

Still waiting on a repro where that path works.

Looks like my version of Windows isn't new enough. Upgrading to newer version.

Ok, can repro this

:tada:This issue was addressed in #10674, which has now been successfully released as v7.0.0-preview.5.:tada:

Handy links:

Was this page helpful?
0 / 5 - 0 ratings