Untar needs --no-same-owner on DNAnexus

[GHAStVHenry]

Check Documentation

I have checked the following places for your error:

• nf-core website: troubleshooting
• nf-core/rnaseq pipeline documentation

Description of the bug

untar Cannot change ownership error
see bottom for suggested fix

@pditommaso @drpatelh

Steps to reproduce

Steps to reproduce the behaviour:

Run workflow on DNAnexus (with xpack) profile test,docker

NFCORE_RNASEQ:RNASEQ:PREPARE_GENOME:UNTAR_SALMON_INDEX (SALMON.TAR.GZ)
fails

Expected behaviour

Log files

tar: salmon/complete_ref_lens.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/pre_indexing.log
tar: salmon/pre_indexing.log: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/versionInfo.json
tar: salmon/versionInfo.json: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/duplicate_clusters.tsv
tar: salmon/duplicate_clusters.tsv: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/mphf.bin
salmon/pos.bin
tar: salmon/mphf.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/reflengths.bin
tar: salmon/pos.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
tar: salmon/reflengths.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/ctable.bin
tar: salmon/ctable.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/refseq.bin
tar: salmon/refseq.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/rank.bin
tar: salmon/rank.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/refAccumLengths.bin
tar: salmon/refAccumLengths.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/ctg_offsets.bin
tar: salmon/ctg_offsets.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
salmon/seq.bin
salmon/ref_indexing.log
tar: salmon/seq.bin: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
tar: salmon/info.json
salmon/ref_indexing.log: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
tar: salmon/info.json: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
tar: salmon: Cannot change ownership to uid 30004321, gid 30000513: Invalid argument
tar: Exiting with failure status due to previous errors

Have you provided the following extra information/files:

• The command used to run the pipeline
• The .nextflow.log file

System

• Hardware: DNAnexus
• Executor:
• OS:
• Version xpack beta6

Nextflow Installation

• Version:

Container engine

• Engine:
• version:

Additional context

can be fixed by adding --no-same-owner to untar command at:

rnaseq/modules/nf-core/modules/untar/main.nf

Line 31 in 964425e

tar \\

[drpatelh]

Hi @GHAStVHenry ! Thanks for reporting! This appears to be the same issue as reported by @drejom in #712

We noticed another issue with Salmon recently that we haven't quite been able to get to the bottom of. I am trying to reproduce on AWS Batch via Tower at the moment but maybe it's worth creating an issue here for it too @drejom ?

[GHAStVHenry]

Oh I actually just got added to the source of @drejom's source issue, but hadn't looked through yet to see this was one of the issues

[drejom]

We noticed another issue with Salmon recently that we haven't quite been able to get to the bottom of. I am trying to reproduce on AWS Batch via Tower at the moment but maybe it's worth creating an issue here for it too @drejom ?

#727

[drpatelh]

can be fixed by adding --no-same-owner to untar command at:

Hi @GHAStVHenry! Do you happen to know why we need this option when running tar and is it something that can be bypassed? I am trying to figure out the best way to ship this option in the next release because it is a non-mandatory option for all other platforms. Maybe having a custom DNAnexus config is the best option here?

[GHAStVHenry]

Howdy @drpatelh!

--no-same-owner is on by default normally, so adding it to the next patch shouldn't affect any deployment on any other environment, and the fact that it happens on DNAnexus means that it could happen elsewhere (even if it's never seen before), so it really would improve robustness.

Why it is necessary in DNAnexus, but has never been seen before in other environments? I have no idea... actually, I have a half baked idea that's not ready for a public forum until I talk to product engineering and Paolo.

[drpatelh]

--no-same-owner is on by default normally

Yep, you are absolutely right.

      --no-same-owner        extract files as yourself (default for ordinary users)

Maybe you folks aren't ordinary users - superpower ones instead?! 😆

[GHAStVHenry]

hahaha, I like the sound of that... let's go with that hahaha

[pditommaso]

default for ordinary users

But likely the container runs as root, and therefore the it should be given explicitly