pnpm: ENOENT: no such file or directory, copyfile '/project/.pnpm-store/... -> '/project/node_modules/...

pnpm version: 7.18.2

Code to reproduce the issue: (running vscode devcontainer)

# .devcontainer/Dockerfile

ARG VARIANT="bullseye"
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:0-${VARIANT}

# [Optional] Install additional OS packages.
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
  && apt-get --yes install --no-install-recommends apt-utils dialog 2>&1 \
  #
  # Verify git, process tools, lsb-release (common in install instructions for CLIs) installed
  && apt-get --yes install curl git iproute2 procps lsb-release \
  #
  # install required packages
  && apt-get --yes install sudo python3 && ln -sf /usr/bin/python3 /usr/bin/python

# [Choice] Node.js version: none, lts/*, 16, 14, 12, 10
ARG NODE_VERSION="lts/*"
RUN if [ "${NODE_VERSION}" != "none" ]; then umask 0002 \
  && sh -c ". /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION}" 2>&1; fi

RUN sh -c ". /usr/local/share/nvm/nvm.sh && nvm alias default ${NODE_VERSION} \
  && npm install --global pnpm && pnpm setup && source /root/.bashrc" 2>&1 \
  && sh -c "pnpm add --global turbo" 2>&1
// .devcontainer/devcontainer.json
{
  "name": "myapp",
  "build": {
    "dockerfile": "Dockerfile",
    "args": {
      "devcontainercli": "true",
      "VARIANT": "bullseye",
      "NODE_VERSION": "18.12.1"
    }
  },
  "runArgs": [
    "--cap-add=SYS_PTRACE",
    "--security-opt",
    "seccomp=unconfined"
  ],
  "postCreateCommand": "node --version && pnpm --version",
  "features": {
    "git": "latest",
    "github-cli": "latest",
    "docker-in-docker": "latest"
  },
  "settings": {
    "typescript.tsdk": "node_modules/typescript/lib"
  }
}

Expected behavior:

It should install packages with no errors.

Actual behavior:

$ pnpm install

Scope: all 12 workspace projects
Downloading registry.npmjs.org/typescript/4.9.4: 11.6 MB/11.6 MB, done
Packages: +816
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: /workspaces/myapp/.pnpm-store/v3
  Virtual store is at:             node_modules/.pnpm
 ENOENT  ENOENT: no such file or directory, copyfile '/workspaces/myapp/.pnpm-store/v3/files/4e/e1c88f8c3f4e4cd34cb6c00339bf9d6d036ff4ade3af49e871cc8966b84c729d8b75492acc6413c9a664ac00a57958223ac13c4229da8c62ebe6a53e4f783f' -> '/workspaces/myapp/node_modules/.pnpm/camel-case@4.1.2/node_modules/_tmp_12988_94ced9782f6a201d347acf8754b6bc09/dist/index.spec.d.ts'

pnpm: ENOENT: no such file or directory, copyfile '/workspaces/myapp/.pnpm-store/v3/files/4e/e1c88f8c3f4e4cd34cb6c00339bf9d6d036ff4ade3af49e871cc8966b84c729d8b75492acc6413c9a664ac00a57958223ac13c4229da8c62ebe6a53e4f783f' -> '/workspaces/myapp/node_modules/.pnpm/camel-case@4.1.2/node_modules/_tmp_12988_94ced9782f6a201d347acf8754b6bc09/dist/index.spec.d.ts'
Progress: resolved 863, reused 0, downloaded 813, added 460
Downloading registry.npmjs.org/turbo-linux-arm64/1.6.3: 1.62 MB/5.69 MB

Additional information:

  • node -v prints: v18.12.1
  • Windows, macOS, or Linux?: I’m on M1 Mac and devcontainer running ubuntu 11
$ cat /etc/*release && node --version && pnpm --version && pnpm store path

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
v18.12.1
7.18.2
/workspaces/myapp/.pnpm-store/v3

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 6
  • Comments: 26 (2 by maintainers)

Commits related to this issue

Most upvoted comments

This fails with an ENOENT error in 89 out of 100 runs with gRPC FUSE, 68 out of 100 runs with VirtioFS, and 0 out of 100 runs with osxfs. I opened https://github.com/docker/for-mac/issues/6787.

Inspired by @andersk, setting container file sharing to osxfs implementation solves this issue for me. image

The store was getting created on the same directory level as the project’s node_modules.

Running pnpm config set store-dir /root/.local/share/pnpm/store to change the store directory solved it for me.

# ...
RUN npm install --global pnpm@latest \
  && SHELL=bash pnpm setup \
  && source /root/.bashrc \
  && pnpm config set store-dir /root/.local/share/pnpm/store

Here we were running pnpm in a dev container based on Node 20. There, to avoid permission errors with the process running unprivileged, we had to put the PNPM store into the home directory of the node user instead of root.

We run this command, after PNPM has been installed globally with NPM under the unprivileged node user:

pnpm config set store-dir /home/node/.local/share/pnpm/store

Orbstack(Docker Desktop alternative) has only VirtioFS, any working solution for it?

Inspired by @andersk, setting container file sharing to osxfs implementation solves this issue for me.

The thing is that osxfs has bad performance compared to grpc, and even worse compared to virtiofs…

pnpm in devcontainers is completely unsuable for me, even with @o-az suggestion

The thing is that osxfs has bad performance compared to grpc, and even worse compared to virtiofs…

Yes that gRPC FUSE also solves this issue for me and have a better performance than osxfs.

image

I found a very quick reproduction recipe using Docker Desktop for Mac with the file sharing implementation set to gRPC FUSE or VirtioFS but not osxfs (Legacy). Run this from an empty directory:

docker run --rm -v "$(pwd):/vol" -w /vol -t node:alpine corepack pnpm install \
    https://codeload.github.com/postcss/postcss-media-minmax/tar.gz/refs/tags/5.0.0

This fails with an ENOENT error in 89 out of 100 runs with gRPC FUSE, 68 out of 100 runs with VirtioFS, and 0 out of 100 runs with osxfs. I opened docker/for-mac#6787.

I’m hitting this, on ZFS, on a fast NVME. It’s easy to repro, I can delete the pnpm cache (which is stored under ~/.local/share instead of ~/.cache, unfortunate), and then serially run pnpm install in two worktrees for a project and get this error.

I also have this kind of messages, only when using VirtioFS on mac Docker. As it’s already been told, it looks like a race condition: if running several times, the error message is different each time (even if each time is for a “clean” base, just checked out from repository)… I tried to switch to osxfs or gRPC FUSE and everything works fine. So I don’t know if this kind of issue is due to pnpm or docker (specifically VirtioFS)…

gRPS FUSE with virtualisation framework seem to deliver decent performances, so as it’s important for me to work in an isolated env (vscode devcontainer) I’ll stick to that waiting for this issue to get resolved (by pnpm or docker)…

We should find a way for @zkochan to get his hands on an M1/M2 computer for him to be able to handle this kind of “mac-only” bug…

that happens on mac, only working fix is to move the store directory outside of the volume mount, or dont use hardlinks.

after that error happens, pnpm store status should give the exact same error as above. removing the store then does nothing.

either use mutagen, if you need the volume mount (i imagine for indexing in vscode that would be neat) or just ditch pnpm (or docker for that matter)

i had some hope when virtiofs went out of beta for docker for desktop, but its still happening here as well. bug was reported multiple times already, they cant fix it.

only difference now is, that until now there existed a file with the same name, but with strange modes (sorry cant remember) set and .exec appended to the name.

this is no longer the case, when you check now, the file exists, so might be a race condition somewhere.

“99 got problems multithreading but aint one”

oh, and another solution is to just run pnpm install until it exits 0 😛 that works but still is a joke.

Damn that’s it then, zfs 2.2 on a PCIe4 NVME here.