Healthcheck failing with panic 'unknown userid 1003' since 10.10.1 update, but Mattermost runs fine

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 mattermost and postgres:16 as DB
• Mattermost image: mattermost/mattermost-team-edition:latest
• Host OS: SLES 15 SP6
• Running as a custom user (user: "1003:471")
• Note: UID 1003 is 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/16

Possible 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

1. Is this an intended change in 10.10.1?
2. Should the healthcheck be adjusted to work when the container runs as a non-root custom UID/GID?
3. Or should the image add a passwd entry for the current UID to avoid the panic?

Start by inspecting the Mattermost Docker image healthcheck and the mmctl initialization path shown at cmd/mmctl/commands/auth_utils.go:49. Reproduce the failure with the supplied Docker Compose custom UID/GID, then verify that the healthcheck succeeds for a container user absent from /etc/passwd while Mattermost remains accessible.