Fmriprep: Read-only file system running 1.5.0 in Singularity

Created on 16 Sep 2019  路  8Comments  路  Source: nipreps/fmriprep

This worked in 1.4.1, but fails in 1.5.0.

Traceback (most recent call last):
  File "/usr/local/miniconda/bin/fmriprep", line 10, in <module>
    sys.exit(main())
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py", line 311, in main
    opts = get_parser().parse_args()
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py", line 284, in get_parser
    latest = check_latest()
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/version.py", line 22, in check_latest
    cachefile.parent.mkdir(parents=True, exist_ok=True)
  File "/usr/local/miniconda/lib/python3.7/pathlib.py", line 1241, in mkdir
    self._accessor.mkdir(self, mode)
OSError: [Errno 30] Read-only file system: '/home/fmriprep/.cache/fmriprep'

The command run was:

/cm/shared/singularity/bin/singularity run \
    -B /data:/data -B /data1:/data1 -B /data2:/data2 -B /data3:/data3 -B /cm/shared:/cm/shared \
    --cleanenv \
    /cm/shared/singularity/images/fmriprep-1.5.0.simg \
    /data/ajanes/testing \
    /data/ajanes/testing/derivatives \
    participant \
    --fs-license-file /cm/shared/freesurfer-6.0.1/license.txt \
    --participant_label acj \
    --output-spaces "MNI152NLin2009cAsym:res-2 anat func fsaverage" \
    --n_cpus 4 \
    --mem-mb 8192 \
    --use-plugin /data/ddrucker/workaround.yml \
    --use-aroma --ignore-aroma-denoising-errors \
    --use-syn-sdc \
    -w  /data/ajanes/testing/fmriprep-work
bug container low high

All 8 comments

Adding

-B /some/scratch/dir:/home/fmriprep

avoids this problem, but that wasn't necessary in 1.4.1.

Okay, sorry we've been experiencing so many problems with TemplateFlow and the read-only execution of Singularity that we missed the original cause of this.

So I introduced this issue in #1715.

As @rwblair suggested elsewhere, you can workaround the problem by binding some writable directory into /home/fmriprep/.cache.

You can use this issue to follow up on a fix. Thanks for reporting and your patience!

BTW, alternatively, you could check whether your Singularity installation could be configured to automatically bind $HOME (and make sure it updates the environment variable within the container).

@oesteban this is the version check.

Yup

Does this being closed mean that the container's /home/fmriprep/.cache/fmriprep no longer needs to be bound?

Either way (bound or not) it won't crash or complain. /home/fmriprep/.cache/fmriprep is used to keep a cache of the latest fMRIPrep version, so not writing it out is totally fine.

So yes, you don't necessarily have to bind it anymore.

Adding

-B /some/scratch/dir:/home/fmriprep

avoids this problem, but that wasn't necessary in 1.4.1.

You saved my day :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

effigies picture effigies  路  4Comments

oesteban picture oesteban  路  4Comments

manishsaggar1 picture manishsaggar1  路  5Comments

lenacanlab picture lenacanlab  路  3Comments

alexlicohen picture alexlicohen  路  4Comments