Permission denied error when trying to install pnpm via Corepack as node user

[bgondy]

Environment

• Node.js Version: 16.15.0
• Image Tag: lts-alpine

Expected Behavior

I should be able to install pnpm using Corepack as a non-privilegied user.

Current Behavior

When I try to install pnpm via Corepack (corepack enable) as non-privilegied user (-u node), I get the following error:

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

Running corepack enable as root work as expected.

docker run -it -v $(pwd):/app node:lts-alpine /bin/sh

Steps to Reproduce

1. Create an empty project with the following package.json. The packageManager property is important here.

   {
       "name": "docker-node-pnpm",
       "version": "1.0.0",
       "private": true,
       "packageManager": "pnpm@7.1.7"
   }

2. Run the container as a non-privilegied user: docker run -it -v $(pwd):/app -u node node:lts-alpine /bin/sh

3. cd /app

4. corepack enable <-- This should fail

5. corepack prepare

6. pnpm install

[bgondy]

For now, I've found a workaround by building my own image on top of node:lts-alpine and running corepack enable (as root) during build.

FROM node:lts-alpine

RUN corepack enable

Then, I'm able to run corepack prepare && corepack enable and pnpm as a non-privilegied user.

[nschonni]

@nodejs/corepack

[eckdanny]

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/bin

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.

[eckdanny]

Opened #1992

[eckdanny]

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

[LaurentGoderre]

Alternatively, you can use a custom entrypoint like this:

#!/usr/bin/env bash
corepack enable

su - node && corepack prepare && pnpm install && $@

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]

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.

[mulder999]

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_modules

[MikeMcC399]

@mulder999

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_modules

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

docker run -it --rm -u node corepack-test sh

then the following can be executed without error:

corepack enable

[MikeMcC399]

@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]

@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_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.