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

[BUG] using npm in windows on a wsl file mount path causes error #6280

Closed
2 tasks done
getify opened this issue Mar 22, 2023 · 6 comments · Fixed by #6548
Closed
2 tasks done

[BUG] using npm in windows on a wsl file mount path causes error #6280

getify opened this issue Mar 22, 2023 · 6 comments · Fixed by #6548
Labels
Bug thing that needs fixing Priority 2 secondary priority issue Release 9.x work is associated with a specific npm 9 release

Comments

@getify
Copy link

getify commented Mar 22, 2023

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

This bug has been reported a number of times before (#3349, #1189) , as far back as v6 as far as I can tell.

I am not sure why, but such bug reports seem to get little to no attention from npm folks, and then eventually someone or some bot just closes the bug and says "too old, please re-open". SMH. So here I am, opening yet again.

I'm on version 9.5.1 of npm, on Windows 11.

I also have WSL2 (Debian) on this machine, which means I have a linux filesystem that windows mounts at a path like:

\\wsl$\Debian\home\my-user\tmp

These paths (I guess called "UNC paths"?) work fine across Windows, in File Explorer and pretty much all windows apps I use (like Sublime, Chrome, etc).

If I go into a Windows shell (i.e., Powershell), and switch to that path, it works fine:

PS C:\Users\my-user> cd \\wsl$\Debian\home\my-user\tmp
PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Debian\home\my-user\tmp>

I can the n issue a command like this, and it works fine:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Debian\home\my-user\tmp> node --version
v19.8.1

However, if I then issue a npm command from that location, I get an error:

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Debian\home\my-user\tmp> npm --version
'\\wsl$\Debian\home\my-user\tmp'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
9.5.1

As you can see, the command runs, but not in the correct working directory.

For --version, that's mildly annoying, but no big deal. But other commands, like npm install, run in C:\Windows working directory instead of where I want them to run, which is completely broken and very bad.

Obviously, the command should run in the current working directory I am in.

Expected Behavior

I expect the npm program to run in whatever working directory I'm in, regardless of how the (valid) path looks, without errors or (worse!) switching to another directory to run the command!

As a bad (but at least reasonable) fallback, if there's just no way UNC paths could be supported (which is terrible), at a minimum these commands should just refuse to run altogether, rather than running in the wrong directory -- especially C:\Windows... good grief!

Steps To Reproduce

  1. windows 10 or 11
  2. with WSL2 installed, with a linux distribution like Ubuntu or Debian, and a file system mounted in windows like \\wsl$\Debian\home\my-user\tmp
  3. also with node and npm installed in windows, not just inside of WSL
  4. open powershell, and do cd to switch to that directory location
  5. issue command npm install
  6. notice the error about "UNC Paths" not being supported and how the npm command (like for example an npm install) operates in the default C:\Windows directory incorrectly

Environment

  • npm: 9.5.1
  • Node.js: 19.8.1
  • OS Name: Windows 11 Professional
  • System Model Name: Surface Laptop 5
  • npm config:
PS C:\Users\my-user> npm config list -l
; "default" config from default values

_auth = (protected)
access = null
all = false
allow-same-version = false
also = null
audit = true
audit-level = null
auth-type = "web"
before = null
bin-links = true
browser = null
ca = null
cache = "C:\\Users\\my-user\\AppData\\Local\\npm-cache"
cache-max = null
cache-min = 0
cafile = null
call = ""
cert = null
ci-name = null
cidr = null
color = true
commit-hooks = true
depth = null
description = true
dev = false
diff = []
diff-dst-prefix = "b/"
diff-ignore-all-space = false
diff-name-only = false
diff-no-prefix = false
diff-src-prefix = "a/"
diff-text = false
diff-unified = 3
dry-run = false
editor = "C:\\Windows\\notepad.exe"
engine-strict = false
fetch-retries = 2
fetch-retry-factor = 10
fetch-retry-maxtimeout = 60000
fetch-retry-mintimeout = 10000
fetch-timeout = 300000
force = false
foreground-scripts = false
format-package-lock = true
fund = true
git = "git"
git-tag-version = true
global = false
global-style = false
globalconfig = "C:\\Users\\my-user\\AppData\\Roaming\\npm\\etc\\npmrc"
heading = "npm"
https-proxy = null
if-present = false
ignore-scripts = false
include = []
include-staged = false
include-workspace-root = false
init-author-email = ""
init-author-name = ""
init-author-url = ""
init-license = "ISC"
init-module = "C:\\Users\\my-user\\.npm-init.js"
init-version = "1.0.0"
init.author.email = ""
init.author.name = ""
init.author.url = ""
init.license = "ISC"
init.module = "C:\\Users\\my-user\\.npm-init.js"
init.version = "1.0.0"
install-links = false
install-strategy = "hoisted"
json = false
key = null
legacy-bundling = false
legacy-peer-deps = false
link = false
local-address = null
location = "user"
lockfile-version = null
loglevel = "notice"
logs-dir = null
logs-max = 10
; long = false ; overridden by cli
maxsockets = 15
message = "%s"
metrics-registry = "https://registry.npmjs.org/"
node-options = null
noproxy = [""]
offline = false
omit = []
omit-lockfile-registry-resolved = false
only = null
optional = null
otp = null
pack-destination = "."
package = []
package-lock = true
package-lock-only = false
parseable = false
prefer-offline = false
prefer-online = false
; prefix = "C:\\Program Files\\nodejs" ; overridden by builtin
preid = ""
production = null
progress = true
provenance = false
proxy = null
read-only = false
rebuild-bundle = true
registry = "https://registry.npmjs.org/"
replace-registry-host = "npmjs"
save = true
save-bundle = false
save-dev = false
save-exact = false
save-optional = false
save-peer = false
save-prefix = "^"
save-prod = false
scope = ""
script-shell = null
searchexclude = ""
searchlimit = 20
searchopts = ""
searchstaleness = 900
shell = "C:\\Windows\\system32\\cmd.exe"
shrinkwrap = true
sign-git-commit = false
sign-git-tag = false
strict-peer-deps = false
strict-ssl = true
tag = "latest"
tag-version-prefix = "v"
timing = false
tmp = "C:\\Users\\my-user\\AppData\\Local\\Temp"
umask = 0
unicode = false
update-notifier = true
usage = false
user-agent = "npm/{npm-version} node/{node-version} {platform} {arch} workspaces/{workspaces} {ci}"

userconfig = "C:\\Users\\my-user\\.npmrc"
version = false
versions = false
viewer = "browser"
which = null
workspace = []
workspaces = null
workspaces-update = true
yes = null

; "builtin" config from C:\Program Files\nodejs\node_modules\npm\npmrc

prefix = "C:\\Users\\my-user\\AppData\\Roaming\\npm"

; "cli" config from command line options

long = true
@getify getify added Bug thing that needs fixing Needs Triage needs review for next steps Release 9.x work is associated with a specific npm 9 release labels Mar 22, 2023
@mribbons
Copy link
Contributor

mribbons commented Mar 22, 2023

If you run cmd.exe from a UNC path, windows won't set the shell's environment as that path, it will instead default to %SystemRoot%

You can test this by navigating to a non UNC path in explorer, edit the address bar and type cmd.exe, you should get a command prompt in that folder.

If you do the same from a UNC path, cmd.exe's cwd will be %SystemRoot%

It looks like Powershell supports UNC paths, but my guess is that npm runs as a separate sub process, and the old UNC path inheritance problem still occurs.

Maybe the answer here is for npm to deploy a npm.ps1 shim as well as npm.cmd

@getify
Copy link
Author

getify commented Apr 28, 2023

Ping. Anyone from npm?

@mribbons
Copy link
Contributor

mribbons commented Jun 9, 2023

Try this script:

#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent

$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
  # Fix case when both the Windows and Linux builds of Node
  # are installed in the same directory
  $exe=".exe"
}
$ret=0

