Compose: group_add doesn't work in version 3

[RaasAhsan]

group_add in the Docker Compose reference file is supposed to work on version 3 according to https://docs.docker.com/compose/compose-file/#groupadd, but when I have the following config:

version: '3'
services:
  logs:
      ...
      group_add: 
        - adm

I get the following error:

ERROR: The Compose file './docker-compose.production.yml' is invalid because:
Unsupported config option for services.logs: 'group_add'

NOTE: group_add works fine when I specify version 2.1.

Version Info:

→ docker version
dClient:
 Version:      17.03.0-ce-rc1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   ce07fb6
 Built:        Mon Feb 20 10:12:38 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.03.0-ce-rc1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   ce07fb6
 Built:        Mon Feb 20 10:12:38 2017
 OS/Arch:      linux/amd64
 Experimental: true

→ docker-compose version
docker-compose version 1.11.1, build 7c5d5e4
docker-py version: 2.0.2
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016

[RaasAhsan]

Also, I'd like to note the example for group_add in the docs might be wrong.

version: '2'
services:
    image: alpine
    group_add:
      - mail

A service name isn't specified.

[shin-]

Thanks for the report!

This is actually a documentation issue and should be reported there.

[RaasAhsan]

I just want some clarification, but is group_add supposed to work in version 3? If not then I guess its just a documentation fix, but this was originally about group_add not working.

[shin-]

@Agrosis Yes, group_add is not a valid configuration option in version 3 at that time.

[moble]

is not ... at that time

@shin The way you played with time in that sentence leaves me confused still. Is there some 3.x version where it does or will work? Is there any version? Is there a reason why this works in version 2 but not 3?

[shin-]

@moble as the documentation indicates, group_add was removed for version 3.x files. This was based on the fact that Swarm services originally did not support that option. Given that it's no longer the case, if you think this would be useful to have in a future version of the v3 format, please create an issue on the docker/cli repository to suggest it, or make a PR there that adds it.

[moble]

Thanks for the clarification.

[doismellburning]

Does anyone have a good workaround for this perhaps please? I can downgrade some things to version 2 but that doesn't feel great!

[moble]

I ended up adding a RUN block to my Dockerfile with the relevant groupadd, useradd, and usermod commands — being sure to switch to USER root before that block, and back to whatever user I had been after it. I guess it wouldn't be too hard to add those commands to your entrypoint or even command. It's much less elegant and less consistent, but it works.

[axel1200]

@moble hmm but if you add the group during build it does not match the host group id and hence is of no use... What can I do about this :(

[moble]

@axel1200 I'm guessing that you're referring to the fact that the mapping between user/group name and user/group id number is not necessarily the same on the host and in the container. So, for example, if you chown mysql:mysql some_file.txt in your container, it could be owned by mailman:postgres on the host machine. This is a pretty fundamental problem when using two systems to talk to the same filesystem. There are a few options — which basically come down to the fact that you need to pay more attention to the numbers than to the names.

First, simply assign the desired numbers to the user or group when you're creating them in the container, with the -u and -g options. Suppose you're creating the web user in your container. Find the id number of that user on your host using id -u web. You probably also want the group id number, which is given by id -g web. Then, your Dockerfile would have

RUN groupadd -g <uid> web
RUN useradd -u <uid> -g <gid> web

with <uid> and <gid> replaced as desired. This could conflict with an existing user/group in the container, so you might need to delete them first.

Second, you could just run commands within the container as whatever weird user/group already has the same uid and gid as the ones you need on your host. This is trickier but can be handy for one-off uses.

Third, there's the somewhat heavier-duty solution of userns-remap, which is docker's real solution to this problem.