Permission issue on windows.

[hyrious]

The node.js installer on windows (*.msi) will choose C:\Program Files\nodejs by default to place node.exe, npm and corepack. As you may know this place requires admin permission, the installer will bring up the UAC and ask for it once.

At the same time, npm (and pnpm) works well here because it will install packages to %appdata%\npm, where no permission is needed.

However, corepack will install pnpm to the same place as corepack by default (which is C:\Program Files\nodejs\node_modules\corepack. This causes permission issue:

> corepack enable
Internal Error: EPERM ....

A workaround is using --install-directory to manually change the install folder to some place without permission, for example %appdata%\corepack.

I hope corepack would use places like %appdata%\corepack on windows to avoid potential EPERM issues.

(BTW, the node.js installer for other systems are likely to choose a place with high permission. It is really an issue on macOS because it generally forbids installing anything globally, in which case users must use brew to correctly install it to a safe place. However I'm not expecting you to fix the installer logic and this is out of scope.)

[ArnabXD]

I am currently facing the issue. I had to run this command as administrator and it worked. However, now, I can't make yarn working, pnpm is working fine but if I run yarn commands it shows the below error. (same with admin rights)

Internal Error: EPERM: operation not permitted, rename 'C:\Users\arnab\.node\corepack\corepack-6616-5c3b9260.66dc1' -> 'C:\Users\arnab\.node\corepack\yarn\1.22.15'
Error: EPERM: operation not permitted, rename 'C:\Users\arnab\.node\corepack\corepack-6616-5c3b9260.66dc1' -> 'C:\Users\arnab\.node\corepack\yarn\1.22.15'

Do you think my issue is related to this one or I shall create another issue (and where, here or in yarn repo).

[louisgv]

This is causing problem as well, when using corepack with pnpm link --global. It produces the following issue:

pnpm link --global
 ERROR  The CLI has no write access to the pnpm home directory at C:\Users\username\AppData\Local\pnpm
For help, run: pnpm help link

[louisgv]

NVM, I was being a dummy. I purged that pnpm directory when trying to uninstall pnpm that I had gotten previously from their install scripts, but didn't remove its cache folders. After creating the pnpm folder in that location, everything works fine now

[rikers]

Same as @ArnabXD
Any updates on this issue ? Having the same problem (win10, nvm 1.1.8, node 16.13.0 selected).
Tried to run git bash and cmd with admin rights. Tried to uncheck read only on node_modules, nvm folder, etc... without any success.

[hyrious]

@rikers Have you tried --install-directory somewhere?

From my personal experience, don't apply "run as admin" to any programming tool on Windows/macOS, it is likely to break everything. Instead find the correct way to put them at current user's scope (%appdata% is such place).

[rikers]

Yup, just like described in your initial message.
corepack disable for now, I'll try again later. Thank you anyway !

[devgioele]

Same issue here. Can't get past it

[lewis-geek]

I have the same issue, I am trying to upgrade the yarn from v1 to v3.

[lewis-geek]

I fixed the issue by installing the latest stable version node which is 16.15.0.

[aduh95]

I hope corepack would use places like %appdata%\corepack on windows to avoid potential EPERM issues.

I don't have a WIndows machine to test that, but my guess is that would indeed not trigger that EPERM error, but it also wouldn't make the scripts available on the path, so it wouldn't be much more useful. Can anyone tries this out? In any case, PRs are welcome.

[hyrious]

but it also wouldn't make the scripts available on the path

Yes, you're right. But installing to the same place as node.exe would also annoy many users when they don't run in sudo mode (they shouldn't). In fact, I was considering %appdata%\npm too because this place is added to path by node.js installer and everything installed by npm i -g <pkg> would go there. But that may cause some conflicts with the npm.

The main problem here is corepack want itself to be treated as the same level as npm. It is half true in being bundled in node.js installers, but it does not have a global path (like %appdata%\npm for npm, set by installers too) to help doing its work. In which case the builtin corepack wouldn't be much more useful than npm i -g pnpm|yarn.

So here are some answers I guess to solve this issue:

• Corepack re-uses the npm global dir (%appdata%\npm, you can get it by npm root -g) to install pnpm and generate executable shims (pnpm.cmd) there.

• Ask the node.js installer to create %appdata%\corepack and add it to path and use that place on Windows by default.

Preknowledge: Permissions of Node.js on Windows

The installer installs node.exe and npm.cmd to C:\Program Files\nodejs. This place requires high permission which generally forbids any program that not run in admin mode to create and modify files, we can call it system scope. So how does npm install -g work? It is because npm installs packages to user scope (%appdata%\npm by default) where no permission is required.

• npm i -g pnpm → C:\Program Files\nodejs\npm.cmd i -g pnpm

  What happens: npm runs in user scope, Windows forbids it edit files in C:\Program Files\, it doesn't. npm creates some files in %appdata%\npm, like %appdata%\npm\pnpm.cmd.

• pnpm i -g pkg → %appdata%\npm\pnpm.cmd i -g pkg

  What happens: pnpm runs in user scope, pnpm creates some files in its global store (%localappdata%\pnpm by default, no permission is required).

[aduh95]

Do you know if it's actually %APPDATA% or %LOCALAPPDATA%? It seems to me that it would be more logical to go with the local one, but I'm not sure.

[hyrious]

Although %localappdata% is perfered, in fact they are almost the same thing.

Let me explain the 2 folders quickly:

Windows has a tiny feature that it can sync program data automatically when it is put in %appdata%, but with some limitations: some file formats (.zip) don't get synced; total files' size bigger than some value will make the whole folder not get synced.

That's why you can see many programs occasionally using %appdata% and/or %localappdata% without fear. To some extent they are the same.

Nowadays programs won't rely on this place to sync settings, they should ask for storing data in OneDrive or require user login to save data to their database.

In fact, Windows is considering deprecate this feature in the future.

You can just treat them as 2 places that don't need admin permission to create and edit files. They are sort of ~/.local on linux.

[AndreKR]

For me the issue was that the freshly installed Node.js installation folder had explicit permissions set instead of inheriting them. Right click -> Properties -> Security -> Advanced -> Change permissions -> Enable inheritance solved the problem.

[domdomegg]

Having to set --install-directory every time as a workaround for this is quite tedious. Setting this via an environment variable in the shell (that could be set up by .zsh or .bashrc or similar) would be useful.

Would the maintainers be okay accepting a contribution adding an environment variable to this effect?

[robmunger]

I had the same issue. When I googled the error, it seemed like many people people were running "corepack enable" by running their terminal using "Run as administrator."

Not saying it's the right way to solve it, but it might be nice to have official guidance on this somewhere.

[Rounak-stha]

Ask the node.js installer to create %appdata%\corepack and add it to path and use that place on Windows by default.

how can we do this?
Did anyone solve this issue?

[PaulSeipl]

(on windows 11) I just wanted to use a yarn for a project. Following the installation guide on the yarn website, I struggled with the same permission error to enable corepack. What fixed it for me was:

1. npm install -g corepack
2. After (or before, I guess) that, delete the corepack files in C:\Program Files\nodejs (were 2 files for me).

Hope that helps :)

[tadghh]

If anyone is installing with WSL, make sure your wsl.conf contains the following. As WSL will use your Windows PATH env.

[interop]
appendWindowsPath = false