After 20240403.1.0, global install of specific npm version fails with "permission denied, mkdir '/usr/local/share/man/man5'"

[jakebailey]

Description

After 20240403.1.0, global installs of specific versions of npm fail.

20240324.2.0 does not fail.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

20240403.1.0

https://github.com/jakebailey/hereby/actions/runs/8577653125/job/23510511696

Is it regression?

Yes, https://github.com/jakebailey/hereby/actions/runs/8563597643/job/23469083748

Expected behavior

npm install -g npm@<version> should work.

Actual behavior

npm install -g npm@<version> fails with:

npm ERR! code EACCES
npm ERR! syscall mkdir
npm ERR! path /usr/local/share/man/man5
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, mkdir '/usr/local/share/man/man5'
npm ERR!  [Error: EACCES: permission denied, mkdir '/usr/local/share/man/man5'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/usr/local/share/man/man5'
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: /home/runner/.npm/_logs/2024-04-07T09_43_22_503Z-debug-0.log
Error: Process completed with exit code 243.

Repro steps

Run npm install -g [email protected]. That's it.

[jakebailey]

Related, but pnpm has also started having sporadic problems that only happen on this new image version, and it's breaking DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/actions/runs/8587816469/job/23531927867?pr=69212

[jakebailey]

This also broke TypeScript's nightly publish: https://github.com/microsoft/TypeScript/actions/runs/8586934300/job/23529969314

[jakebailey]

Reran a few times and got the old image again; it passed on the old image: https://github.com/jakebailey/hereby/actions/runs/8585240094/job/23532442215

But another rerun failed on the new one: https://github.com/jakebailey/hereby/actions/runs/8585240094/job/23532442281

This seems to be related to the bump to the global npm from 10.2.4 to 10.5.0.

[jakebailey]

All in all, though, I don't understand why the image update broke things; in all of these cases the install came after setup-node, so why is npm even 10.x on the Node 12 examples? Shouldn't PATH have old npm?

(I am unfortunately not actually at a real machine so have not had a chance to test this all)

And yet, it sometimes works? https://github.com/microsoft/TypeScript/actions/runs/8586651231/job/23529361501

[jakebailey]

I think I see a pattern; on the latest runner image, if setup-node runs without check-latest, the globally installed node is used and a global install of npm fails. For some reason, the old runner image did not break with this?

[mikhailkoliada]

/usr/share/man permission has not changed in the images between version, + we do not have man5 subduer at all, so it looks like a big in nom/node, or might be not a big but something changed

[erik-bershel]

Hey @jakebailey!
It's a well-known bug of NPM. You may use the workaround from here or to read the discussion. You can also submit a bug to the NPM repository - it should help them to resolve it faster. Like here: npm/cli#7044.
Since the bug is not blocking - there is workaround for it, we are unlikely to decide to roll back to the previous version of tool. I will keep this item open for a while to better alert users.

[jakebailey]

I did a bunch of testing, and the particular bad situation is:

• When using setup-node and not specifying a version, it doesn't do anything, leaving the global node/npm on PATH, i.e. what's in /usr/bin. (If you do give a version, it instead uses /opt/hostedcache.)
• In 20240403.1.0, npm install -g [email protected] fails, but, in 20240324.2.0, it passes.

I tried instead using npx [email protected] install -g [email protected] (a hilarious command) to simulate going back to the old runner, and that worked. So, it really is the npm bump itself. Super odd!

Testing every version between 10.2.4 and 10.5.0, it looks like 10.4.0 is the point at which this behavior changed. Past that, it's impossible for me to tell based on npm's commits/changelog.

It's pretty unfortunate that setup-node uses the global install like that, as that basically means the behavior can change based on the runner image's setup. But, I guess that's documented behavior (that's not recommended).

[erik-bershel]

I'm going to close this issue as an external one. I suppose that most Node actions users have already encountered this behavior.