Running fmriprep with Docker without root-owned files?

, ,
1

I followed the instructions on using fmriprep with Docker as indicated in the documentation, and run the command below:
fmriprep-docker /path/to/data/dir /path/to/output/dir participant

The resulting output directory and files are owned by root. Is there a way to have the files owned by the user running the that command?

2

You can’t with fmriprep-docker as currently written, but it does print the generated docker command. You can try adding the --user flag, but I don’t know that it works.

3

You can change the default group permissions for a group called <your-group> doing the following:

setfacl -R -m g:<your-group>:rwX /path/to/output

If you’ve already have files under /path/to/output, then you will also need:

find /path/to/output -type d | xargs setfacl -R -m d:g:<your-group>:rwX

Files will still be owned by root, but any user belonging in <your-group> will be allowed to read and write.

4

Thanks @oesteban. To make sure, this is to be done before running fmriprep, is that right?

Also, what about the suggestion of @effigies (thank you @effigies for this) , to use the --user flag? Would that work to have all the files and directories being owned by a given user? Should the two methods proposed be combined to set both user and group ownership, or is there also a --group flag to set both ownership in one go when running the docker command?

5

Hi @michael, if you’ve already run fmriprep, then you’ll need both commands. From that moment on, you’ll have the new permissions set. But yes, ideally, you will want to do that ahead of time.

If you give @effigies’ suggestion a try, I would suggest using your user and group ids like --user $(id -u):$(id -g). The docker image of FMRIPREP does not have any users created, so the behavior in this case is quite unpredictable. I’ve just given it a try and it apparently works.

1 Like
6

Hey Michael,

We had the same thought/issue. After fiddling with the docker syntax, the following worked for us (at least so far without error, the pipeline is still running…):

docker run --user 1xx:1yy -w=/out --rm -it -v /usr/local/freesurfer/license.txt:/opt/freesurfer/license.txt:ro -v /data/project/raw_bids:/data:ro -v /data/project/out:/out poldracklab/fmriprep:1.1.2 /data /out participant --ignore=slicetiming --participant_label subjectXX

The second addition (-w=/out) was necessary since in our version of fmriprep (1.1.2) the WORKDIR is set to a folder within /root/src, which is not accessible for regular UIDs.

Does this help?

1 Like
7

Hi @Jochen,

In the latest release of fmriprep (1.1.3, came out last Tuesday) we have addressed both concerns. Now the fmriprep-docker interface will allow you to run as user setting a -u $(id -u). I’m not 100% sure about the group though, but in theory it should work out.

We have also changed the WORKDIR to /tmp, so it does not write to /root/src anymore.

Thanks very much!

1 Like