You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Permission denied error when trying to install pnpm via Corepack as node user #1732
I maintain a suite of private org-level images which extend docker.io/_/node:{18,20}, and that's what I did.
Proper ACLs (via setfacl) would be probably be best, but unlikely that'll be available for all targets/upstreams. Unless maintainers are opposed to granting group=node write perms to /usr/local/bin, i don't think there's a simpler way.
I agree with @meyfa's PR feedback. The private org-level images i mentioned are ephemeral runtimes to generate statics (fine for my use case) but anyone using docker.io/_/node imgs for runtime workloads should be justifiably concerned.
💡 I think there may be a precedent in the homebrew ecosystem worth looking into.
💡 I don't know how/where corepack determines where to writes symlinks, but hopefully its user-aware and we might try giving $PATH precedence to $USER/bin.
Open to suggestions that wouldn't compromise root.root ownership of /usr/local/bin w/o introducing ACLs
The pnpm website https://pnpm.io/11.x/docker includes documentation on using pnpm in a Node.js Docker container.
If there are additional instructions necessary for running under the node user, it may make more sense to work with the pnpm team to get this documented in one place on their site.
The other consideration with Corepack these days is that it is no longer a central theme or prerequisite for installing pnpm (see https://pnpm.io/11.x/installation for alternatives).
Corepack is also not bundled for Node.js >=25.
For versions of Node.js <=24, Corepack remains in the Stability category Experimental, with the note "Use of the feature is not recommended in production environments."
Possibly this issue should be converted to a documentation request that could be actioned. Leaving open for possible feedback here.
I tried that and I still got the permissions error.
To describe how to do it so it works for all different combinations, means testing on Alpine & Debian, on Node.js <=24 (with Corepack pre-installed + Yarn), on Node.js 25 (Corepack not installed + Yarn) and on Node.js >=26 (Corepack & Yarn not pre-installed).
For Node.js 24, the following seems to work, although I have not tested it intensively.
FROM node:24.15.0
ENV NPM_CONFIG_PREFIX=/home/node/.npm-global
ENV PATH=$PATH:/home/node/.npm-global/bin
RUN rm -rf /usr/local/bin/yarn /usr/local/bin/yarnpkg /opt/yarn-v1.22.22
According to the PR #2485 you have submitted, it appears that you're not trying to resolve an issue with Corepack and pnpm, so I'm afraid my previous comments will not be helpful to you.
Thank you for the clarification. You are correct—the PR #2485 is not intended to address Corepack logic specifically. As your tests noted, it may not resolve those issues on its own.
However, this change provides the essential filesystem state required for any package manager to function as a non-root user when volumes are involved. In environments like Swarm or Kubernetes, mounting a volume to /home/node/node_modules will cause Docker to initialize that directory with root ownership if it is missing from the image metadata.
By pre-creating this directory with node:node ownership, we ensure that the mount point inherits the correct permissions from the image layer. This removes a foundational hurdle, ensuring that once the package manager—be it npm, Yarn, or pnpm—starts its work, it isn't immediately blocked by an EACCES error on the volume-backed destination folder.
Activity
bgondy commentedon Jun 3, 2022
For now, I've found a workaround by building my own image on top of
node:lts-alpineand runningcorepack enable(as root) during build.Then, I'm able to run
corepack prepare && corepack enableandpnpmas a non-privilegied user.nschonni commentedon Jun 3, 2022
@nodejs/corepack
eckdanny commentedon Oct 31, 2023
I think this would best solved at image build-time by adding following cmd to Dockerfile(s):
chgrp 1000 /usr/local/bin && chmod g+w /usr/local/binI maintain a suite of private org-level images which extend docker.io/_/node:{18,20}, and that's what I did.
Proper ACLs (via
setfacl) would be probably be best, but unlikely that'll be available for all targets/upstreams. Unless maintainers are opposed to granting group=node write perms to /usr/local/bin, i don't think there's a simpler way.eckdanny commentedon Oct 31, 2023
Opened #1992
eckdanny commentedon Oct 31, 2023
I agree with @meyfa's PR feedback. The private org-level images i mentioned are ephemeral runtimes to generate statics (fine for my use case) but anyone using
docker.io/_/nodeimgs for runtime workloads should be justifiably concerned.💡 I think there may be a precedent in the homebrew ecosystem worth looking into.
💡 I don't know how/where
corepackdetermines where to writes symlinks, but hopefully its user-aware and we might try giving$PATHprecedence to$USER/bin.Open to suggestions that wouldn't compromise
root.rootownership of/usr/local/binw/o introducing ACLsLaurentGoderre commentedon Nov 1, 2023
Alternatively, you can use a custom entrypoint like this:
docker run --rm -v ./entrypoint.sh:/entrypoint.sh --entrypoint /entrypoint.sh -v ./app:/home/node/app -w /home/node/app node:16 node -e 'console.log("test")'MikeMcC399 commentedon May 6, 2026
The pnpm website https://pnpm.io/11.x/docker includes documentation on using pnpm in a Node.js Docker container.
If there are additional instructions necessary for running under the
nodeuser, it may make more sense to work with the pnpm team to get this documented in one place on their site.The other consideration with Corepack these days is that it is no longer a central theme or prerequisite for installing pnpm (see https://pnpm.io/11.x/installation for alternatives).
Corepack is also not bundled for Node.js >=25.
For versions of Node.js <=24, Corepack remains in the Stability category Experimental, with the note "Use of the feature is not recommended in production environments."
Possibly this issue should be converted to a documentation request that could be actioned. Leaving open for possible feedback here.
mulder999 commentedon May 6, 2026
Ideally node team should modify Dockerfile to have:
RUN groupadd --gid 1000 node \ && useradd --uid 1000 --gid node --shell /bin/bash --create-home node \ && mkdir -p /home/node/node_modules \ && chown -R node:node /home/node/node_modulesMikeMcC399 commentedon May 6, 2026
@mulder999
I tried that and I still got the permissions error.
To describe how to do it so it works for all different combinations, means testing on Alpine & Debian, on Node.js <=24 (with Corepack pre-installed + Yarn), on Node.js 25 (Corepack not installed + Yarn) and on Node.js >=26 (Corepack & Yarn not pre-installed).
For Node.js 24, the following seems to work, although I have not tested it intensively.
then the following can be executed without error:
corepack enableMikeMcC399 commentedon May 6, 2026
@mulder999
According to the PR #2485 you have submitted, it appears that you're not trying to resolve an issue with Corepack and pnpm, so I'm afraid my previous comments will not be helpful to you.
mulder999 commentedon May 6, 2026
@MikeMcC399
Thank you for the clarification. You are correct—the PR #2485 is not intended to address Corepack logic specifically. As your tests noted, it may not resolve those issues on its own.
However, this change provides the essential filesystem state required for any package manager to function as a non-root user when volumes are involved. In environments like Swarm or Kubernetes, mounting a volume to
/home/node/node_moduleswill cause Docker to initialize that directory with root ownership if it is missing from the image metadata.By pre-creating this directory with
node:nodeownership, we ensure that the mount point inherits the correct permissions from the image layer. This removes a foundational hurdle, ensuring that once the package manager—be it npm, Yarn, or pnpm—starts its work, it isn't immediately blocked by an EACCES error on the volume-backed destination folder.S1-028: Fix corepack enable failing without sudo in a fresh Codespace
MikeMcC399 commentedon Sep 15, 2026
pnpm installation 11.x & pnpm installation 12.x no longer recommend Corepack.
pnpm installation 10.x is the last version to mention Corepack. pnpm 10.x is no longer actively maintained.