[Solved] Permission Denied, but Permissions are Correct

Troubleshooting
1

Summary

Followed official documentation, to the point.

Basically, when deploying the standard Mattermost docker-compose.yml setup, as described in the official documentation, the setup is plagued with non-sensical permission denied errors.
All folders have been repeatedly set to the correct UID and GID, as portrayed in the documentaiton. Yet, the error still continues to appear.

Steps to reproduce

  1. Follow Deploy Mattermost via Docker - Mattermost documentation.
  2. Get permission denied for absolutely no reason.

Expected behavior
Setup, as displayed here, should not yield any permission issues.

Observed behavior
Error

Error: failed to load configuration: open /mattermost/config/config.json: permission denied
Usage:
  mattermost [flags]
  mattermost [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  db          Commands related to the database
  export      Export data from Mattermost
  help        Help about any command
  import      Import data.
  jobserver   Start the Mattermost job server
  server      Run the Mattermost server
  version     Display version information

Flags:
  -c, --config string   Configuration file to use.
  -h, --help            help for mattermost

Use "mattermost [command] --help" for more information about a command.

Using most recent docker-compose.yml from official repository.

# https://docs.docker.com/compose/environment-variables/

version: "2.4"

services:
  postgres:
    image: postgres:${POSTGRES_IMAGE_TAG}
    restart: ${RESTART_POLICY}
    security_opt:
      - no-new-privileges:true
    pids_limit: 100
    read_only: true
    tmpfs:
      - /tmp
      - /var/run/postgresql
    volumes:
      - ${POSTGRES_DATA_PATH}:/var/lib/postgresql/data
    environment:
      # timezone inside container
      - TZ

      # necessary Postgres options/variables
      - POSTGRES_USER
      - POSTGRES_PASSWORD
      - POSTGRES_DB

  mattermost:
    depends_on:
      - postgres
    image: mattermost/${MATTERMOST_IMAGE}:${MATTERMOST_IMAGE_TAG}
    restart: ${RESTART_POLICY}
    security_opt:
      - no-new-privileges:true
    pids_limit: 200
    read_only: ${MATTERMOST_CONTAINER_READONLY}
    tmpfs:
      - /tmp
    volumes:
      - ${MATTERMOST_CONFIG_PATH}:/mattermost/config:rw
      - ${MATTERMOST_DATA_PATH}:/mattermost/data:rw
      - ${MATTERMOST_LOGS_PATH}:/mattermost/logs:rw
      - ${MATTERMOST_PLUGINS_PATH}:/mattermost/plugins:rw
      - ${MATTERMOST_CLIENT_PLUGINS_PATH}:/mattermost/client/plugins:rw
      - ${MATTERMOST_BLEVE_INDEXES_PATH}:/mattermost/bleve-indexes:rw
      # When you want to use SSO with GitLab, you have to add the cert pki chain of GitLab inside Alpine
      # to avoid Token request failed: certificate signed by unknown authority
      # (link: https://github.com/mattermost/mattermost-server/issues/13059 and https://github.com/mattermost/docker/issues/34)
      # - ${GITLAB_PKI_CHAIN_PATH}:/etc/ssl/certs/pki_chain.pem:ro
    environment:
      # timezone inside container
      - TZ

      # necessary Mattermost options/variables (see env.example)
      - MM_SQLSETTINGS_DRIVERNAME
      - MM_SQLSETTINGS_DATASOURCE

      # necessary for bleve
      - MM_BLEVESETTINGS_INDEXDIR

      # additional settings
      - MM_SERVICESETTINGS_SITEURL

# If you use rolling image tags and feel lucky watchtower can automatically pull new images and
# instantiate containers from it. https://containrrr.dev/watchtower/
# Please keep in mind watchtower will have access on the docker socket. This can be a security risk.
#
#  watchtower:
#    container_name: watchtower
#    image: containrrr/watchtower:latest
#    restart: unless-stopped
#    volumes:
#      - /var/run/docker.sock:/var/run/docker.sock
2

Remember, the permissions you see on your system are not what are seen inside of the container! If you docker exec -it <container> bash and do an ls -l /mattermost/config/config.json you may see something different than you expect to see.

1 Like
3

Thank you for the response.

The permissions were the same.

I just realised, that I accidentally set up a too strict permission set for the directories created via Ansible. They weren’t executable, i.e. the owner wasn’t allowed to join.
(It does not answer the question, why chmod run by some entrypoint script did not fix that, but that’s a story for another day…)

I fixed the issue by updating the related Ansible tasks to create directories with the permission code 700. This made those folders executable and everything started working.

I just looked at the ownership the whole time and kind of took it for granted, that the containers’ entrypoint scripts already chmod the owned folders themselves, to always keep the permissions, as needed.

This might be something, the Mattermost Docker image might improve upon. Use chmod on start.