Plugins Do Not Have Correct Permissions Inside A Docker Container

Summary
Plugins do not seem to be activating inside of the Mattermost Docker container due to permission denied.

Steps to reproduce
Spin up a brand new Mattermost Docker image by following the guide located on the official website. Do not use the NGINX proxy and don’t set up any of the SSO options.

Expected behavior
All plugins should be working, but Calls in particular will not launch.

Observed behavior
What happens instead is the following output when reviewing the system logs.

{"timestamp":"2023-12-03 14:17:28.903 Z","level":"warn","msg":"plugin configured with a nil SecureConfig","caller":"plugin/hclog_adapter.go:72","plugin_id":"com.mattermost.calls"}
{"timestamp":"2023-12-03 14:17:28.903 Z","level":"error","msg":"Unable to activate plugin","caller":"app/plugin.go:166","plugin_id":"com.mattermost.calls","error":"unable to start plugin: com.mattermost.calls: fork/exec plugins/com.mattermost.calls/server/dist/plugin-linux-amd64: permission denied"}
{"timestamp":"2023-12-03 14:17:29.944 Z","level":"warn","msg":"plugin configured with a nil SecureConfig","caller":"plugin/hclog_adapter.go:72","plugin_id":"focalboard"}
{"timestamp":"2023-12-03 14:17:29.945 Z","level":"error","msg":"Unable to activate plugin","caller":"app/plugin.go:166","plugin_id":"focalboard","error":"unable to start plugin: focalboard: fork/exec plugins/focalboard/server/dist/plugin-linux-amd64: permission denied"}
{"timestamp":"2023-12-03 14:17:29.980 Z","level":"error","msg":"Mail server connection test failed","caller":"app/server.go:862","error":"unable to connect: unable to connect to the SMTP server: dial tcp 127.0.0.1:10025: connect: connection refused"}

Can you post your Dockerfile?

Hi John,

I believe this is it, but if not please let me know!

# 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

That is a Dockerfile!

Check out Install Mattermost via Docker — Mattermost documentation See if that helps.

Specifically, try

docker exec -ti mattermost /bin/bash

From that terminal, you can examine logs and permissions and such within the running container.

Hi John,

It looks like the permissions are correct and I think the logs are the same from what I see on the server itself. I have pasted the output of the permissions for the folder of plugins and the mattermost user. I did follow the documentation from start to finish while downloading fresh copies of everything but no change. Can you let me know if it would be helpful to share out the permissions of the files outside of the Docker container? Thank you for your assistance on this!

mattermost@002c7826dd3f:~$ ls -l
total 280
-rw-r--r-- 1 mattermost mattermost   1239 Nov 10 19:36 MIT-COMPILED-LICENSE.md
-rw-r--r-- 1 mattermost mattermost 218333 Nov 10 19:36 NOTICE.txt
-rw-r--r-- 1 mattermost mattermost   7145 Nov 10 19:36 README.md
drwxr-xr-x 2 mattermost mattermost   4096 Nov 10 19:37 bin
drwxr-xr-x 2 mattermost mattermost   4096 Dec  3 14:14 bleve-indexes
drwxr-xr-x 1 mattermost mattermost   4096 Nov 10 19:36 client
drwxr-xr-x 2 mattermost mattermost   4096 Dec  3 14:16 config
drwxr-xr-x 2 mattermost mattermost   4096 Dec  3 14:17 data
drwxr-xr-x 2 mattermost mattermost   4096 Nov 10 19:36 fonts
drwxr-xr-x 2 mattermost mattermost   4096 Nov 10 19:36 i18n
drwxr-xr-x 2 mattermost mattermost   4096 Dec  3 14:16 logs
-rw-r--r-- 1 mattermost mattermost    628 Nov 10 19:36 manifest.txt
drwxr-xr-x 7 mattermost mattermost   4096 Dec  3 14:17 plugins
drwxr-xr-x 2 mattermost mattermost   4096 Nov 10 19:38 prepackaged_plugins
drwxr-xr-x 2 mattermost mattermost   4096 Nov 10 19:36 templates
mattermost@002c7826dd3f:~$ cd plugins
mattermost@002c7826dd3f:~/plugins$ ls
com.mattermost.apps  com.mattermost.calls  com.mattermost.nps  focalboard  playbooks
mattermost@002c7826dd3f:~/plugins$ ls -l
total 20
drwxr--r-- 4 mattermost mattermost 4096 Dec  3 14:17 com.mattermost.apps
drwxr--r-- 6 mattermost mattermost 4096 Dec  3 14:17 com.mattermost.calls
drwxr--r-- 5 mattermost mattermost 4096 Dec  3 14:17 com.mattermost.nps
drwxr--r-- 7 mattermost mattermost 4096 Dec  3 14:17 focalboard
drwxr--r-- 6 mattermost mattermost 4096 Dec  3 14:17 playbooks
mattermost@002c7826dd3f:~/plugins$ pwd

I have gone ahead and pasted the results of the permissions of the files outside of the Docker container as well. I would really appreciate any assistance on this as by this point it’s getting very confusing as to how a from scratch container with brand new images, and something that was just pulled is still having the same problem. Thank you!

/mnt/HDD_01/Docker-Compose Projects/Mattermost$ ls -al volumes/app/mattermost/plugins
total 32
drwxr-xr-x 8 2000 2000 4096 Dec  3 16:12 .
drwxr-xr-x 8 2000 2000 4096 Dec  3 16:11 ..
drwxr--r-- 4 2000 2000 4096 Dec  3 16:12 com.mattermost.apps
drwxr--r-- 6 2000 2000 4096 Dec  3 16:12 com.mattermost.calls
drwxr--r-- 5 2000 2000 4096 Dec  3 16:12 com.mattermost.nps
drwxr--r-- 6 2000 2000 4096 Dec  3 16:12 com.mattermost.plugin-channel-export
drwxr--r-- 7 2000 2000 4096 Dec  3 16:12 focalboard
drwxr--r-- 6 2000 2000 4096 Dec  3 16:12 playbooks

You have to remember that the logs from within the running container are very, very different from the logs on the host the container is running on. The container has it’s own root and UIDs and permissions structure.

You can increase logging verbosity to get some more details from Mattermost:

Hi John,

I apologize, I should have mentioned that I am referring to the logs inside of the container, not the logs on the host system. I will attempt to change the log level however and see if I can get any further details about what’s occurring. Thanks for the input and I’ll update what I find!

It appears that the logging was already set to the highest verbosity that was available. It does appear to be a problem with the external permissions of the volumes that get created. Somehow the root permissions and the 2000:2000 permissions are conflicting. I’m not sure why this is, but if I run the exact same set up out of the local user’s folder, everything works without a hitch. I’m still troubleshooting this, but progress has been made!