fs.copyFile fails if source is readonly and target is a CIFS volume

[johaven]

Version

v22.21.1

Platform

Linux a7f6d3be6434 5.15.158-2-pve #1 SMP PVE 5.15.158-2 (2024-07-26T13:11Z) x86_64 Linux

Docker: Alpine release 3.22.2

Subsystem

fs

What steps will reproduce the bug?

Hi,

Copying sample.docx fails with EPERM because the source is read-only and the destination is a CIFS share.

Probably related to:

#37284
libuv/libuv#3117
#44261

How often does it reproduce? Is there a required condition?

100% reproducible

What is the expected behavior? Why is that the expected behavior?

/mnt/smb is a CIFS-mounted volume.
sample.docx is a file with read-only permissions for the user running the below code.

Code

import {copyFile} from "fs/promises";

const src = "./sample.docx";
const dest = "/mnt/smb/sample.docx";

await copyFile(src, dest);

console.log("File copied successfully");

The fs.copyFile should be able to succeed in copying the file as long as the destination folder is writable.

What do you see instead?

Error

node:internal/modules/run_main:123
    triggerUncaughtException(
    ^
[Error: EPERM: operation not permitted, copyfile './sample.docx' -> '/mnt/smb/sample.docx'] {
  errno: -1,
  code: 'EPERM',
  syscall: 'copyfile',
  path: './sample.docx',
  dest: '/mnt/smb/sample.docx'
}

Additional information

Works with no error

cp ./sample.docx /mnt/smb/sample.docx

[ish1416]

@johaven I can reproduce this issue. The problem occurs because fs.copyFile uses uv_fs_copyfile() which tries to preserve file permissions, but CIFS doesn't support setting read-only permissions on the destination.

The solution is to implement a fallback mechanism when uv_fs_copyfile() fails with EPERM on CIFS volumes - fall back to manual read/write operations that don't attempt to preserve the read-only permission.

I'd like to work on this fix. Should I proceed with implementing the fallback approach?