$nodebin = $(Get-Command "node$exe" -ErrorAction SilentlyContinue -ErrorVariable F).Source
if ($nodebin -eq $null) {
  Write-Host "node$exe not found."
  exit 1
}
$nodedir = $(New-Object -ComObject Scripting.FileSystemObject).GetFile("$nodebin").ParentFolder.Path

# Support pipeline input
if ($MyInvocation.ExpectingInput) {
  $input | & "node$exe" "$nodedir/node_modules/npm/bin/npm-cli.js" $args
} else {
  & "node$exe" "$nodedir/node_modules/npm/bin/npm-cli.js" $args
}
$ret=$LASTEXITCODE
exit $ret

Save it in the same folder as this:

$(Get-Command "npm").Source
PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu-22.04\home\test> npm --version
8.5.0 🎉 

mribbons added a commit to mribbons/npm-cli that referenced this issue Jun 9, 2023
Resolves UNC path issues because powershell.exe
supports UNC, while cmd.exe doesn't.
(Which is why npm.cmd doesn't work within
UNC paths, even under powershell)

Resolves npm#6280
@lukekarrys lukekarrys added Priority 2 secondary priority issue and removed Needs Triage needs review for next steps labels Jun 15, 2023
lukekarrys pushed a commit to mribbons/npm-cli that referenced this issue Jun 23, 2023
Resolves UNC path issues because powershell.exe
supports UNC, while cmd.exe doesn't.
(Which is why npm.cmd doesn't work within
UNC paths, even under powershell)

