A little update....
Since i saw in another forum post that an updated version of the container was availlable due to a problem that was not completely different from mine (not MAFFT but I/O and permissions),
I deleted my singularity image and restarted my pipeline.
I ran into the error [30] with permissions on /home/qiime2, previously working processes did not anymore and after further reading in the forum put further bindings for singularity while keeping automounts false.
In case it might be of help for someone stumbling accross this:
In nextflow config the updated bindings:
runOptions = "-B /data/users/${username}:/data/users/${username} -B \${TMP_LOCAL}:/tmp -B /data/users/${username}/Nextflow/qiime2home:/home/qiime2"
Data is obviously my data storage.
TMP_LOCAL is a shared /tmp on my cluster and grants writable /tmp to qiime2.
/home/qiime2 is additionally added to get a writable folder and things work fine for processes outside of MAFFT again, which has the same error as described earlier:
...
/opt/conda/envs/qiime2-amplicon-2024.10/bin/mafft: line 1147: /_codonpos: Read-only file system
/opt/conda/envs/qiime2-amplicon-2024.10/bin/mafft: line 1148: /_codonscore: Read-only file system
/opt/conda/envs/qiime2-amplicon-2024.10/bin/mafft: line 1149: /_seedtablefile: Read-only file system
...
I then tried binding a readable folder to /opt, which obviously was leading to the command qiime being lost as the conda env resides in /opt in the container, which i cannot override.
So as far as i am concerned, I would argue that something mafft specific happens which is based on some wrting process within the container?
The fast itself seems fine:
path in tmp, artifact name and number of sequences (~3000) seem ok.
Will try to puzzle out whether a writable sandbox container helps, though i was trying to avoid that.