write in shared volumes docker

Question

I have a docker with a php application on it

I have a share volume, for example

/home/me/dev/site <=> /var/www/site

I can write something in my host, it will be sync with the container

if I launch

sudo docker exec test touch /var/www/site/test.txt

It works

But if my server is trying to create a file as www-data this is not working because of the rights.

Is there a way to give access to my shared volumes to www-data ?

I am using boot2docker

Does that user need write permission to the volume, or does it need the ability to execute docker (as a wrapper for managing the volume)? — scrowler, Mar 25 '15 at 00:09
the user needs to create files in the volume, not just execute files from the volume — Ajouve, Mar 25 '15 at 00:13
And does that creation and execution happen through the shell or do you have to use the `docker exec` command to do that? — scrowler, Mar 25 '15 at 00:18
No, this is a website, it can create a file when I load a page for example — Ajouve, Mar 25 '15 at 00:20
So what are the current permissions (i.e. user and group) for that folder you write to? If it's root you will probably need to `chown` it to a generic user, or create a user group that can contain both the generic/root user and the www-user, and assign that group as the owner of the folder — scrowler, Mar 25 '15 at 00:23
I have for example `drwxr-xr-x 1 1000 staff 340 Mar 24 21:52 web` in my shared folder when I execute `docker exec test ls -l /var/www/site` — Ajouve, Mar 25 '15 at 00:44

score 112 · Answer 1 · edited Dec 08 '17 at 18:18

(Bind-mounted) volumes in Docker will maintain the permissions that are set on the Docker host itself. You can use this to set the permissions on those files and directories before using them in the container.

Some background;

Permissions in Linux are based on user and group ids ('uid' / 'gid'). Even though you see a user- and group name as owner, those names aren't actually important in Linux, they are only there to make it easier for you to see who's the owner of a file (they are looked up from the /etc/passwd file).

You can set any uid/gid on a file; a user doesn't have to exist when setting those permissions. For example;

touch foobar && sudo chown 1234:5678 foobar && ls -la foobar

# UID and GID are set to 1234 / 5678, even though there's no such user
-rw-rw-r-- 1 1234 5678 0 Mar 25 19:14 foobar

Checking permissions (inside and outside a container)

As mentioned above, Docker maintains ownership of the host when using a volume. This example shows that permissions and ownership in the volume are the same outside and inside a container;

# (First create a dummy site)

mkdir -p volume-example/site && cd volume-example
echo "<html><body>hello world</body></html>" > site/index.html

# Permissions on the Docker host;

ls -n site

# total 4
# -rw-rw-r-- 1 1002 1002 38 Mar 25 19:15 index.html

# And, permissions inside a nginx container, using it as volume;

sudo docker run --rm -v $(pwd)/site:/var/www nginx ls -n /var/www

# total 4
# -rw-rw-r-- 1 1002 1002 38 Mar 25 19:15 index.html

Setting the permissions

As explained, a user doesn't have to exist in order to use them, so even if we don't have a www-data user on the Docker host, we can still set the correct permissions if we know the "uid" and "gid" of that user inside the container;

Let's see what the uid and gid of the www-data user is inside the container;

sudo docker run --rm nginx id www-data

# uid=33(www-data) gid=33(www-data) groups=33(www-data)

First check the state before changing the permissions. This time we run the nginx container as user www-data;

sudo docker run \
  --rm \
  --volume $(pwd)/site:/var/www \
  --user www-data nginx touch /var/www/can-i-write.txt

# touch: cannot touch `/var/www/can-i-write.txt': Permission denied

Next, set the permissions on the local directory, and see if we are able to write;

sudo chown -R 33:33 site

sudo docker run \
   --rm \
   --volume $(pwd)/site:/var/www \
   --user www-data nginx touch /var/www/can-i-write.txt

Success!

Thanks, you saved my day, It works well on linux. But but it doesn't work on Osx with docker-machine. Any suggestion? — Hemerson Varela, Mar 03 '16 at 21:20
That's a great explanation, thanks. But what if we want to use different UID/GID on a host machine and inside a container? For example `33` could be a legitimate user inside a container, but could be an "evil person" on a host machine. Also, I want for all files to belong to my user account on a host machine and not to some mysterious user `33`. — Slava Fomin II, Feb 11 '19 at 22:25
That's not possible, unless you're using something like `shiftfs` (https://lwn.net/Articles/687354/). If you're bind-mounting files, files inside the container are _the same files_ as the files outside of the container, so changing permissions on those files would change the permissions on the host as well. — thaJeztah, Feb 14 '19 at 00:29
What if the uid of the container clashes with the uid of an existing user in the host? You'll end up giving them access to it. Also, you're setting some dangling uids in your host system that only make sense for the container. For these reasons I think it's better to do it the other way around: setting the uid of the container to match the one of the host or make use of the "docker" group on linux — disklosr, May 14 '19 at 13:49
> I think it's better to do it the other way around: setting the uid of the container to match the one of the host or make use of the "docker" group on linux The `docker` group should not be used as it provides access to the docker socket (API access). As to matching the container to run as the current user; The scenario described here is most useful for development situations (working on files outside of the container, but giving the container access), however, — thaJeztah, May 22 '19 at 13:51
making the container use a different than it is designed to run on will make your development situation differ more from the production situation (you should not use bind-mounts in production), which may cause other headaches down the road. — thaJeztah, May 22 '19 at 13:51

score 47 · Answer 2 · edited Mar 20 '16 at 19:23

47

Add the following lines to your dockerfile and rebuild your image

RUN usermod -u 1000 www-data
RUN usermod -G staff www-data

edited Mar 20 '16 at 19:23

Tunaki

125,519
44
317
399

answered Mar 20 '16 at 19:20

István Döbrentei

880
10
18

3

Perfect! That is what I've been looking for. http://linux.die.net/man/8/usermod docs for this command. Basically www-data's user id is changed to 1000 and it's added to staff group. Why 1000 or staff? Run `docker exec -it CONTAINER_NAME_OR_ID bash` Once in run `ls -la /var/www` you will see ex. `drwxr-xr-x 1 1000 staff 238 Aug 20 20:14 html` – Krzysztof Boduch Aug 20 '16 at 20:23
This works for me on my Ubuntu desktop because my uid is 1000. If you're not the first user account (which gets 1000 by default) you'll need to replace 1000 with your uid. – Ethan Hohensee Apr 08 '18 at 14:03

score 0 · Answer 3 · answered Feb 18 '22 at 21:51

We are seeing a problem where php-fpm on Windows cannot write to files under /var/www/html, but Mac can. Kind of a variation on the original author's issue.

I am using Docker Desktop 4.4.2 on Mac Mojave (10.14.6). I have colleagues running Docker Desktop on Windows 10.

Our Docker container is using the php:7.1.33-fpm-alpine image.

We have a host folder mapped into the docker container at /var/www/html.

The www.conf under /usr/local/etc/php-fpm.d has the user, group, listen.user and listen.group all set to www-data.

On the Mac, php-fpm has no problem writing to the files under /var/www/html.

On Windows, php-fpm cannot write to the files under /var/www/html.

I observe something strange on the Mac. The ownership of files in the shared volume appear to change based upon the user I am logged into the container with.

If I log into the container with docker exec -it ideas-wordpress-1 /bin/sh and I list the files in /var/www/html with ls -l the files are all owned by root:root with the permissions rw-r--r--.

If I change the shell for the www-data user from /sbin/nologin to /bin/sh in /etc/passwd, and I su - www-data, when I list the files in the /var/www/html folder they are now owned by www-data:www-data with the permissions rw-r--r--.

On Windows, it's a little different.

If I log into the container with docker exec -it ideas-wordpress-1 /bin/sh and I list the files in /var/www/html with ls -l the files are all owned by root:root with the permissions -rwxrwxrwx.

If I change the shell for the www-data user from /sbin/nologin to /bin/sh in /etc/passwd, and I su - www-data, when I list the files in the /var/www/html folder they are now owned by root:root with the permissions -rwxrwxrwx. They didn't change.

I believe that this is why PHP-FPM can write to files in a mounted volume on Mac and not on Windows.

I wonder if we could get the Docker maintainers to modify docker for Windows to behave like it does on the Mac.

write in shared volumes docker

3 Answers3

Checking permissions (inside and outside a container)

Setting the permissions

Linked