- Permissions (Exit 1, Exit 5, Access Denied, Exit 145)
- Exit 145 or "The process cannot access the file because it is being used by another process."
- Spaces in pathnames/installation root
- Uninstall Existing Node Installation Before Installing NVM4W
- Cannot install npm?
- Upgrading npm
- How do I use yarn with nvm-windows?
- Special Terminal Shells
- "The system cannot find the path specified"
- Delayed Changes
- Why isn't .nvmrc supported? Why aren't some nvm for macOS/Linux features supported?
- How can I use two different versions of Node.js at the same time?
Clone this wiki locally
There are a couple of common issues folks run into. I try to fix them/accept PR's when possible, but there are a few things I've simply held off on. Why? I'm building a new version that's cross-platform compatible, and I'm trying to get infrastructure setup for things like auto-update.
In the meantime, here are some common issues and workarounds:
By popular demand, NVM4W 1.1.8 introduced support for developer mode. In other words, you won't receive a UAC prompt to elevate permissions if it's not explicitly necessary. If you prefer to be prompted for UAC rights, use NVM4W 1.1.7.
If you do not run the nvm.exe file with appropriate permissions, you may receive an
exit 5, or
Access Denied error. These come straight from Windows, indicating the user account does not have permissions to do what you're trying to do.
The most common permission issue has to do with creating symlinks. NVM4W uses symlinks (
mklink is used in
nvm use) to redirect the Node installation path to the appropriate installation. Windows requires elevated administrative privileges to create symlinks, but developer mode eases these restrictions.
It's best to enable developer mode on Windows 10, which will grant your user account slightly elevated permissions. See how to Enable Your Device for Development
The second most common permission issue is trying to use a protected directory for storing Node installations. Windows requires administrative privileges to write to
C:\Program Files. Many users want to install different versions of Node to this directory, but this forces NVM4W to create download (write) Node/npm to a protected directory. It's typically simpler to store Node installations in an alternative directory, such as
C:\nvm4w, or on another drive such as
Several people have complained about protected directories, and I'm sorry... but I'm not the person to talk to about that. Your best bet is to reach out to Microsoft, because it's an operating system requirement. Every program has to deal with this. Remember that NVM4W is basically an installer, so it needs installer-like permissions.
The third most common permission issue is conflicting permissions. Many users fail to uninstall old versions of Node before installing NVM4W. The NVM for Windows installer attempts to migrate existing Node installations into NVM4W, but old installations can prevent this. The original Node installation is often installed with different user permissions, making it impossible for NVM4W to uninstall it. This results in two conflicting installations of Node. Node can physically exist in more than one location, but only one unscoped (i.e. globally available) version can be used at a time. This is why the README recommends uninstalling previous versions of Node before installing NVM4W.
The exit 145: The directory is not empty and exit 32: The process cannot access the file because it is being used by another process. errors are passed through from Windows itself. The errors are self-explanatory. Most users encounter one or the other because they're trying to change the Node.js version from within the directory of the Node installation. For example, if your root is
C:\nvm4w and you install Node 16.9.1, it will be available at
C:\nvm4w\v16.9.1. If you navigate to
C:\nvm4w\v16.9.1 in the terminal/powershell or keep it open in Windows explorer, Windows will lock the directory (because it is open). If you try to run
nvm use 16.11.0 (another version of Node), it will not be able to remove the original symlink, because it is locked. The easiest way to bypass this is to navigate to another directory (i.e.
cd C:\ before running
nvm use x.x.x).
An active Node process can also cause these problems. If an active process is running when attempting to
nvm use a new version, it will fail. For example, if you run
node mywebserver.js, a live process (using node.exe) is created. If you try to switch versions without shutting down the server, Windows will warn you the node.exe process is currently in use. It's kind of like saying "you can't uninstall this while you're still using it".
Some versions (particularly 1.1.8 and nvm-update.exe) are not code-signed. Some antivirus services use machine learning algorithms to determine threats on unsigned executables. If your antivirus recognizes a threat with a name like
.ML, it indicates a machine learning algorithm is making a guess about the application. These are not the same as known virus signatures. NVM4W has no malicious code, but version 1.1.8 is not code signed. See the release notes under the
WARNING section for details.
After an undetermined number of installations, Microsoft Defender and Microsoft SmartScreen will trust the application. However; there is no way of knowing what that number is. You may need to make an exception in your antivirus for NVM4W.
If you cannot download a release, you may need to temporarily disable realtime protection. Always remember to turn this back on after your download completes!
Take note that running nvm-update.exe will download nvm-setup.zip, then extract all of the relevant files to update your installation and cleanup when done. You may need to temporarily disable Windows Defender realtime protection while doing this as well.
This issue should be resolved as of version 1.1.8.
If you are working with an older version...
Some environments aren't picking up on space-escaping. If you're having problems with Windows recognizing NVM4W, try installing it on a path with no spaces, like
C:\nvm. The same situation is relevant for the symlink path, so you may want to use something other than
C:\Program Files\nodejs for the symlink root.
If you're unsure whether you're impacted by this, try using the pathfinder troubleshooting utility.
The installer attempts to take over any existing installations of Node for you, but the process can be more complex than it appears. The most common source of problems is when users install NVM4W using a different account or with different permissions than those which are used to install prior versions. The bottom line is permissions for installing/uninstalling applications are quite strict and NVM4W may not be able to absorb prior installations.
The best course of action is to uninstall prior versions of Node before installing NVM4W. In some cases, you can uninstall prior versions afterwards, but the only reliable way I've consistently seen it work is by removing prior versions before installing NVM4W.
Depending on which version of Windows you have and how your desktop is setup, there can be issues with modifying a path in the registry for an application you don't control, user accounts associated with an existing app, roaming profiles, etc.
I only have a couple of versions of Windows to test on, but it's far from the complete Microsoft Windows catalog. Again, the one consistent solution that always seems to work is uninstalling Node before installing NVM4W.
Several users have reported issues installing versions of Node.js that ship with npm 6.14.7, such as Node 14.19.x (except 14.19.1, which uses npm 6.14.16). There has been an upstream problem with the npm download. Please see issue #799 for details.
Make sure you are using NVM for Windows 1.1.7 or greater. Older versions of NVM4W use the old npm github repository (which only has older versions).
Some users attempt to install old versions of npm for testing. Be aware that newer versions of npm won't necessarily work on older versions of Node.js. Older versions of npm won't necessarily work on newer versions of Node.js. NVM4W does not manage npm, it merely installs it. It is up to developers to assure the versions of Node/npm they're using are compatible.
Some users experience the following error:
npm ERR! path C:\Program Files\nodejs\npm.cmd npm ERR! code EEXIST npm ERR! Refusing to delete C:\Program Files\nodejs\npm.cmd: is outside C:\Program Files\nodejs\node_modules\npm and not a link npm ERR! File exists: C:\Program Files\nodejs\npm.cmd npm ERR! Move it away, and try again.
The best bet is to use this solution, https://github.com/felixrieseberg/npm-windows-upgrade
Some older versions of npm have hard coded paths that prevent automatic removal. Several users have found manual workarounds that work well.
Yarn is an npm package.
npm install -g yarn will install it. Remember, yarn is not officially released with Node.js, so this will need to be repeated for each new installation of Node.js.
Per issue #417, some shells do not respect UAC prompts (i.e. requesting administrator permissions). NVM for Windows cannot control how terminals work, and due to the sheer number of custom terminals available (mingw, cmder, ConEmu, cygwin, hyper, etc), only official Windows terminals are supported (CMD and PowerShell). Bash for Windows support may come in the future.
If you are using a special terminal that does not respect UAC requests, you may see errors like this:
If Windows cannot find NVM, try restarting the terminal/powershell first. If the issue persists, it may be due to a misconfiguration in the terminal. See this stackoverflow answer for a possible fix.
nvm use x.x.x is called, NVM for Windows updates a symlink pointing to the
x.x.x installation root. This can take a few milliseconds on the operating system, meaning the change is not immediately available. Some users have run into problems with this in CI environments with code like:
nvm use lts npm i -g yarn
In some (not all) environments, the
nvm use lts background process has not completed before the
npm i -g yarn command is executed, causing it to fail. If you encounter this issue, add a slight delay:
nvm use lts start-sleep -seconds 1 npm i -g yarn
.nvmrc file is a concept that's a part of the nvm project. This project is and always has been different from the original nvm project. This project does not strive to be a mirror of the original nvm project.
The primary reason why
.nvmrc files aren't supported is due to a key difference in the design philosophy. The nvm project uses a shim to access Node.js, whereas this project does not.
A shim is an executable/command that relays commands to another executable. Shims can reconstruct the command, which includes reading a config file (i.e.
.nvmrc for a version, then constructing the command using the path to the nvmrc-specified version of Node.
Historically, shims cause edge cases on Windows systems. It is often deemed unreliable. The most common issue is failure to relay user and directory context directly to the other executable. For example, the current working directory of the shim is recognized instead of the Node executable, or the owner of the shim would differ from the user executing the script. It requires some scripts to be aware they're operating in the context of a shim instead of directly with Node.js. See the edge cases in the version management workgroup. The bottom line is calling a shim is not the same as calling
NVM for Window's was designed to use Node.js executables directly. This is why symlinks are used instead of a shim. Philosophically, it aligns with how Node (or any runtime) is used without a version manager.
A note on the author's intentions:
Even though the name of this project is similar to an earlier project, they are not the same. I have no intention of adding
.nvmrc support or mirroring nvm's every move (nor the other way around).
The popularity of
.nvmrc indicates there is a desire for more automated runtime/environment management. I feel this myself. However; the scope of this project has always been version management, not runtime or environment management. I've spent considerable time thinking about these concepts though. I believe runtime management is a valid community need/desire, but I also feel the .nvmrc concept only addresses a small part of it.
Instead of breaking the design scope of this project, I've chosen to work on a successor: rt, described in "the future of this project". By harnessing the lessons learned from this project (which are plentiful), we're better equipped to build a better/unified overall solution for all users.
NVM4W is not designed to manage more than one version of Node.js at the same time, but it is still possible to run more than one version at the same time. If you need to run more than one version of Node at the same time, use the absolute path of the version you want. For example, if your NVM4W installation looks like this:
It is possible to run a script directly, like this:
In other words, run
C:\path\to\version\node.exe myscript.js instead of just
The same is possible with npm: