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
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/fmriprepavoids this problem, but that wasn't necessary in 1.4.1.
You saved my day :)