Nextflow with Podman and Selinux

May 23, 2024 in Writtings

Nextflow is a good idea, but it you wander too far from the ideal environment, you will get into trouble.

Where am I?

I have a Fedora 39/40 box, with Selinux and Podman. It seems from the forums and github issues that there might be some oddities with that config. Right now I'm going to give up on the Slurm queue, enough problems already.

I'm trying to run the sarek pipeline. It looks like a complex and computationally demanding pipeline, so problems are expected. Also I'm running it semi-offline with the following command:


nextflow run nf-core-sarek_3.4.2/3_4_2/ --input samplesheet.csv -profile podman --outdir results -c params.yaml -resume

Problem 1: ".command.sh" is not executable" or "permission denied"

When Podman mounts a volume it can't access the files as freely as Docker does. You might have to label the mount properly (and not just for Nextflow pipelines). Add this to the "params.yaml" file:


podman.mountFlags = 'Z'

Problem 2: Process requirement exceeds available CPUs

I need to limit the number of Cpus available, adding this to the "params.yaml" file:


process {
 withName: 'FASTP' {
  cpus = 4
  memory = '16 GB'
 }
}

Changing "BWA" to whatever tool is complaining about "not enough resources".

Problem 3: file doesn't exist (it does, but is a symlink)

I'm not sure it Docker happily follows symlinks out of the container context, but Podman doesn't. Nextflow creates symlinks to the original source files, in this example the FastQ. But then the container command can't access them. I solved this by also binding the source dir to the container:

 
 podman.runOptions = "-v /abs/path/to/src:/abs/path/to/src:Z"

As the symlinks from the container point to the "/abs/path/to/src", we create that mount in the container with exactly the same path. Don't forget the "Z" if you deal with Selinux!

This document is live, updates are expected.