-
Notifications
You must be signed in to change notification settings - Fork 265
Open
Description
Description
After updating to Mattermost Team Edition 10.10.1 (Docker image mattermost/mattermost-team-edition:latest), the container status is now always reported as unhealthy, although Mattermost itself is running normally and is fully accessible.
The docker inspect output for the healthcheck shows repeated panic: user: unknown userid 1003 errors. This was not happening before the update.
Healthcheck log excerpt
panic: user: unknown userid 1003
goroutine 1 [running]:
github.com/mattermost/mattermost/server/v8/cmd/mmctl/commands.init.1()
github.com/mattermost/mattermost/server/v8/cmd/mmctl/commands/auth_utils.go:49 +0x4e
Full healthcheck output example from docker inspect
"Health": {
"Status": "unhealthy",
"FailingStreak": 28592,
"Log": [
{
"Start": "2025-08-11T09:36:30.619061811+02:00",
"End": "2025-08-11T09:36:30.708679359+02:00",
"ExitCode": 2,
"Output": "panic: user: unknown userid 1003\n\ngoroutine 1 [running]:\ngithub.com/mattermost/mattermost/server/v8/cmd/mmctl/commands.init.1()\n\tgithub.com/mattermost/mattermost/server/v8/cmd/mmctl/commands/auth_utils.go:49 +0x4e\n"
}
]
}
Environment
- Docker Compose setup with
mattermostandpostgres:16as DB - Mattermost image:
mattermost/mattermost-team-edition:latest - Host OS: SLES 15 SP6
- Running as a custom user (
user: "1003:471") - Note: UID
1003is the local user on the host system that owns and has access to the/opt/docker/directories used as volumes for the containers. - Healthcheck failing continuously since updating to 10.10.1
- Mattermost web UI and API work normally despite the unhealthy status
docker-compose.yml snippet
services:
mattermost-db:
image: postgres:16
container_name: mattermost-db
hostname: mattermost-db
restart: always
environment:
POSTGRES_DB: mattermost
POSTGRES_USER: mattermostuser
POSTGRES_PASSWORD: mattermostpw
volumes:
- /opt/docker/mattermost/db:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-d", "mattermost", "-U", "mattermostuser"]
interval: 30s
timeout: 20s
retries: 3
networks:
mattermost:
ipv4_address: 172.x.x.x
mattermost:
image: mattermost/mattermost-team-edition:latest
container_name: mattermost
restart: unless-stopped
depends_on:
- mattermost-db
user: "1003:471"
environment:
MM_SQLSETTINGS_DRIVERNAME: postgres
MM_SQLSETTINGS_DATASOURCE: postgres://...
MM_BLEVESETTINGS_INDEXDIR: /mattermost/bleve-indexes
MM_SERVICESETTINGS_SITEURL: https://chat.domain.tld
TZ: Europe/Berlin
volumes:
- /opt/docker/mattermost/config:/mattermost/config
- /opt/docker/mattermost/data:/mattermost/data
- /opt/docker/mattermost/logs:/mattermost/logs
- /opt/docker/mattermost/plugins:/mattermost/plugins
- /opt/docker/mattermost/client/plugins:/mattermost/client/plugins
- /opt/docker/mattermost/indexes:/mattermost/bleve-indexes
networks:
mattermost:
ipv4_address: 172.x.x.x
proxy:
ipv4_address: 172.x.x.x
networks:
proxy:
external: true
mattermost:
internal: true
name: mattermost
ipam:
driver: default
config:
- subnet: 172.x.x.x/16Possible cause
It seems the healthcheck command (likely running mmctl) is executed in the container as a user that does not exist in /etc/passwd when a custom user: is set in Docker Compose.
This causes the panic: user: unknown userid error, leading to a failed healthcheck even though the server itself is fine.
Questions
- Is this an intended change in 10.10.1?
- Should the healthcheck be adjusted to work when the container runs as a non-root custom UID/GID?
- Or should the image add a passwd entry for the current UID to avoid the panic?
Metadata
Metadata
Assignees
Labels
No labels