fails to invoke npm when used in run-scripts

Environment

Platform: MacOS
Docker Version: 20.10.16
Node.js Version: 16.15.1
Image Tag: node:16.15.1-alpine

Expected Behavior

Given the following package.json

{
  "name": "test",
  "scripts": {
    "ver": "npm --version"
  },
  "devDependencies": {
    "cowsay": "^1.5.0"
  }
}

$ npm run ver

> ver
> npm --version

8.12.1

The same behavior should be replicated within a container runtime

Current Behavior

When running within a container runtime, npm fails and returns 243 exit code

$ docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:16.15.1-alpine run ver

> ver
> npm --version


npm notice
npm notice New minor version of npm available! 8.11.0 -> 8.12.1
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v8.12.1>
npm notice Run `npm install -g npm@8.12.1` to update!
npm notice

$ echo $?
243

When using a different image, it works as expected

$ docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:14-alpine run ver

> test@ ver /app
> npm --version

6.14.17

It works on on some images (note the --user node:node option)

$ docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:16.15.0-alpine3.15@sha256:bb776153f81d6e931211e3cadd7eef92c811e7086993b685d1f40242d486b9bb run ver

> ver
> npm --version

8.5.5
npm notice
npm notice New minor version of npm available! 8.5.5 -> 8.12.1
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v8.12.1>
npm notice Run `npm install -g npm@8.12.1` to update!
npm notice

$ docker run --rm -v $PWD:/app --workdir /app --entrypoint npm --user node:node node:18-alpine run ver

> ver
> npm --version

8.11.0

when the node user is used, then there a permission issue when mount volumes are used.

$ docker run --rm -it -v $PWD:/src -v node_modules:/src/node_modules --workdir /src --user node:node --entrypoint /bin/sh node:lts-alpine -c 'npm install && npm run ver'
npm ERR! code EACCES
npm ERR! syscall mkdir
npm ERR! path /src/node_modules/ansi-regex
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, mkdir '/src/node_modules/ansi-regex'
npm ERR!  [Error: EACCES: permission denied, mkdir '/src/node_modules/ansi-regex'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/src/node_modules/ansi-regex'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/node/.npm/_logs/2022-06-09T07_10_27_665Z-debug-0.log

$ docker run --rm -it -v $PWD:/src -v node_modules:/src/node_modules --workdir /src --user root:root --entrypoint /bin/sh node:lts-alpine -c 'npm install && npm run ver'

added 41 packages, and audited 42 packages in 2s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm notice
npm notice New minor version of npm available! 8.11.0 -> 8.12.1
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.12.1
npm notice Run npm install -g npm@8.12.1 to update!
npm notice

> ver
> npm --version

Steps to Reproduce

Use the package.json configuration above and repeat the commands in this post.

Seeing the same issue in my Jenkins pipeline with node:16.15-alpine3.15. I cannot reproduce the issue locally though.

we are facing the same issue.

on k8s we're setting the pod security context to run with an arbitrary user id, after deleting this in the config the pod starts again.

we are setting the tag / sha of images to node:16.14 for now, to keep our pod settings.

also see npm/cli#4996

Also seeing this issue, hard coding to node:16.15.0-alpine in the meantime.

we are facing the same issue.

on k8s we're setting the pod security context to run with an arbitrary user id, after deleting this in the config the pod starts again.

we are setting the tag / sha of images to node:16.14 for now, to keep our pod settings.

also see npm/cli#4996

This is our circumstance as well. We use an arbitrary non-privileged user ID which worked fine until v16.15.1.

@nschonni

Maybe @nschonni knows what's up

Facing the same issue.

Was using node:16-slim which brought in version 16.15.1-slim. So reverted back to previous minor version as a temporary fix by specifying node:16.14-slim

Facing the same issue.

Was using node:16-slim which brought in version 16.15.1-slim. So reverted back to previous minor version as a temporary fix by specifying node:16.14-slim

For us this was specifically with the 16.15.1 patch release, 16.15.0 works in our case.

I'm having a similar issue. We're seeing it when we try to do an npm install from the Docker command, when we set the user for the container. If you set the node cache to a non-existent path, it seems to work.

Can replicate it using a simple package.json file with a dependency. This example assumes the package.json is owned by user 1001.

> docker run --rm -it -v $PWD:/app -u=1001 -w /app node:16.15.1-alpine sh -c 'npm i'
> echo $?
243

When setting --cache=nope, the install works:

> docker run --rm -it -v $PWD:/app -u=1001 -w /app node:16.15.1-alpine sh -c 'npm i --cache=nope'
... added some packages
> echo $?
0

EDIT:

It appears (at least in part) to do with the home directory for the user it's running as. Running as user 1001 (which doesn't exist in the container) fails to run npm at all:

> docker run --rm -it -u 1001 node:16.15.1-alpine sh
> npm -v

> echo $?
243

If you add the user with that ID, it creates the home directory and works:

