Issue when trying to write to a mounted volume fro

Question

I'm working with a container that will be running ZooKeeper but I'm running into issues with permissions on the host volumes that I mount into my container.

This is my setup:

On the host machine (Ubuntu 14.04):

• Created a "zookeeper" system user (id=106) and group (id=111).
• Created the directory "/var/log/zookeeper" and set its ownership to zookeeper (ie. chown zookeeper:zookeeper). This is the directory that I will be mounting into my container.

Inside the container (Ubuntu 14.04):

• Also created a "zookeeper" system user (id=102) and group (id=105) which I use as the user from which to execute the command in the ENTRYPOINT.
• Create the same directory "/var/log/zookeeper" that will be mounted to and also set its ownership to zookeeper:zookeeper (although I don't think this matters).

Once I start up my container with the /var/log/zookeeper mount and I open up a shell inside of the container as the zookeeper user (that was created inside the container), I find that I get a "Permission Denied" error if I try to create a file in the mounted directory /var/log/zookeeper. When I do an "ls -l" to look at the ownership of this directory (still inside of the container) it looks something like this:

drwxr-xr-x 2  106  111   4096 Jun 30 17:18 zookeeper

The 106 and 111 in this case correspond to the zookeeper user and group ids of the host machine which I think is where the issue lies. I tried opening a shell inside of the container but this time I went in as the root user and the scenario that I described above worked perfectly fine just that root was the owner of the file that got created (which was expected).

From this I concluded that I need to either:

(a) Run the application inside of my container as the default root user instead of the zookeeper user that I create.

(b) Create a zookeeper user and group both on my host machine and inside the container whose id's are exactly the same.

Neither case is ideal because for (a), running the application as the root user could have potential security issues (from what I've read anyways), and for (b), it can be very difficult to get the id's to match due to the fact that they might already be taken by other users that were created (which you don't have any control over).

Has anyone ever dealt with something like this before? Are there other possible solutions that I might be overlooking?

Answer 1

Very important to see the difference between running a production and a development container. Afaik, there's no real issue if your Docker container runs as root, even on production. However you should never want or need to mount a volume of production. If you want to run it as a zookeeper feel free to do so.

// Edit: The more I read, the more I'm convinced there actually might be a security issue when running stuff as root, so you better not doing so on production.

The solution to try and match uid and gid is viable only for small/local project - it really does make it unportable. You can try and set an arbitrary high uid and gid and then do the same on each of your devs machines, but that doesn't mean it'll always be fine.

tl;dr: On development run chmod -R 0777 on existing files and then umask 0000 to setup permissions on files and directories created later. Then you can mount and edit your files as you please, no matter what user created it.

Answer 2

To my knowledge, user ID and group ID inside the container and on the host machine should match, in order to let the host machine to grant you permissions to the share directory.