I am running the nf-core RNAseq pipeline, but I me...
# rnaseq
x
I am running the nf-core RNAseq pipeline, but I met an error and I dont know to fix it, is anybody can belp me?
m
Looks like a temporary? problem with your storage.
/storage2
seems to have had an issue? File does not exist and parent directory is not writeable points into this direction.
x
storage2 is writable and still has 38 TB of free space, but its usage is already at 88%.
m
And if you
-resume
, the error is persists?
x
yes
🤔 1
m
Elapsed time: 0.01 minutes
for Markduplicates suggests that the command crashes right away. Can you locate the input file
24L01770.sorted.bam
and check if that looks normal? Maybe even try to run the command outside of the pipeline on that file?
x
I check the file and run the script, the error still exists
t
If you are running on a cluster, could it be that you have access to the storage from the head node, but not from the compute node, or some nodes, but not others? (Or maybe there is a different
/storage2
mounted there?) Maybe your sysadmins have some ideas.
x
https://github.com/samtools/htsjdk/issues/1671 here, they have the same issue
m
Unfortunately, it is outside the scope of the pipeline then, since it seems to be related to the NFS mount and would require a fix in samtools libraries. Ideally, try to find another storage or ask your admins, if they can make a folder on that network attached storage available via FUSE or Plan 9 File Protocol instead of NFS. Most storage backends support various protocols and are not limited to NFS.
You can alternatively try the workaround described in the GitHub thread, build your custom container and override the default with a custom container config.
t
Definitely talk to the sysadmins, maybe they can change those special permissions (NFS in general is fine, it is being used practically everywhere). I wonder if this is something that can be solved at the Java level (where file access functions are iplemented), and if so, if the newest Java versions can deal with it. That would still require a custom container (or possibly Conda environment), though, since the Java for
samtools
is taken from there.
x
After changing the working directory, I was able to run the pipeline successfully, but I encountered a new error(deseq2_qc.r).
t
Glad you solved the issue with your work directory. Have a look in the
.nextflow.log
(where you started the pipeline) and see which process failed. You appear to have some incompatibility of names. You can also go to the work directory of the process (as listed in your log) and see which files are being used by what code. That might give you an idea what is going wrong. The issue is in one of the QC processes, so if you just want results quickly and don't care about this particular process, there may be a parameter to skip it.