Resolves npm#6280
lukekarrys pushed a commit that referenced this issue Jun 23, 2023
Resolves UNC path issues because powershell.exe
supports UNC, while cmd.exe doesn't.
(Which is why npm.cmd doesn't work within
UNC paths, even under powershell)

Resolves #6280
wraithgar pushed a commit to mribbons/npm-cli that referenced this issue Jun 26, 2023
Resolves UNC path issues because powershell.exe
supports UNC, while cmd.exe doesn't.
(Which is why npm.cmd doesn't work within
UNC paths, even under powershell)

Resolves npm#6280
wraithgar pushed a commit that referenced this issue Jun 26, 2023
* add ps1 scripts

Resolves UNC path issues because powershell.exe
supports UNC, while cmd.exe doesn't.
(Which is why npm.cmd doesn't work within
UNC paths, even under powershell)

Resolves #6280

* fixup: add tests and prefix for ps1 scripts

---------

Co-authored-by: Luke Karrys <[email protected]>
@gunlock
Copy link

gunlock commented Jan 21, 2024

I believe this has to do with how wsl is configured and not npm. The configuration file /etc/wsl.conf allows you to apply settings each time a subsystem is launched. See here for the settings reference.

The fix for me was to disable interop in the wsl.conf config file. After you make a change to /etc/wsl.conf, exit the subsystem and powershell instance, and relaunch. Below is my wsl.conf.

[boot]
systemd=true

[automount]
enabled=false

[interop]
enabled=false
appendWindowsPath=false

@ferronsw

This comment has been minimized.

@CalebMcNevin
Copy link

CalebMcNevin commented Mar 13, 2024

I believe this has to do with how wsl is configured and not npm. The configuration file /etc/wsl.conf allows you to apply settings each time a subsystem is launched. See here for the settings reference.

The fix for me was to disable interop in the wsl.conf config file. After you make a change to /etc/wsl.conf, exit the subsystem and powershell instance, and relaunch. Below is my wsl.conf.

[boot]
systemd=true

[automount]
enabled=false

[interop]
enabled=false
appendWindowsPath=false

I made your recommended changes and found out I was using my windows installation of node and npm because of wsl appending the windows path. I found out because my wsl installation told me I had to install npm and node when I tried to run them facepalm
Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 2 secondary priority issue Release 9.x work is associated with a specific npm 9 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants