René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"fs.cpSync fails with EACCES when the destination is on a Docker bind mount (regression in 22.17)","articleBody":"### Version\n\nv22.17.1 (also v22.18.0, v22.20.0, v22.23.2, v24.19.0). Last good: **v22.16.0**.\n\n### Platform\n\nDocker Desktop on macOS (Darwin 25.5.0, arm64), default VirtioFS file sharing. Reproduced with the official `node:*-slim` images, so the container distro is Debian bookworm.\n\n### Subsystem\n\nfs\n\n### What steps will reproduce the bug?\n\n`fs.cpSync(src, dest, { recursive: true })` throws `EACCES` when `dest` is on a Docker bind mount. The same call succeeds on 22.16.0, and on 22.17.1 it succeeds when `dest` is on the container's own filesystem.\n\nOn a macOS host:\n\n```bash\nmkdir -p /tmp/repro/src/nested\nprintf 'a' > /tmp/repro/src/file.txt\nprintf 'b' > /tmp/repro/src/nested/inner.txt\n\nfor V in 22.16 22.17; do\n  docker run --rm -v /tmp/repro:/mnt/repro -w /mnt/repro node:$V-slim node -e \"\nconst fs = require('fs');\nconst dest = 'out-' + process.version.replace(/[^0-9]/g, '_');\ntry { fs.cpSync('src', dest, { recursive: true }); console.log(process.version, 'OK'); }\ncatch (e) { console.log(process.version, 'FAIL', e.code, e.syscall, e.path); }\n\"\ndone\n```\n\nOutput:\n\n```\nv22.16.0 OK\nv22.17.1 FAIL EACCES cp out-_22_17_1\n```\n\n### How often does it reproduce?\n\nEvery time, on every version from 22.17.1 onward that I tested.\n\n### What is the expected behavior?\n\n`cpSync` copies the tree, as it does on 22.16.0 and as `cp -R` does on the same path in the same container.\n\n### What do you see instead?\n\n```\nError: EACCES: permission denied, cp 'out-_22_17_1'\n```\n\n### Additional information\n\n**This is not a permission problem.** In a single container run on 22.17.1, with the bind mount as CWD:\n\n```\nnode v22.17.1\n  FAIL dest on bind mount        EACCES cp bind-dest\n  OK   dest on container fs\n  control: id=0 access(W_OK)=yes\n  control: mkdirSync on bind mount OK\n  control: copyFileSync on bind mount OK\n  control: cp -R OK\n```\n\nSo, on the very path that `cpSync` rejects:\n\n- the process is **root** (uid 0) — it also fails as a non-root uid matching the host owner;\n- `fs.accessSync(dir, W_OK)` succeeds;\n- `fs.mkdirSync` succeeds;\n- `fs.copyFileSync` succeeds;\n- coreutils `cp -R` succeeds;\n- `fs.cpSync` with the **same source** and a destination on the container's own filesystem succeeds.\n\nOnly the combination of `cpSync` + a bind-mount destination fails.\n\n`cpSync` does partially complete before throwing: the destination directory is created and at least one entry is copied, so a retry then sees `EEXIST`/`ENOTEMPTY`. That makes the failure messy to recover from in a build pipeline.\n\n**Bisect** (identical mount, source, destination and uid; only the Node binary varies):\n\n| Version | Result |\n| ------- | ------ |\n| 22.13.1 | OK |\n| 22.14.0 | OK |\n| 22.16.0 | OK |\n| 22.17.1 | EACCES |\n| 22.18.0 | EACCES |\n| 22.20.0 | EACCES |\n| 22.23.2 | EACCES |\n| 24.19.0 | EACCES |\n\nThe boundary lines up with the C++ reimplementation of `cpSync`, which landed in 22.17. The mechanism is below.\n\n**Real-world impact.** `@nx/next:build` finishes by copying the app's `public/` directory into its output path with exactly this call:\n\n```js\ncpSync(join(projectRoot, 'public'), join(options.outputPath, 'public'), {\n  dereference: true,\n  recursive: true,\n});\n```\n\nAny Next.js build run inside a container against a bind-mounted workspace therefore fails on Node ≥ 22.17 — after the build has already compiled and typechecked successfully, so it presents as a mysterious late-stage permission error rather than an obvious environment problem. Related historical regressions in the same function: #54285, #54782.\n\n**Root cause.** Reduced to raw syscalls in the container, as root:\n\n```\nFAIL open dest O_WRONLY|O_CREAT|O_TRUNC mode 0200   errno=13 (Permission denied)\nOK   open dest O_WRONLY|O_CREAT|O_TRUNC mode 0644\nFAIL reopen the 0200 file O_WRONLY                  errno=13 (Permission denied)\n```\n\nlibstdc++'s `do_copy_file` creates the destination with `S_IWUSR` (0200) and `fchmod`s it to the source's mode afterwards. This mount refuses to open a mode-0200 file for writing, so the create fails. `uv_fs_copyfile` creates the destination with the source's mode and is unaffected.\n\nThat is confirmed outside Node entirely — plain C++ with gcc 14 and libstdc++, same mount:\n\n```\nFAIL copy_file  mount -> mount   value=13 msg=Permission denied\nOK   copy_file  mount -> /tmp\nOK   copy_file  /tmp  -> /tmp\nFAIL copy_file  /tmp  -> mount   value=13 msg=Permission denied\n```\n\n**Which is why `cpSync` is inconsistent with itself**, on one mount in one process:\n\n| Call | Result | Path taken |\n| ---- | ------ | ---------- |\n| `cpSync(file, newDest)` | OK | JS falls through to `copyFileSync` (libuv) |\n| `cpSync(file, existingDest)` | EACCES | `CpSyncOverrideFile`, `mode == 0` branch |\n| `cpSync(dirWithAFile, dest)` | EACCES | `CpSyncCopyDir`, regular-file branch |\n| `cpSync(dirNoFiles, dest)` | OK | no file is ever copied |\n\n`fs.copyFileSync` works on this mount because it uses `uv_fs_copyfile`. Both failing paths already have a libuv sibling in `node_file.cc`; they just do not take it.\n\n**Workaround.** Pin to 22.16.x, or arrange for the destination to live on the container's own filesystem rather than the bind mount.","author":{"url":"https://github.com/mnaimfaizy","@type":"Person","name":"mnaimfaizy"},"datePublished":"2026-08-23T01:37:39Z","url":"https://github.com/nodejs/node/issues/65497"}