3

Let's say I have a Docker container that holds some data. I want this data to persist - if the container is stopped, removed, upgraded etc. I still want the data to be in an accessible location on the host OS filesystem.

Currently, my solution is to create a directory /srv/service-name on my host (I use Ubuntu 14.10) and then run my service with the -v /srv/service-name:/path/inside/container argument.

By trial and error I found out that sometimes the container is unable to write to this, because it doesn't have the right permissions. I found this question where data-only containers are given as a solution. Well, I don't want to use containers because it seems needlessly complicated for what I am doing. I'd rather just keep mounting the directories with -v.

So, how can I set the right permissions on the directory I am mounting?

Community
  • 1
  • 1
Superbest
  • 25,318
  • 14
  • 62
  • 134

1 Answers1

5

So, how can I set the right permissions on the directory I am mounting?

There's nothing special about Docker volumes: in order for a process to write to a directory, the ownership and permissions on that directory need to allow writing.

By default, processes in a Docker container are running as root and are able to write pretty much anywhere, absent additional restrictions imposed by something like selinux.

If you have a process in a container that is not running as root, it is up to you to ensure that any volumes you expose to the container have appropriate ownership. You have basically two choices:

  1. Set the permissions on the source directory from the host.

    If your process is running as user httpd inside a container, you will need to determine the numeric UID associated with that user and then chown the directory to the appropriate user ID. E.g., if user httpd inside the container is UID 48, then on the host:

    chown 48 /srv/webserver

    As you probably expect, this means that running ls -l on the host may return a different username, because there is no guarantee that UIDs in the container match UIDs on the host.

  2. Set permissions in an ENTRYPOINT script

    If you are building your own images, you can run containers as root, and then have an ENTRYPOINT script that is responsible for (a) setting ownership and permissions and then (b) switching to a non-privileged user to run your CMD.

larsks
  • 277,717
  • 41
  • 399
  • 399