nvm-windows
nvm-windows copied to clipboard
coreybutler
The installer installs "as administrator", not as the user invoking the installer
The installer currently tries to install nvm to the user account that was used to grant administrator access, instead of the user that invoked the installer. For example, if your user account is set to "standard user" (as it always should be, but never is on a standard single user windows install) and you have the built-in administrator account enabled for UAC purposes, then nvm will try to install to Users\Administrator\AppData\Roaming\nvm instead of the actual user's roaming profile location.
To add to the above, I made nvm install into C:\Users\Public\nvm instead, and a new cmd instance shows an env list including
NVM_HOME=C:\Users\Public\nvm
NVM_SYMLINK=C:\Program Files\nodejs
OneDrive=C:\Users\Mike\OneDrive
OS=Windows_NT
PATH=/c/Windows/system32:/c/Windows:......:%NVM_HOME%:%NVM_SYMLINK%
yet running nvm fails:
C:\Windows\System32>nvm
'nvm' is not recognized as an internal or external command,
operable program or batch file.
To add to the above, I made nvm install into
C:\Users\Public\nvminstead, and a newcmdinstance shows anenvlist includingNVM_HOME=C:\Users\Public\nvm NVM_SYMLINK=C:\Program Files\nodejs OneDrive=C:\Users\Mike\OneDrive OS=Windows_NT PATH=/c/Windows/system32:/c/Windows:......:%NVM_HOME%:%NVM_SYMLINK%yet running
nvmfails:C:\Windows\System32>nvm 'nvm' is not recognized as an internal or external command, operable program or batch file.
Just experienced the same behaviour, even though it had worked one reboot earlier. I suspect it being a Windows bug. The nvm variables in PATH should be resolved instead of having the variable names %NVM_HOME% and %NVM_SYMLINK% in it.
After editing/saving the PATH variable via Windows UI and reopening a command prompt, the PATH env variable was resolved completely and running nvm (and also node / yarn) worked again.
In my case, before it stopped working I uninstalled an application which probably changed the PATH variable, so maybe that caused this bug or at least weird behaviour of not resolving the nvm variables within the PATH declaration.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@coreybutler this feels like it's worth not having go stale, given how key of a component UAC is on Windows.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Again, commenting to get eyes on this, because windows installation needs to use the right user accounts for the various actions (so, ping @coreybutler again).
I had the same problem, installed under an admin account.
This defaults to appdata/
To fix Install nvm under a public path for example C:\Users\Public\nvm Add path variables NVM_HOME and NVM_SYMLINK to system. Now u can use nvm, node. To switch to another node version use an elevated powershell
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Note that's those steps are a workaround not, not an actual fix to what the installer does (which can negotiate permissions with Windows correctly if properly set up).
@coreybutler hopefully this can still get fixed rather than getting closed by a bot without ever having been triaged =)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue was closed because it has been stalled for 7 days with no activity.
Hi. This is still a problem, especially for developers using elevated rights when needed and not all the time.
If you install as the admin user, then you need to specify the appropriate install directory for your user, or a common directory (like C:\nvm-windows), instead of the default.
For organizations that need to install this in an automated fashion, I recommend following the manual installation guide to produce scripts.
Being able to install for a different user seems like a nice feature, but I'm not going to have time to do it. I would accept a PR for this.
I forgot about an old PR for this (#459), so I'll look into it for the next release.
Note that there's "being the admin user, and installing stuff" and there's the "run as administrator" option that windows offers every user for every executable, in order to temporarily elevate permissions on a per-run basis, commonly used (and often automatically triggered) for installs. No manual specifying of the user dir should be needed there: the standard windows variables should still be those for the logged in user, not the administrator account.
Note that there's "being the admin user, and installing stuff" and there's the "run as administrator" option that windows offers every user for every executable, in order to temporarily elevate permissions on a per-run basis, commonly used (and often automatically triggered) for installs. No manual specifying of the user dir should be needed there: the standard windows variables should still be those for the logged in user, not the administrator account.
Exactly. This ticket is not about being able to install under different user, but the bug which changes home folder from the invoking user, to the admin user.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
probably want to configure the bot to not flag issues labeled with "help wanted" as stale. Those should just stay open for whoever wants to help out, not get auto-closed.
I'm not able to get this working on my system, and I'm wondering if this could have something to do with it. I can install things as Administrator, but I think the installer is from my account, which isn't the same as Administrator. I've tried various ways of installing, I've changed the file folders. The installer ignores any suggestions for creating a file folder to install to. It will accept the locations you put during the installation wizard, but at the end it ignores the locations and just stores in the same place inside the nvm folder. I tried making a folder to match the spot listed in examples, and during installation, it will actually delete the folder and not replace it with a new one. If I put the folder back afterwards, it won't use the folder to store node versions in. It always installs to itself inside the nvm folder, and it won't recognize the location even if I set the path manually to match it in the settings file and the environment variables. I've also tried going through to look for any other installations, I don't have any.
@erikkai - are you saying the installer isn't installing NVM4W to the directory you specify in the install wizard, or are you saying Node.js installations aren't going to the directory you expect?
Node.js installations are always physically stored in the NVM root. You'll see folders like v20.0.0 inside the NVM root. You can configure the NVM4W installation root directory, but you cannot configure a separate location for the physical Node.js installations. When you run nvm use, it updates the NVM_SYMLINK directory to point to <NVM4W Installation Root>/vX.X.X.
Why does the installer elevate at all? If I run the installer, I have to enter my Administrator credentials. If it's meant to be installed in appdata, the installer should run with my normal user account. I know that NVM4W itself has to elevate later but I see no reason for the installer.
@fishbone1 It doesn't have to be installed to appdata. If it is installed in a protected directory, like C:\Program Files, Windows requires elevation. Additionally, it writes a small bit of data to the registry.