Corepack enable: permission denied on Arch Linux

[johhnry]

Hi,

I am running corepack on Node v19.9.0 and Arch Linux 6.3.1 and I can't enable it:

$ pacman -S node npm
$ corepack enable

Internal Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/pnpm.js' -> '/usr/bin/pnpm'
Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/pnpm.js' -> '/usr/bin/pnpm'

Should this be reported on some Arch Linux channel or it's a corepack issue?

Thanks

[NovaAndrom3da]

You can enable it using:

sudo corepack enable

[bjo81]

Why does it need root privileges when it should be only installed as a user?

[aduh95]

It tries to add the symlinks next to the corepack binary, which is installed somewhere the current doesn't have permissions in your case. If you know a way to make it transparent for the user, feel free to share / send a PR.

[bjo81]

It seems --install-directory fixes it.

[mikk150]

you should make symlinks to ~/.local/bin folder

[MartinX3]

If someone finds this issue, just do the following:

1. sudo npm uninstall -g yarn pnpm corepack
   • And what else packet is globally installed
2. sudo pacman -R npm
3. sudo pacman -S pnpm
4. pnpm install -g corepack
5. corepack enable
   • Remove the files in your /home/${user}/.local/share/pnpm/ directory from the error messages until it works
6. sudo pacman -R pnpm
7. pnpm install -g corepack
8. corepack enable

The last 2 steps are just to make sure.

[NovaAndrom3da]

How are you running step 7 if you've uninstalled pnpm in step 6?

[MartinX3]

Step 5 enabled the local version of it which was introduced by the global install of corepack via the system package version of pnpm.
While pnpm 8.x was still installed as a system package the terminal used the local pnpm 9.x.

It's sad that this is needed because npm install -g bla wants root while pnpm just installs it in the user directory....

[ghost]

So, fact is that corepack does not work with system-managed versions of package managers like pnpm or yarn when there is a project-specific version that does not match the one installed in the system.

As this is a very common case when dealing with projects that are being worked on by multiple people as well as CI systems, it's highly recommended to use NVM (or something similar) for each project, which then makes any changes that corepack does specific to this project only, not breaking or affecting other projects.

As a result, we add a .nvmrc to all our projects, specifying the version, e.g. (for LTS 20.x):

lts/iron

...and then you can do this to initialize everything for local development:

nvm use
corepack enable

So no dealing with directories yourself and a stable developer experience across systems.