-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permission denied error when mounting /export/ directory to local disk #68
Comments
Make sure that things under |
The directory is created entirely by the the docker container, it doesn't exist at all prior to executing |
@lparsons can you provide me with more informations? Docker version? kinematic? Galaxy Docker version? I haven't seen this before. Thanks and sorry for the trouble! |
I ran into this error yesterday with boot2docker/docker version 1.6.1. Today, there was an update to boot2docker/docker version 1.7 and I'm running into the same problem:
I am not using Kinematic. I don't know how to determine the Galaxy Docker version, but it was freshly downloaded yesterday and again today. |
PermissionsDocker Container
Boot2Docker VM
OSX Host
|
I'm thinking this is the same issue I had with sharing /export between my VirtualBox VM (either Kitematic Boot2Docker or Vagrant Ubuntu) and my Windows host. Virtual machine shared folders commonly have problems keeping uid/gid straight between the host and guest. As you see in your B2D VM's ls, the shared folder is mapped with docker:staff (1000:50). Your Docker container has the staff group but not the docker user. But that doesn't really matter, because those things should be owned by the galaxy user (1450 by default) and postgres (default varies). I just submitted a patch to Bjorn that allows you to configure what the postgres user's UID/GID will be in the docker container (default 1550). Then, in the VM, you make sure to map /export/postgresql with 1550:1550, and /export/galaxy-central and /export/shed_tools with 1450:1450. /export/var should be mounted with root:root. In Kitematic on Windows, I couldn't tell it what UID/GID to use for the mounts, so I ended up having to use Vagrant Ubuntu and now it's working. |
xref: #71 |
@bgruening I've been having the same problem and unfortunately #71 doesn't solve it for me. I believe the root cause is Docker and boot2docker/boot2docker#581 . It seems that it is not possible to change the owner of the /export directories from within the VM (or a container running in the VM) and so postgres refuses to start. If I ssh into the container (see Problem #3) I can see the directories properly mounted under /export, but they are all owned by docker:staff and any attempt to Another (almost) related problem is that the
Everything else under /export is being populated correctly so I don't know what is special about /export/galaxy-central/database. If I create the directories before running Docker at least I get to the "Galaxy won't start because Postgres isn't running" problem. Otherwise Galaxy won't start due to the missing |
@ksuderman which UID/GID does your postgres user have? Are you running |
Sorry @bgruening, I should have mentioned that I have been basing my images on galaxy-stable:dev. I just tried 15.07 image and the problems are still there. The postgres user is 1550:1550 and the galaxy user is 1450:1450 (see below). However, I have made progress. To "fix" (hack around) the "permission denied" problems I cloned the docker-galaxy-stable repo and changed the GALAXY_UID and GALAXY_GID to 1000 (the docker UID in VirtualBox). This solves the problem of Galaxy not being able to create files in /export/galaxy-central/database/* directories. I had assumed Postgres wasn't starting due to permissions problems in the /export/postgresql directory, and that is sort of correct. I can start postgres with > sudo -u postgres /usr/lib/postgresql/9.3/bin/postmaster -D "/export/postgresql/9.3/main"
LOG: could not open configuration file "/export/postgresql/9.3/main/postgresql.conf": Permission denied
FATAL: configuration file "/export/postgresql/9.3/main/postgresql.conf" contains errors If I try as the galaxy user (which has now has r/w access to /export) I get: > sudo -u galaxy /usr/lib/postgresql/9.3/bin/postmaster -D "/export/postgresql/9.3/main"
FATAL: data directory "/export/postgresql/9.3/main" has group or world access
DETAIL: Permissions should be u=rwx (0700). Due to the VirtualBox/Docker/OS X bugs it is not possible to change the permissions/owner of any files/directories in the shared volume. So my workaround is to simply add With the above two changes I can now use shared volumes, however I don't think these "fixes" should be merged into docker-galaxy-stable. Another suggested work around is to remount /Users with NFS in the VBox VM, but I haven't explored that yet. |
@ksuderman this is a really great analysis. Thanks a bunch for sharing. I suppose these bugs are known to the Docker guys? I hope they fix it soon. Let me know if I can support you. What we can try is to figure out if the container is running under VBox/OS-X and squeeze in your workaround - only in this case? What do you think? @lparsons any opinion here? Sorry that I can not help much as I'm missing the a proper test environment. |
Keith, in my case, on Windows, I originally tried to share everything with NFS would fix the postgres problems for you most likely on OSX, but Winnfsd On Sun, Sep 6, 2015 at 6:41 PM, Björn Grüning notifications@github.com
|
@bgruening Yes, this turns out to be a known problem in Docker (boot2docker actually) but it seems the root cause is the way VirtualBox does shared folders so I don't know how quickly a fix will be coming. If anyone wants to test my hacks I've pushed an image to the Docker hub: FROM ksuderman/galaxy-stable:osx
... @chambm I will take look at Vagrant. Our use case right now is to develop something that can be used for course work and demos so I want to keep things as simple as possible for our users. Vagrant looks promising if it solves the permission problems. |
@bgruening I don't see an elegant solution (at least not near term). The idea of using the workaround in the VBox/OS-X case seems like a reasonable and practical solution if it works. @chambm The Vagrant idea does indeed seem promising. My main goal is to be able to quickly setup clean Galaxy environments where I can test things like tool integrations and installations. Semi-permanent would be fine in those cases. Am I understanding correctly that you are creating a |
@lparsons Check out https://github.com/chambm/bingomics-galaxy/tree/master/vagrant - it's the Vagrantfile I use for developing and testing my lab's docker-galaxy flavor. It has a lot of stuff needed for a cluster-based configuration commented out since that's a bit resource intensive. But that is a possibility. There are some shell provisioning commands to prep a fresh VM and then it runs the docker image on |
Another work around, particularly if you just want some persistence during testing and development is to mount a directory from the VM. I.E. > docker run -v /var/lib/galaxy:/export -d -p 8000:80 bgruening/galaxy-stable:dev Then use |
@ksuderman @lparsons is there anything I can do here? |
I think you can close this. There is not much you can do other than document the problem and possible work arounds. I've simply been mounting volumes I need to write to in the VirtualBox VM and then using |
@lparsons @ksuderman we have added a small section about This might be a good solution for this problem. |
Workflow par clip
NOTE: I am using boot2docker v1.6.1 on OSX 10.9.5.
Command:
docker run -p 8080:80 -v /Users/lparsons/galaxy_storage/:/export/ bgruening/galaxy-stable
Result:
/Users/lparsons/galaxy_storage/
is created on my OSX machine and populated withgalaxy_central
,postgresql
,shed_tools
andvar
directories. However, I then run into the following error:Various other logs report errors due to the directory
/export/galaxy-central/database/files
not existing.I've attempted to manually create this directory, but then I get similar errors about other directories and I wasn't ever able to get things to startup.
The text was updated successfully, but these errors were encountered: