Feature Request: Fallback from fs.copyFile() to a simple stream-based copy to work in restricted ACL mode datasets.

[tabalugadreieck]

Copy of:
nxzai#367

Problem description

Copy/Move-Paste fails in a dataset with restricted ACL mode because chmod/chown is not allowed.

Reproduction Example:

printf 'copy test\n' > nx-test.txt
cp -v nx-test.txt nx-test-cp.txt
# succeeds
node -e "require('node:fs').copyFileSync('nx-test.txt', 'nx-test-node.txt')"
# fails: EPERM operation not permitted, copyfile
cp -av nx-test.txt nx-test-archive.txt
# content is copied, then fails:
# can't preserve permissions: Operation not permitted

Environment:
TrueNAS SCALE 25.10, host-path-mounted ZFS dataset using NFSv4/SMB ACLs with aclmode=restricted. NextExplorer deployed as docker app. The app can browse, create, rename, and delete. The container runs as root.
Changing ACL mode to passthrough: Copy works again without error.

Feature Request

Please add a copy mode that does not preserve/chmod/chown file metadata, or fall back to a stream-based copy when fs.copyFile() returns EPERM. This is required for restricted ACL datasets where new files must inherit the destination directory ACL unchanged, e.g. because they are used with additional SMB access.
This could either be implemented as a fallback when fs.copyFile() returns EPERM or just be a global toggle: Preserve file mode/metadata on copy: disabled

[cerede2000]

Thanks for the report — the reproduction and the aclmode detail made this quick to pin down.

What was happening

It isn't fs.copyFile() on this fork. On Linux, copies go through rsync, and the command was:

rsync -a --no-owner --no-group ...

-a implies -p, so rsync chmods the destination after writing it. --no-owner and --no-group drop the owner and the group, but not the permissions — so the chmod remained, and your dataset refuses it. That matches your cp -av exactly: the contents are copied, and only the metadata step fails.

This applies to moves too, when they cross datasets: the rename fails with EXDEV and falls back to the same copy path.

What it does now

Preserving permissions is still the default, and nothing changes where it works.

Where the chmod is refused, the copy runs again without -p. rsync is idempotent, so the second pass transfers nothing — everything is already up to date — and only completes what the first could not. Your files end up with the destination directory's inherited ACL, untouched, which is what you asked for.

The retry is deliberately narrow: it needs both exit code 23 and a failed to set permissions message. Exit 23 also covers unrelated cases — a source file that vanished mid-copy gets the same code — and retrying those without -p would only hide the real error.

Making it permanent

On a dataset where every copy would fail that way, paying for a doomed attempt and a retry each time is waste. So there is also a global switch:

COPY_PRESERVE_PERMISSIONS: "false"

With that, the copy never attempts to preserve permissions at all — one rsync call, straight away. This is the Preserve file mode/metadata on copy: disabled toggle you suggested.

Please try it

It's on the test image, ready now:

ghcr.io/cerede2000/explorer:test

or the smaller variant, ghcr.io/cerede2000/explorer:test-lean (no VA-API or RAW support).

Try it first without setting anything — the fallback should carry your copy through on its own. If that works, COPY_PRESERVE_PERMISSIONS=false is worth setting anyway on a restricted dataset, purely to skip the attempt that cannot succeed.

I can reproduce the refusal in tests but not a real ZFS dataset with aclmode=restricted, so a confirmation from your setup is genuinely useful before this goes to a release. If anything still fails, the rsync output in the error would tell us what else it is trying to set.

[cerede2000]

Hi @tabalugadreieck, it's ok ?
I can close this issue ?