Hello,
I am running fmriprep-docker on remote computer and I do not have ROOT permissions. However, it looks like the output directories (fmriprep and fresurfer) has only ROOT permission. Is there any way to change the output files permission so that the user has the ownership?
Not directly with fmriprep-docker, but when you run fmriprep-docker, it prints a fully-expanded command, e.g.
$ fmriprep-docker /bids /bids/derivatives participant -w /scratch
RUNNING: docker run --rm -it \
-v /bids:/data:ro -v /bids/derivatives:/out -v /scratch:/scratch \
poldracklab/fmriprep:1.1.1 /data /out participant -w /scratch
(Newline and spaces added for readability.)
So you can copy this command, and make additions such as -u $UID, which will cause it to run under your user name:
docker run --rm -it \
-v /bids:/data:ro -v /bids/derivatives:/out -v /scratch:/scratch -u $UID \
poldracklab/fmriprep:1.1.1 /data /out participant -w /scratch
Note that you’re going to need to use the -w flag and mount a working directory that you own into the container, to avoid permission issues within the container.
3 Likes
I tried following but did not work. Would you please check on (below) this if i made mistakes somewhere?
Thanks
BL
After I ran this: " fmriprep-docker --fs-license-file /usr/local/pkg/freesurfer6.0/.license /data/BIDS/OA /data/BIDS/OA1 -w /scratch" got printed following extended commands:
docker run --rm -it -v /usr/local/pkg/freesurfer6.0/.license:/opt/freesurfer/license.txt:ro -v /data/BIDS/OA:/data:ro -v /data/BIDS/OA1:/out -v /scratch:/scratch poldracklab/fmriprep:1.0.15 /data /out participant -w /scratch
180618-16:45:58,806 workflow IMPORTANT:
Running fMRIPREP version 1.0.15:
* BIDS dataset path: /data.
* Participant list: ['201'].
.............
Then, following your suggestion, I modified as ( where 1552 is my user id):
docker run --rm -it -v /usr/local/pkg/freesurfer6.0/.license:/opt/freesurfer/license.txt:ro -v /data/BIDS/OA:/data:ro -v /data/BIDS/OA1:/out -v /scratch:/scratch -u 1552 poldracklab/fmriprep:1.0.15 /data /out participant -w /data/BIDS/OA1
But got following error:
Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused “chdir to cwd (”/root/src/fmriprep") set in config.json failed: permission denied": unknown.
Ah, interesting. Well, nothing requires that you be in that directory, so we may want to adjust our default CWD in Docker.
In the meantime, can you put -w / before the image name? (This -w will apply to docker itself; the -w /scratch after the image name is an argument to fMRIPrep, so we still want that, too.)
Edit: Or you could use -w /scratch on both sides, to ensure that you’re in a directory you own.
Hello,
I did try this and ended up with error again. But I not sure if I put -w on right place ( like you mentioned above)-could you please help me putting -w in right place by copy-pasting above extended commands ( or in fmriprep-docker command) ?
Thanks
BL
Sure, no problem.
docker run --rm -it \
-v /usr/local/pkg/freesurfer6.0/.license:/opt/freesurfer/license.txt:ro \
-v /data/BIDS/OA:/data:ro \
-v /data/BIDS/OA1:/out \
-v /scratch:/scratch \
-w /scratch \
poldracklab/fmriprep:1.0.15 /data /out participant -w /scratch
Also, advanced apologies if this doesn’t work. I haven’t tested it, so it may be useful to dig through docker run --help output for other possibilities for modifying the current working directory (CWD) of processes within the container.
Thank you so much !
I will keep digging on it using --help but just wanted show you the error message(below) by using the extended command you suggested…
Thanks
BL
%--------------------------------------------------------------------------------------------------------
Running fMRIPREP version 1.0.15:
* BIDS dataset path: /data.
* Participant list: [‘201’].
* Run identifier: 20180620-005232_a663fb02-b343-4c3d-bae4-1efcbb0171d1.
180620-00:52:33,978 workflow IMPORTANT:
Creating bold processing workflow for “/data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmAP_run-01_bold.nii.gz” (0.40 GB / 1072 TRs). Memory resampled/largemem=1.62/5.95 GB.
180620-00:52:34,828 workflow IMPORTANT:
Slice-timing correction will be included.
180620-00:52:35,43 workflow IMPORTANT:
SDC: fieldmap estimation of type “epi” intended for /data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmAP_run-01_bold.nii.gz found.
180620-00:52:35,838 workflow IMPORTANT:
Creating BOLD surface-sampling workflow.
180620-00:52:37,699 workflow IMPORTANT:
Creating bold processing workflow for “/data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmAP_run-04_bold.nii.gz” (0.38 GB / 1009 TRs). Memory resampled/largemem=1.54/5.41 GB.
180620-00:52:38,483 workflow IMPORTANT:
Slice-timing correction will be included.
180620-00:52:38,705 workflow IMPORTANT:
SDC: fieldmap estimation of type “epi” intended for /data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmAP_run-04_bold.nii.gz found.
180620-00:52:39,552 workflow IMPORTANT:
Creating BOLD surface-sampling workflow.
180620-00:52:41,428 workflow IMPORTANT:
Creating bold processing workflow for “/data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmPA_run-02_bold.nii.gz” (0.40 GB / 1072 TRs). Memory resampled/largemem=1.61/5.92 GB.
180620-00:52:42,89 workflow IMPORTANT:
Slice-timing correction will be included.
180620-00:52:42,316 workflow IMPORTANT:
SDC: fieldmap estimation of type “epi” intended for /data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmPA_run-02_bold.nii.gz found.
180620-00:52:43,84 workflow IMPORTANT:
Creating BOLD surface-sampling workflow.
180620-00:52:44,989 workflow IMPORTANT:
Creating bold processing workflow for “/data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmPA_run-03_bold.nii.gz” (0.40 GB / 1063 TRs). Memory resampled/largemem=1.60/5.84 GB.
180620-00:52:45,718 workflow IMPORTANT:
Slice-timing correction will be included.
180620-00:52:45,934 workflow IMPORTANT:
SDC: fieldmap estimation of type “epi” intended for /data/sub-201/ses-01/func/sub-201_ses-01_task-DofG_acq-MB43mmPA_run-03_bold.nii.gz found.
180620-00:52:46,676 workflow IMPORTANT:
Creating BOLD surface-sampling workflow.
Traceback (most recent call last):
File “/usr/local/miniconda/bin/fmriprep”, line 11, in
load_entry_point(‘fmriprep==1.0.15’, ‘console_scripts’, ‘fmriprep’)()
File “/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/cli/run.py”, line 314, in main
fmriprep_wf.run(**plugin_settings)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/workflows.py”, line 594, in run
self._write_report_info(self.base_dir, self.name, execgraph)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/workflows.py”, line 619, in _write_report_info
op.join(report_dir, ‘index.html’))
File “/usr/local/miniconda/lib/python3.6/shutil.py”, line 121, in copyfile
with open(dst, ‘wb’) as fdst:
PermissionError: [Errno 13] Permission denied: ‘/scratch/fmriprep_wf/index.html’
Sentry is attempting to send 1 pending error messages
Waiting up to 10 seconds
Sorry for the slow response. Do you have permissions in /scratch? If not, you may need to mount a different directory.
Thank you, actually I have asked the (root-personal) to run a script-( to change permission) in every 24 hrs for me as a temporary solution. Please let me know if there is a easy fix without running a script ?
Also, I am having memory issue–is there a way to increase the allocated memory ( to docker) on docker-fmriprep command ?
Thanks
BL
Hi there, sorry to bump up an old thread, but I’m interested in hearing any new developments on this issue. I access a server where all my data is housed and where all data processing takes place and I do not have root access. I do however, have a directory that I own with drwxrwxrwx permissions. I’m testing out fmriprep and noticed that the output directory and files have “nobody” as an owner and I am unable to delete files and directories to clear out space after moving output to a different location. It would be nice to have the output’s owner set to me so that I can clear out files if/when necessary. I am running fmriprep through docker and have been trying out the following command (organized for clarity) to run subject 003.
docker run -ti --rm
-v /scratch/crodriguez/data:/data:ro
-v /scratch/crodriguez/prep/derivatives:/out
-v /scratch/crodriguez/prep/wd:/work
-u crodriguez
-v /export/apps/linux-x86_64/freesurfer/freesurfer_6.0/license.txt:/opt/freesurfer/license.txt
poldracklab/fmriprep:20.1.1 /data /out/fmriprep-20.1.1
participant -w /work
–participant-label 003
I get the following error:
Error response from daemon: linux spec user: unable to find user crodriguez: no matching entries in passwd file.
Has anyone figured out how to use fmriprep via docker and change permissions to the user?
Can you try -u $UID?
1 Like
Hi Chris,
Thanks for the response. I was able to get the permissions to work.
What I did was type “id -u” in a linux terminal and got a 5-digit user ID number. I used that number in my command to run the following:
docker run -ti --rm
-v /scratch/crodriguez/data:/data:ro
-v /scratch/crodriguez/prep/derivatives:/out
-v /scratch/crodriguez/prep/wd:/work
-u 11555
-v /export/apps/linux-x86_64/freesurfer/freesurfer_6.0/license.txt:/opt/freesurfer/license.txt
poldracklab/fmriprep:20.1.1 /data /out/fmriprep-20.1.1
participant -w /work
–participant-label 003
That subject ran successfully and had the appropriate permissions.
1 Like
Hi all, me and another user in my lab are both running fmriprep jobs via singularity for the same BIDS directory, on different subjects alternating.
The other user is getting permissions denied for the same file mentioned in this thread, the index.html in the work directory. I have used setfacl and chmod to ensure those directories are accessible rwx for the other user, but I don’t think those permissions stick. Is there a singularity version to this solution? I didn’t see a user flag in the singularity run help text.
@claytonjschneider, what you’re describing sounds like a related but slightly different issue. I think what you’re doing is something like starting several separate processes of fMRIPrep, each with different participants, with the added complication that you run some participants while a labmate runs others. Is that about right?
Every time fMRIPrep starts, it generates several files in the working directory related to overall processing, with the index.html file being one of them. If those files already exist, they will be overwritten. So, the permissions might not be sticking around because the file is being overwritten each time a new participant is run.
Are you able to set a unique working directory for each participant (the value for the -w option) ? For example, if the participant’s id is stored in a variable PARTICIPANT_LABEL, then do something like
-w /work/"${PARTICIPANT_LABEL}"
If there is a unique working directory for each run of fmriprep, then I expect that any changes you make to the permissions on the resulting index.html files will persist.
Hope that helps. If it doesn’t could you start a new thread and link back to this one? A new thread would be a bit easier to track and search for. Thanks!