docker.fixOwnership not working with busybox's chown

Bug report

Expected behavior and actual behavior

for most containers when docker is enabled, we see the expected behavior: chown is run at the end of a process to transfer ownership from root to NXF_OWNER. However, some containers use the BusyBox software suite, which is incompatible with nextflow's implementation of chown. This seems to be a problem with some mulled containers, since they use BusyBox by default to provide a lightweight suite of basic tools.

Steps to reproduce the problem

For the main.nf, we have:

process stuff {
debug true
container 'quay.io/biocontainers/mulled-v2-d9e7bad0f7fbc8f4458d5c3ab7ffaaf0235b59fb:f857e2d6cc88d35580d01cf39e0959a68b83c1d9-0' 
script:
"""
touch afile.txt
ls -l afile.txt
"""
}

workflow {
stuff()
}

and in the config we have:

docker.enabled = true
docker.fixOwnership = true

You can also replace the container with busybox:latest but i wanted to also have an example with a container that users would realistically have in their process definition.

Program output

The nextflow completes the process successfully, however the .command.log file has the following:

-rw-r--r--    1 root     root             0 Dec  9 04:44 afile.txt
chown: unrecognized option '--from'
BusyBox v1.32.1 (2021-04-13 11:15:36 UTC) multi-call binary.

Usage: chown [-RhLHPcvf]... USER[:[GRP]] FILE...

Change the owner and/or group of each FILE to USER and/or GRP

        -R      Recurse
        -h      Affect symlinks instead of symlink targets
        -L      Traverse all symlinks to directories
        -H      Traverse symlinks on command line only
        -P      Don't traverse symlinks (default)
        -c      List changed files
        -v      List all files
        -f      Hide errors

And afile.txt continues to be owned by root, which is not desirable.

Environment

• Nextflow version: 23.04.3
• Java version: 17
• Operating system: Linux
• Bash version: GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Start with the provided main.nf reproduction and the docker.fixOwnership configuration, then inspect the generated .command.log output in the BusyBox container. Confirm how ownership correction handles BusyBox chown, and consider the issue done when the process completes with afile.txt owned by the configured user rather than root.