Our local compute center has support for running jobs inside Docker containers and we are super excited about the possibility of running qiime2 using the Docker container.
The catch? Our Docker jobs run as the user (not root) so they can’t use the container as currently configured. Would it be possible to change the configuration of the Docker container installation so that you can run the container as a non-root user?
More details about what I can/can’t run and why I think root permissions are the problem below.
When I try the following locally (running as a non-root user inside the container): $ docker run --user $(id -u):$(id -g) --rm=true -it qiime2/core:2017.9 /bin/bash
The container starts, but when I run $ qiime info
I get: PermissionError: [Errno 13] Permission denied: '/.config'
If I start the container w/o the user flag shown above (running as root inside the container), qiime runs as expected.
Hi @ChristinaLK! Thanks for writing! This certainly sounds like a good idea! Do you think you could provide a bit more detail about what it is specifically that is requiring you to invoke the container this way (e.g. --user)? That will help drive us towards a solution that makes sense for your use case! I suspect the specific reason you need to run the container as your user is so that the file permissions for your mounted volume are correct (this comment has come up before in discussion), but please let me know if there is something else in particular (e.g. container process monitoring, etc.).
I think that the issue is we’re running the container on a shared compute system, so we don’t ever want a normal user’s processes to be running as root, even if it’s “only” inside the container. Let me check w/ our admins/developers and get back to you if there are more details than that.
After further discussion w/ our HTCondor developer (HTCondor is the scheduler we’re using to orchestrate docker containers on our resource pool), it sounds like file permissions may indeed be part of the motivation:
“HTCondor always runs the container as non-root, as it provides a volume-mounted sandbox directory with the input files it brings along, and the output files that it takes back to the submitting users. A specific thing for us is we might not know at container creation time what uid we want to use at runtime.”
Does that help? Let me know if you have further questions.
Thanks @ChristinaLK! I think we have enough to make some decisions about how to move forward — I created an issue to track the progress of this. I don’t expect this to be tackled until sometime in 2018, but will update this thread if it happens sooner. Thanks so much!
