search

coreybutler / nvm-windows

A node.js version management utility for Windows. Ironically written in Go.
MIT License
37.12k stars 3.3k forks source link

nvm root elevate.cmd: file does not exist #505

Open Poltergeisen opened 4 years ago

Poltergeisen commented 4 years ago

My Environment

I'm using NVM4W version:

1.1.7

I have already...

My issue is related to (check only those which apply):

Expected Behavior

Using nvm root C:\Git\nvm should set my nvm root to that folder. Then running nvm install 10.17.0 and nvm use 10.17.0 should work.

Actual Behavior

nvm root will set my root directory to the right place. But nvm use 10.17.0 is not working and is giving me the error exec: "C:\\Git\\nvm\\elevate.cmd": file does not exist:

Steps to reproduce the problem:

I had a previously existing version of node running. Our security team changed our virus scanners to be more restrictive in our appdata folders so I tried to move NVM into an excluded folder using nvm root C:\Git. Then I installed the version of node that I needed nvm install 10.17.0 and when trying to do nvm use 10.17.0 this happened.

Poltergeisen commented 4 years ago

Workaround:

Seems like re-installing nvm-windows into the root folder that I wanted fixed this issue. But this doesn't seem like the correct functionality.

coreybutler commented 4 years ago

When you say you had a version of Node installed, do you mean you had a prior version that was installed using nvm install or another standalone version installed? If I understand you correctly, you were expecting the versions previously installed with nvm4w to essentially be migrated to the new root directory. Is that accurate?

Poltergeisen commented 4 years ago

Yes I had Nvm installed correctly in a different root and when using Nvm root command I had expected it to migrate to the new location.

coreybutler commented 4 years ago

@Poltergeisen thanks for clarifying.

NVM4W doesn't currently move prior installations, but I think that's a reasonable expectation in this circumstance. I've marked this as an enhancement request.

capsocrates commented 4 years ago

What is the point of the nvm root command?

I have followed the same steps as Poltergeisen (albeit with a different path and versions of node). And I am seeing the same error. But I had no expectation that any existing node versions would be moved. I had no existing node versions. I did these steps

nvm root W:\nvm-root
nvm install 12.13.1
nvm install 12.14
nvm install 12.16
nvm use 12.13.1

And like Poltergeisen I got

exec: "W:\\nvm-root\\elevate.cmd": file does not exist:

But if nvm root [path] has no effect unless you install nvm into the chosen [path] in the first place, what is the point of the command?

coreybutler commented 4 years ago

@capsocrates The command is used more often in CI/CD processes where there are no existing installations. Consider running in a Docker container. Once the container boots, you can point to a mounted directory (i.e. a pseudo-dynamic directory).

After reviewing the code again, I am thinking there may be a bug (as originally described), because the elevate command really should move to the new root. I may have mistakenly jumped to a conclusion about permissions instead focusing on the file transfer itself. That would be the bug if I can confirm it. NVM4W will still not move the prior node installations by default... but having an option to do that seems like a reasonable enhancement request. I don't want to enable that by default because there are a lot of users whose environments are spread across mapped/remote drives. Moving global node_modules can mean transferring many GB across networks, which is really tough for users who aren't on the fastest networks (lots of rural school districts, municpalities, etc). Stil, I'm thinking there should be a flag so devs have a choice in the matter.

capsocrates commented 4 years ago

That use case makes sense and would explain why the current behavior is considered to "work."

For my part I don't care about transferring the existing installs as part of this command (though I'm sure it would be a nice option to have in a flag). But it would be nice if it worked as described :)

bl9l commented 3 years ago

Hi guys. The solution for those who face the same problem.

Copy these files image

Into new root directory manually image

Symionow commented 3 years ago

I agree, this is a bug. bl9l's solution works. I wanted my nvm4w install location and the root for my node installs to be different. I assumed that is the point of the root command. However, the files above also need to be where the root directory is set and the workaround is working but not expected.

LesterReddy commented 3 years ago

When installing nvm - set in installation to "c:\path}" ; nvm root "c:\path" mvm install version nb c:\path => your choice

userInner commented 2 years ago

