Issue when trying to write to a mounted volume from inside a container as a non-root user

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

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.