Deploying into Docker for AWS swarm with EBS mounted volumes

[michaelmedellin]

Hi, I'm working to deploy Mattermost into a Docker Swarm in AWS with volumes backed by EBS for data persistence. Docker for AWS provides a cloudstor:aws plugin that provides a volume driver for mounting EFS and EBS volumes. However, cloudstor:aws mounts the EBS volume in the container with root ownership and I run into this issue when the container tries to start:

/entrypoint.sh: line 82: can't create /mattermost/config/config.json.tmp: Permission denied

ls -la within the /mattermost directory of the mattermost-app container

drwxr-xr-x    3 root     root          4096 Aug 25 18:58 config
drwxr-xr-x    3 root     root          4096 Aug 25 18:58 data
drwxr-xr-x    3 root     root          4096 Aug 25 18:59 logs
drwxr-xr-x    3 root     root          4096 Aug 25 18:59 plugins

The README explains that the container executes as the mattermost user, so it makes sense why I'm getting a permission denied error. The entrypoint script doesn't have permission to modify these directories. At this point, I'm unsure how to change the mount ownership programmatically so I can proceed with my deploy.

Has anyone run into a similar issue before and found a simple way to work around? Thanks very much.

Here are the relevant portions of docker-compose.yml

volumes:
  mattermost-config:
    driver: "cloudstor:aws"
    driver_opts:
      backing: relocatable
      ebstype: gp2
      size: 20
  mattermost-data:
    driver: "cloudstor:aws"
    driver_opts:
      backing: relocatable
      ebstype: gp2
      size: 200
  mattermost-logs:
    driver: "cloudstor:aws"
    driver_opts:
      backing: relocatable
      ebstype: gp2
      size: 20
  mattermost-plugins:
    driver: "cloudstor:aws"
    driver_opts:
      backing: relocatable
      ebstype: gp2
      size: 20

services:
  mattermost-app:
    image: app
    build: 
      context: app
    restart: unless-stopped
    ports:
      - "8000:8000"
    volumes:
      - mattermost-config:/mattermost/config:rw
      - mattermost-data:/mattermost/data:rw
      - mattermost-logs:/mattermost/logs:rw
      - mattermost-plugins:/mattermost/plugins:rw

[pichouk]

I'm not an AWS user, but as I understand your issue, I guess it can be solved by changing the UID/GID of the Mattermost process. Try to build the app image with PUID and GUID args both set to 0, maybe it will help.

[michaelmedellin]

@pichouk appreciate the reply—I tried that and when rebuilding the images I received an error saying GID 0 was already in use. Looking for the exact error and will edit when I locate.

[michaelmedellin]

@pichouk I ended up switching USER mattermost to USER root in the dockerfile for this to function. After doing this, it worked fine, as expected.

That said, I do agree it's not best practice to run as root in production. If anyone has suggestions here how to avoid changing to USER root for the dockerfile, I'd be really appreciative of tips.

Being able to leverage persistent cloud storage for availability is a critical use case for me.