> docker run --rm -it node:16.15.1-alpine sh
> adduser -D -u 1001 test
> su test
> npm -v
8.11.0
> echo $?
0

If you add the user with that ID, but without the home directory, you get the same error:

> docker run --rm -it node:16.15.1-alpine sh
> adduser -D -H -u 1001 test
> su test
> npm -v

> echo $?
243

Hardcode node version to 16.15.0 in tests

It seems that npm exec and other command-invoking command such as npx executes commands as the owner of the current working directory, regardless of the user that these commands executed.

user:~$ npm exec -- /usr/bin/whoami
user
user:~$ sudo npm exec -- /usr/bin/whoami
user
user:~$ cd /
user:/$ npm exec -- /usr/bin/whoami
user
user:/$ sudo npm exec -- /usr/bin/whoami
root

Edit: here overrides uid if root

https://github.com/npm/cli/blob/9f94049f058687b916da726ea625b5fa68d0829d/node_modules/%40npmcli/promise-spawn/lib/index.js#L13

Probably the same problem with docker image of 18.2-alpine, npm version 8.9.0.

{
  "name": "test-app",
  "version": "0.0.0",
  "scripts": {
    "test": "npm --version"
  },
  ...
}

The issue here seems npm doesnt want to run as root. Example when container is run as root and when switched to user node using su:

1aae0dcc8624:/workspace/app# whoami
root
1aae0dcc8624:/workspace/app# npm run test

> test-app@0.0.0 test
> npm --version


1aae0dcc8624:/workspace/app# su node
1aae0dcc8624:/workspace/app$ whoami
node
1aae0dcc8624:/workspace/app$ npm run test

> test-app@0.0.0 test
> npm --version

8.9.0
1aae0dcc8624:/workspace/app$

Running the container as node fixes the issue.

@SmallhillCZ

@SmallhillCZ

Running the container as node fixes the issue.

Not fully correct. It depends whether you are using the container in conjunction with mount/data volumes as node_modules directory. When it is used, the user must be root in most cases (depends on the inner implementation of how mount volumes work across different operating systems)

The issue exists in other images too and seems like the maintainers/contributors are not a part of the thread discussion.

Do we know what is the cause for the issue?
Is anyone working on a fix?

@foolioo
NPM overrides uid if current user is root in the following line.

https://github.com/npm/cli/blob/9f94049f058687b916da726ea625b5fa68d0829d/node_modules/%40npmcli/promise-spawn/lib/index.js#L13

This was removed before, but reintroduced now.

npm/promise-spawn#6

@yuki-js

@yuki-js Thanks. Do you have any suggestion how to resolve the issue?

Temporary fix for nodejs/docker-node#1734

The simple solution is to change the nodejs version. I was facing the same issue, i fixed it by changing node version from 16 to 14 and this worked

Simply adding user: node to my docker-compose.yaml fixed it in my case...

This is still happening on 16.17.1 docker images.

Actually, this is not only an issue with run-scripts. node:16-alpine docker image is completely broken as a base build image in these cases:

Environments where image is run by root user.
Read-only root filesystem environments, e.g., Kubernetes container with readOnlyRootFilesystem: true.
Environments where one could not modify a running user, e.g., on Jenkins pipelines which by default run under Jenkins user and the UID is most probably not the same as UID 1000 which is used in the image.

The source of these issues is that npm_config_prefix is set to /usr/local and npm_config_userconfig is not set at all, so NPM is trying to use HOME folder which in the docker image is set to /. Again, that folder is not writable by any of the users except root, but remember, NPM ignores root user due to https://github.com/npm/cli/blob/37bf6d31bd2f68e661928744833b57dcabbb0d1a/node_modules/@npmcli/promise-spawn/lib/index.js#L13

The only way I found to fix this on Jenkins is set NPM_CONFIG_CACHE to something like /tmp/jenkins/.npm. GitLab/GitHub runners can be fixed in similar manner.

I guess the final fix should be to create .npm cache folder somewhere writable by any user on the docker image, so at least it works by default on CI pipelines. Maybe create some kind of documented folder specified via npm_config_userconfig so anyone can map it and modify the behaviour of a running user.

P.S. Why NPM tries to spawn a process according to permission on current folder in case it is run by the root user is still a mistery to me. It goes against all commons. Programs should not modify running user.

https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#non-root-user

https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#non-root-user

Yes, I saw that, but this assumes that Docker image can be modified. In a lot of cases, you cannot do that. Free GitLab runners are one such example.

I confirm, the issue is still exist in latest 16.17.1 docker images when we run them on Openshift/Kubernetes.
We need to run latest node 16 version images because of security policy we have!
Node 16.15.0 Docker image worked before for us just fine. Now something is changed/broken on later releases.

Seems issue is so old already on nowbody cares to fix it 👎

cares ro fix it

cares to fix it

Fix error 243 in GitHub Actions

