Podman Permission Issues on Lifebit Platform

Dear Seqera Team and Community,

I recently started working on the Lifebit platform to run analyses using Nextflow. The pipeline I am running has been tested successfully on multiple servers with different environments, primarily using Apptainer. However, on the Lifebit platform, where Podman containers are used, I am encountering permission-related issues that prevent the container from reading and writing properly.

I would appreciate any insights or guidance on resolving this issue. Below is the error message I encountered:

Error Message:

ERROR ~ Error executing process > 'VEP_score (1)'  

Caused by:  
  Process `VEP_score (1)` terminated with an error exit status (1)  

Command executed:  
  vep -i "p1.vcf" --offline --assembly GRCh38 --vcf --fork 8 --cache --force_overwrite --pick_allele --plugin CADD,/CADD/v1.6/data/GRCh38_v1.6/no_anno/whole_genome_SNVs.tsv.gz, CADD/v1.6/data/GRCh38_v1.6/no_anno/gnomad.genomes.r3.0.indel.tsv.gz,"wes.tsv.gz" --af_gnomadg --fields "Allele,Consequence,SYMBOL,Gene,gnomADg_AF,gnomADg_NFE_AF,gnomADe_AF,gnomADe_NFE_AF,CADD_RAW,gnomadRF_RF_flag" -o "chr10.pl.vep.vcf" --dir_cache VE P111/ --dir_plugins /templates/Plugins  

Command exit status:  
  1  

Command output:  
  (empty)  

Command error:  
  time="2025-02-06T16:13:55Z" level=warning msg="failed to set net.ipv6.conf.default.accept_dad sysctl: open /proc/sys/net/ipv6/conf/default/accept_dad: read-only file system"  
  touch: cannot touch '.command.trace': Permission denied  

Container Used:
docker://parsboy66/vep:v1

Any help or suggestions on resolving this permission issue would be greatly appreciated.

Best regards,
Iman

HI Iman

I’d recommend looking at the .command.run file in the task working directory. This file is vanilla bash and contains everything needed to stage in task inputs and run the container. Executing this file with should be sufficient to replicate the permissions issue:

cd work/pa/thtoyourtaskworkdir
bash .command.run

It sounds like the task working directory is owned by a different user and has restricted permissions that are not extended to the user inside the container.

I would run ls -lha in the task workdir, and then check in the .command.run how the container is executed and then run ls -lha inside the container. Check the uid of the folder owner and the corresponding uid of the user inside the container. It’s very likely that the user inside the container does not have permissions on the mounted volume inside the container.

A common solution is to ensure that the user inside the container is root.

If that doesn’t fix it, it might be a platform-related issue, which we may not able to help with. However you’re welcome to try it out on Seqera platform.

2 Likes