我也遇到了同样的问题。尝试使用了1.19版本，完美的解决了此问题 https://github.com/coreybutler/nvm-windows/releases

mahede182 commented 1 year ago

Try this.

afsharm commented 1 year ago

Hi guys. The solution for those who face the same problem.

Copy these files image

Into new root directory manually image

In my case I copied it from C:\Program Files\nvm as I originally installed nvm in this path.

olallier commented 1 year ago

It is a bug of pointing to the correct folder in the code. The manual installation explicitly states those files are installed in %NVM_HOME% while the node.js versions are stored in %NVM_SYMLINK%. when we run "nvm use (folder name of node.js)", we have the error " file does not exist:" because it is looking for elevate.cmd in NVM_SYMLINK and NOT where it is supposed to look for, in NVM_HOME. So it is a bug.

seraph-b commented 9 months ago

Facing the same problem after installing through scoop. Changing the root path does not help.

te1 commented 9 months ago

Because this is the first thing that shows up on Google: I updated nvm to version 1.1.12 using scoop and now have this error whenever I nvm use <something>: exec: "elevate.cmd": executable file not found in %PATH%:

I reverted back to nvm 1.1.11 and it works fine again. scoop reset nvm@1.1.11

Mentioning #1069 for reference.

Looking at scoop nothing unexpected changed https://github.com/ScoopInstaller/Main/commit/a09fed86cdbf265649b96a305116bacd6f1a3f5e

Comparing the contents of 1.1.11/nvm-noinstall.zip and 1.1.12/nvm-noinstall.zip all the files seem to be present and only the nvm.exe has changed.

nickolay commented 8 months ago

The scoop issue about nvm-windows 1.1.12 not working is here: https://github.com/ScoopInstaller/Main/issues/5311

mar10br0 commented 8 months ago

The above solutions of copying the nvm application from the NVM_HOME into the NVM_ROOT folder is not working for me. My usecase may be slightly different (not moving a working installation to a different folder, but rather using nvm to manage node-version(s) without administrative rights: nvm is offered as an approved software and installed through the company's software distribution. As a user (without admin-rights), I then start with nvm root %APPDATA%\nvm (where I have write-permissions to install the managed node-versions) Next nvm install 18.19.0 (my team's selected and tested node-version) works just fine (it installs a folder for node v18.19.0). However, running nvm use 18.19.0 (very first time running the use command on my system) it fails with the missing elevate.cmd Applying the trick to copy the nvm application from the installed location in Program Files (x86), no longer complains about missing elevate, but now the windows admin-permission popup shows (presumably to create/redirect the symlink?). And that's where I'm truly stuck, as I don't have (nor be allowed to have) local admin permissions.

As @olallier mentioned, I believe the bug to be confusing NVM_HOME and NVM_ROOT. (hoping that the installed location of elevate.cmd can elevate the permissions of nvm to manage the sym-link.

PS: the software distribution in our organisation is not giving any control over the installation of nvm itself.

coreybutler commented 8 months ago

@mar10br0 I hate to say it, but I don't think there is anything you can do other than petition the powers that be to grant you more capabilities. nvm use establishes a symlink to the version you want to use. Windows does not grant symlink privileges to users by default. You either have to be an admin (which is the only way on old versions of Windows) or you must be explicitly granted permission to manage symlinks. Microsoft recognized this as a pain point several years ago and introduced "Developer Mode". By enabling this, you'll have the ability to manage symlinks without requiring full admin privileges. Your org will probably have to enable this for you though, given the locked down nature of the environment you're working in.

See https://github.com/coreybutler/nvm-windows/wiki/Common-Issues#permissions-exit-1-exit-5-access-denied-exit-145.

Also, see Runtime, which is the version manager we're building for enterprise/corporate use.

mar10br0 commented 8 months ago

Thanks @coreybutler, I'll dive into those resources 👍

IvanBanifatsyeu commented 2 weeks ago

Try this.

  • [ ] Open the Command Prompt as an administrator. To do this, right-click on the Start menu and select "Command Prompt (Admin)".
  • [ ] Type the following command and press Enter: sfc /scannow

It helped me‼!!!!!!!!!!!!!!!