Skip to content
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

Files owned by unknown user in container #15

Closed
jom opened this issue Mar 25, 2015 · 7 comments
Closed

Files owned by unknown user in container #15

jom opened this issue Mar 25, 2015 · 7 comments

Comments

@jom
Copy link

jom commented Mar 25, 2015

Is there any way to map or mount a container volume's files to a user in the container (just locally--say "www-data")? Mounting my local project files to /var/www in my container and nginx can't write to it.

OS X 10.10.2 / Dinghy 2.2.2 / Docker 1.5.0 / Vagrant 1.7.2 / VirtualBox 4.3.26

@codekitchen
Copy link
Owner

Not currently. This is a more general issue with docker volume mounts right now, not really a dinghy thing.

As I understand it, the linux kernel now has support for mapping user ids between namespaces, and docker plans to add support as well so that you can specify what a user in the container maps to on the host. Once that's all implemented, it'll be easier to deal with, but for now your options are to either run nginx as root in the container, or chown/chmod the mounted directory to give it access.

@jom
Copy link
Author

jom commented Mar 25, 2015

Things are working in boot2docker with VirtualBox Shared Folders (just slowly), but I'll keep looking.

@jom
Copy link
Author

jom commented Mar 25, 2015

In boot2docker, my home directory is mounted and owned by docker. In dinghy they are owned by an unknown user.

@codekitchen
Copy link
Owner

Yeah, virtualbox shared folders are an odd case, because they "squash" file ownership and permissions. You can see this by creating a file on the share as the root user in boot2docker -- it'll end up being owned by the "docker" user as well, not by root. This actually causes problems with using volumes in some docker containers, such as the postgres container, which aborts if it can't chown its data directory to the postgres user inside the container.

NFS enforces file permissions more strictly, and in that way is actually more like running docker directly on a linux machine. I can see how the "less correct" behavior could be desirable, but an issue like you're seeing typically means that people trying to use your container+volume directly on linux in the same way would run into the same issue.

Perhaps it's worth making this behavior configurable, It is possible to get similar squashing behavior in NFS as well (see e.g. #12). If I get some time I'll experiment further with what the consequences would be.

@codekitchen codekitchen reopened this Mar 25, 2015
@codekitchen
Copy link
Owner

@jom I think I'm starting to come around to this, after doing some further experimentation and evaluating the ways that my co-workers have been using dinghy. I have an experimental commit on master that will enable squashing on the mounted NFS volume, so that files and folders created in docker mounted volumes will end up being owned by your host machine user. See caveats at d1cf4d9

If you'd like to try it out, you can install the master revision with: brew reinstall --HEAD https://github.com/codekitchen/dinghy/raw/master/dinghy.rb. Make sure to dinghy halt first.

Note this doesn't work exactly like virtualbox file sharing, files will still show up as owned by an unknown user id inside the VM, but permissions will be applied differently. In general it'll work more like boot2docker.

@jom
Copy link
Author

jom commented Apr 14, 2015

Did a quick test with my project and it seems to work! Files created in the container have the correct owner in the host machine. I'll let you know if I run into any issues.

@codekitchen
Copy link
Owner

I've had a few people testing this for the last week, and it's working well, so I've rolled it into the latest stable release. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants