pnpm fails with spurious ENOENT in shared volume using gRPC FUSE or VirtioFS
andersk opened this issue · 3 comments
- I have tried with the latest version of Docker Desktop
- I have tried disabling enabled experimental features
- I have uploaded Diagnostics
- Diagnostics ID: B2C62333-7CA4-4567-9275-25C9197CA33C/20230330205254
Expected behavior
pnpm should run successfully in a shared volume.
Actual behavior
pnpm works if the file sharing implementation is set to osxfs (Legacy), but it fails most of the time if the file sharing implementation is set to either gRPC FUSE or VirtioFS, with an error that looks like
ENOENT ENOENT: no such file or directory, copyfile '/vol/.pnpm-store/v3/files/87/8518257fb796f8ea1cdf3fd1f0d36ec182e03559fa02417be6381005db0ed86b11baaf5ec87405cb6f654087e31a0550a74f1934f82403fb5c23ed125d6d77' -> '/vol/node_modules/.pnpm/@codeload.github.com+postcss+postcss-media-minmax+tar.gz+refs+tags@5.0.0_postcss@8.4.21/node_modules/_tmp_1_4ce31e6923e81e32681a5fdd130b6925/_tmp_1_3ae00e407b27e1fa857fed13410eb96d/test/fixtures/color.css'
or
ENOENT ENOENT: no such file or directory, open '/vol/.pnpm-store/v3/tmp/_tmp_1_68aa7d92ad9ed3f8f865fa725cb72c0d/test/fixtures/color-index.css'
even though that file definitely exists (it had just been put there by pnpm itself, and an strace log confirms that it was created well before this spurious ENOENT was returned).
Information
There are many reports of this on the pnpm issue tracker, such as pnpm/pnpm#5803. I found a simple and quick reproduction recipe, given below.
- macOS Version: Ventura 13.3
- Intel chip or Apple chip: Apple M1
- Docker Desktop Version: 4.17.0 (99724)
Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
[2023-03-30T20:54:58.878969000Z][com.docker.diagnose][I] set path configuration to OnHost
Starting diagnostics
[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0038: is the connection to Docker working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?
No fatal errors detected.
Steps to reproduce the behavior
This is reproducible quickly and pretty reliably (89 out of 100 runs with gRPC FUSE, 68 out of 100 runs with VirtioFS, 0 out of 100 runs with osxfs) by running the following command in an empty directory.
docker run --rm -v "$(pwd):/vol" -w /vol -t node:alpine corepack pnpm@8.1.0 install \
https://codeload.github.com/postcss/postcss-media-minmax/tar.gz/refs/tags/5.0.0If you want to reproduce multiple times, delete the .pnpm-store and node_modules directories between runs.
I'd like to +1 on this issue.
Just wanted to add, this happens on M2 chips (Mac Mini) as well.
Same issue here (M1, docker, pnpm)