Repository navigation
fs.copyFile fails if source is readonly and target is a WSL volume #44261
Description
Version
v18.7.0
Platform
Linux 774484ed2c79 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 Linux
Subsystem
fs
What steps will reproduce the bug?
- Command Prompt
docker run --rm -it ^
-e "CODE=require('fs').copyFileSync('/tmp/file', '/target/file')" ^
-v "%TEMP%:/target" ^
node:alpine ^
sh -c "touch /tmp/file && chmod -w /tmp/file && node -e 'eval(process.env.CODE)'"- Git Bash
docker run --rm -it \
-e "CODE=require('fs').copyFileSync('/tmp/file', '/target/file')" \
-v "$TEMP:/target" \
node:alpine \
sh -c "touch /tmp/file && chmod -w /tmp/file && node -e 'eval(process.env.CODE)'"How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior?
No error.
What do you see instead?
node:internal/fs/utils:348
throw err;
^
Error: EACCES: permission denied, copyfile '/tmp/file' -> '/target/file'
at Object.copyFileSync (node:fs:2866:3)
at eval (eval at <anonymous> ([eval]:1:1), <anonymous>:1:15)
at [eval]:1:1
at Script.runInThisContext (node:vm:129:12)
at Object.runInThisContext (node:vm:313:38)
at node:internal/process/execution:76:19
at [eval]-wrapper:6:22
at evalScript (node:internal/process/execution:75:60)
at node:internal/main/eval_string:27:3 {
errno: -13,
syscall: 'copyfile',
code: 'EACCES',
path: '/tmp/file',
dest: '/target/file'
}
Activity
fix(cli): copy readonly file in WSL system
prettydiff commentedon Aug 19, 2022
Is the file in question read protected by the operating system? If the operating system has marked a file as read protected, such that it is locked by an underlying operating system process Node will not be able to perform the necessary
fs.openmethod on the file to access the file contents. You will not see this very often on files you, as a user or administrator, own. However, it will happen on some files at the file system root, in system32, file associated with regedit, and so forth. You should still be able to see these files withfs.readdirandfs.statthough.See also:
juanrgm commentedon Aug 19, 2022
But this it works:
github-actions commentedon Jun 25, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 26, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Zamiell commentedon Sep 3, 2026
This is still reproducible on Node.js v24.19.0 with current WSL2. Unlike the original report, the source file is not read-only and Docker is not involved.
Environment
The Windows drive is mounted as 9p:
Reproduction
The source is on the native WSL filesystem and has mode
0644. The destination is a writable directory under/mnt/c.Result:
The destination directory is writable and its Windows ACL grants my user full control. These operations succeed:
fs.writeFile()to the same destinationcpbetween the same source and destinationfs.copyFile()implementationA direct permission change on a newly created destination file fails:
This appears to be a different remaining case from #56248. That issue fixed
futimens()failures on CIFS/SMB. Node v24.19.0 contains that fix.In the current libuv
uv__fs_copyfile()implementation, anEPERMfromfchmod()is ignored only whenuv__is_cifs_or_smb(dstfd)succeeds. WSL's/mnt/cis reported as filesystem type9p, so the error remains fatal even though the file data can be copied successfully and Unix mode preservation is not supported by this mount.Could this issue be reopened, or should the
fchmod()handling be moved to libuv with 9p/WSL included among the filesystems where permission preservation is best-effort?