So I encountered what I believe is this problem (although not sure of the fix yet). Essentially experiencing the exact same behavior. It's probably the most confounding problem I've ever had to troubleshoot because (and I mean this sincerely) "the compose-up command was working with the image last week, and not today", with literally nothing changed in the dockerfile or compose file .. I started trying to re-build the image as fresh as possible (--no-cache, etc) .. and then just started deleting images off docker desktop as verbose build logging still showed a few layers being "CACHED" but I might misunderstand that as it was referencing the node:18.13-alpine image itself.
Anyway.. I was able to get it working both inside the docker desktop GUI (play button/no args) (working btw for us means that NestJS runs the 'start --watch' command (via 'npm run start:dev') starting a NestJS dev server). And then (again without changing a single thing except the final CMD to be "bin/sh" instead of what it was (working with) last week which was ["npm", "run", "start:dev" ] then running 'npm install' again which updated 0 things (as there is already that command further up in the dockerfile.. but just to be sure ran it again .. then ran 'npm run start:dev' and lo and behold it started the nest dev server like it did last week.. without changing anything other than deleting old images using node:18.13-alpine off my system

To add more context as one person mentioned in their reply: The docker compose that ran (and worked last week but not today) did create a volume to the pwd (the app directory) and so I assume there would be node_modules in that mount as my local machine is the 'root' for this project's initial build and docker development environment creation

So here I am more confused than at the start as to what in the heck is going on here.. and can't wait for one of the other devs to have the same problem so I can say "oh yeah .. just start deleting things and starting them and clicking.. it eventually works again"

I also encountered this issue when building an Angular+nginx image. What worked for me is I included the package-lock.json to the Dockerfile.

# Set the working directory
WORKDIR /app

# Add the source code to app
COPY package.json .
COPY package-lock.json .

# Install all the dependencies
RUN npm cache clean --force

# Generate the build of the application

RUN npm ci --legacy-peer-deps

The original issue with Node.js 16.15.1 / npm 8.11.0 is reproducible running:

docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:16.15.1-alpine run ver

Updating to Node.js 16.18.0 with bundled npm 8.19.2 resolves the npm issue:

$ docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:16.18.0-alpine run ver
Unable to find image 'node:16.18.0-alpine' locally
16.18.0-alpine: Pulling from library/node
f05a94b04b95: Pull complete
90d4f1a52341: Pull complete
96f9ff3b94d8: Pull complete
Digest: sha256:f16544bc93cf1a36d213c8e2efecf682e9f4df28429a629a37aaf38ecfc25cf4
Status: Downloaded newer image for node:16.18.0-alpine

> ver
> npm --version

8.19.2
npm notice
npm notice New major version of npm available! 8.19.2 -> 11.13.0
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v11.13.0>
npm notice Run `npm install -g npm@11.13.0` to update!
npm notice

Node.js 16 reached end-of-life on 2023-09-11.

The lowest currently supported Node.js version is 22.22.2 with bundled npm version 10.9.7. The issue is also no longer reproducible with this version:

docker run --rm -v $PWD:/app --workdir /app --entrypoint npm node:22.22.2-alpine run ver

Closing, as resolved.

Unfortunately, this is only fixed partially. Changes in https://github.com/npm/cli/pull/5757/changes now allows this image to be run as root, but it is still broken the same way when running on rootless Docker, or other unprivileged environments. The real issue is really not the permissions, but the incorrectly configured cache folder settings in the image itself. I have created a generalized ticket about this #2495.

Navigation Menu

Repository navigation

fails to invoke npm when used in run-scripts #1734

Environment

Expected Behavior

Current Behavior

Steps to Reproduce

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fails to invoke npm when used in run-scripts #1734

Description

Environment

Expected Behavior

Current Behavior

Steps to Reproduce

Activity

alaney commented on Jun 7, 2022

parkwart commented on Jun 8, 2022

reidja commented on Jun 8, 2022

gcstarr commented on Jun 10, 2022

electriquo commented on Jun 14, 2022

neonidian commented on Jun 15, 2022

cascornelissen commented on Jun 22, 2022

scooper91 commented on Jun 27, 2022

yuki-js commented on Jun 28, 2022

SmallhillCZ commented on Jun 29, 2022

electriquo commented on Jun 29, 2022

electriquo commented on Jul 6, 2022

yuki-js commented on Jul 10, 2022

electriquo commented on Jul 10, 2022

9 remaining items

neon010 commented on Sep 14, 2022

DaleCam commented on Sep 16, 2022

ViliusS commented on Oct 10, 2022

ViliusS commented on Oct 10, 2022

nschonni commented on Oct 10, 2022

ViliusS commented on Oct 10, 2022

sasskinn12 commented on Oct 11, 2022

hannesvdvreken commented on Oct 11, 2022

stall84 commented on Feb 6, 2023

carloliwanag commented on May 2, 2023

MikeMcC399 commented on May 3, 2026

ViliusS commented on May 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions