2

I'm developing a PHP 7.1 web application using the following:

  • Symfony 3.2
  • Docker Compose 1.12.0
  • Ubuntu 16.04 x64

When running docker-compose up -d, my bind mounted project directory's owner and group are changed to root. Thus, whenever I try to commit a change or pull from my remote with git pull, I'll see the following:

error: unable to unlink old 'gulpfile.js' (Permission denied)
fatal: Could not reset index file to revision 'HEAD^'.

Changing the project directory's owner and group back to my user removes the error. Is there an easier way to prevent these user permission conflicts while developing with Docker Compose?

EDIT
Here is an overview of my current directory structure:

dockerComposeAndProjectDir/
|-- projectDirectory/
|-- dockerComposeDirectory/
    |-- docker-compose.yml
Community
  • 1
  • 1
lolsky
  • 428
  • 2
  • 14

1 Answers1

1

As mentioned in this docker (err... moby!) issue

If you chown the volume (on the host side) before bind-mounting it, it will work.
In that case, you could do:

mkdir /tmp/www
chown 101:101 /tmp/www
docker run -v /tmp/www:/var/www ubuntu stat -c "%U %G" /var/www

(Assuming that 101:101 is the UID:GID of the www-data user in your container.)

Another possibility is to do the bind-mount, then chown inside the container.

Using volumes just works assuming the image has data at the path your mounting to.
Using binds uses the host path's UID/GID.
UID/GID in the container is the same as UID/GID on the host... even if user/group names don't match, UID/GID is what matters here.

I refered the OP lolsky to phpdocker-io/base-images/php/7.1 Dockerfile.
The OP concludes:

The php:7.1-fpm Dockerfile indicates that the php-fpm service would be run as www-data, so I was incorrect about the container's user.
Chowning the volume after the initial bind mount seems to work.
Anytime the volume needs to be recreated by Docker Compose, I have to chown it again, which gets a little annoying, but it does solve my issue.

lolsky
  • 428
  • 2
  • 14
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I tried chowning the volume from my host using the UID and GID for my user before running `docker-compose up -d`. However, after the up command ran my bind mounted project directory still got root as the owner and group. – lolsky Apr 24 '17 at 16:31
  • Looking at the issue you posted, I'm not sure anyone has found a solution other than manually changing the owner/group using an entrypoint script after the container has mounted the volume. – lolsky Apr 24 '17 at 16:45
  • @ChristianElowsky You need to make sure the uid/gid are the same in the host and in the container. – VonC Apr 24 '17 at 20:42
  • @ChristianElowsky I thought it was working since you accepted the answer?. – VonC Apr 25 '17 at 21:11
  • I'm using a _PHP7.1-fpm_ container, which runs as the **root** user. For my _nginx_ container, it was easy to make sure the UID of the **www-data** user was the same as my host user UID. I put `RUN usermod -u 1000 www-data` in the Dockerfile right before `CMD`. However, putting `RUN usermod -u 1000 root` before `CMD` for the _PHP7.1-fpm_ container fails with `usermod: user root is currently used by process 1` `ERROR: Service 'php' failed to build: The command '/bin/sh -c usermod -u 1000 root' returned a non-zero code: 8`, since **root** is probably already in use by Docker. – lolsky Apr 25 '17 at 21:20
  • Your initial answer did work for volumes mounted by my _nginx:latest_ container which runs as **www-data**, but not _php:7.1-fpm_ which runs as **root**. For containers that must run as **root**, this issue is still unresolved. – lolsky Apr 25 '17 at 21:31
  • @ChristianElowsky Can you check if https://github.com/phpdocker-io/base-images/blob/master/php/7.1/fpm/Dockerfile contains any clues? – VonC Apr 25 '17 at 21:33
  • The *php:7.1-fpm* Dockerfile indicates that the php-fpm service would be run as **www-data**, so I was incorrect about the container's user. Chowning the volume after the initial bind mount seems to work. Anytime the volume needs to be recreated by Docker Compose, I have to chown it again, which gets a little annoying, but it does solve my issue. I'll look into other possibilities in the Github issue you linked to ensure the bind mount is owned by the host user regardless of whether or not it's being recreated. – lolsky Apr 25 '17 at 23:51