The installer installs "as administrator", not as the user invoking the installer

[Pomax]

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.

[Pomax]

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.

[mario-neuhold]

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.

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.

[Pomax]

@coreybutler this feels like it's worth not having go stale, given how key of a component UAC is on Windows.

[Pomax]

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

[sweco-nlmdek]

I had the same problem, installed under an admin account.
This defaults to appdata//Roaming/nvm. under a non admin account this path is not accessible.
Also the paths variables are installed under a user, and not system. therefor NVM_HOME and NVM_SYMLINK is not found.

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

[Pomax]

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 =)

[ViliusS]

ping

[ViliusS]

ping

[nuvan]

Hi. This is still a problem, especially for developers using elevated rights when needed and not all the time.

[coreybutler]

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.

[coreybutler]

I forgot about an old PR for this (#459), so I'll look into it for the next release.

[Pomax]

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.

[ViliusS]

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.

[github-actions]

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.

[Pomax]

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.

[coreybutler]

@Pomax I thought I had 😳 . Will look into it.

[erikkai]

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.

[coreybutler]

@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.

[fishbone1]

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.

[coreybutler]

@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.

[yuvigrg]

my case scenerio is i have an admin account and a normal account. i have to use admin account when installing software. the nvm is installed on
C:\Users\xxx\AppData\Roaming. after numerous unsuccesful installs, i found that the NVM_HOME and NVM_SYMLINK were not being added on path. I had to manually add them following this guide
https://github.com/coreybutler/nvm-windows/wiki#manual-installation

i am using
nvm installer 1.1.12
OS - Version 10.0.22621 Build 22621

now I can use node in a non elevated terminals

[mklemarczyk]

@coreybutler What about adding some options in the installer with option to install for local user only or for the workstation ?
It is being done more and more often in installer, than the installer might suggest the best fitting paths for given use.

Alternatevly there is option to relese two installers like for Visual Studio code, you will find that there is a special one that does not require any permission and any user can use it. There is second one that performs the system installation for all users.
The other difference in local user install is that the installer should allow other users to perform the local install.

I can investigate the posibilities and come back with PR if you are willing to integrate it ;)

[coreybutler]

@mklemarczyk Similar to the other thread about junctions, I'm hesitant to add anything else to this project due to the feature freeze and maintenance ramifications.

We built a per-user installer for Runtime. The Windows version will be delivered as an MSI, allowing organizations to customize paths when the defaults don't fit their use case.

This will ultimately provide the desired user experience at the heart of this issue.

[Pomax]

that's fair enough, I will close this issue then because if it's cutting into your work on Runtime that's to no one's benefit. I'd also mention that if it were me, I'd archive this repo after updating the readme to state this project is deprecated and to go use Runtime instead, with a link to the repo as well as a direct link to the issues in the same paragraph.

(The nice thing about archiving being that all the data's still there, nothing gets deleted, the project's just locked)

[coreybutler]

@Pomax that's the plan! I'm not going to immediately deprecate the project... a phased deprecation seems more appropriate. There will still be a few maintenance releases, but naturally we'll encourage shifting to Runtime. Realistically, it will take time for people to get accustomed to a new tool, no matter how similar or easy the upgrade path is... so yes, this will remain as a public archive when the time comes to stop work on it altogether.

[Pomax]

Note that archiving and deprecating aren't the same though - archived just means "this is done, feel free to keep using it but we consider it feature complete and we're not going to work on it anymore" rather than deprecation's "you should stop using this" =)

(so I'd recommend archiving the repo but not using something like npm deprecate)

[coreybutler]

@Pomax semantics, but I hear you :-)

I feel NVM4W is feature complete as a version switcher/manager. From this perspective, archiving the project makes sense. Some people would disagree with me because other version managers have different features NVM4W lacks. From my perspective, most of these desires relate to environment management, which is a whole new level of "complicated" compared to basic version management. I've always considered that a separate product with a different scope. It's a natural evolution, which is where we're headed... but version management is only a subset of that.

Deprecation is still applicable, for security reasons. Ultimately, there will be individual users who want to remain on NVM4W due to familiarity. There will be an upgrade path to Runtime, and we really think people ought to switch to it (and we think most will want to)... but are we going to force them? No. I feel very differently about enterprise users though. I do believe they need to upgrade. Enterprise environments are very different, with stringent requirements an environment manager can sustain but a version manager cannot. To meet the ongoing needs of enterprise/organizational use, yes, people should start using Runtime as soon as it is released.

Bottom line: archival makes sense as well as circumstantial deprecation. That may eventually lead to full deprecation. Time will tell.