mmctl Fails With a Credentials Error, and Deactivated AD/LDAP Users Keep Reactivating

 

Applies to: Mattermost self-hosted deployments using AD/LDAP synchronization, where administrators run mmctl directly on the server, on any currently supported version (the exact command needed differs before and after v10.8, see below).

Symptoms: Running mmctl on the Mattermost server fails with a credentials error even when run as root, and a user deactivated through the System Console automatically becomes active again after the next AD/LDAP sync.


Problem

This is two distinct issues that are often encountered together:

First, mmctl does not treat "running as root, or any privileged user, directly on the server" as authentication. Prior to Mattermost v10.8, if no saved login credentials are found, mmctl does not automatically fall back to local mode. It looks for a saved session, does not find one, and errors out, even when run on the Mattermost server itself. From v10.8 onward, mmctl automatically assumes local mode when no credentials are found, so this manual step is no longer required on newer versions.

Second, for accounts provisioned through AD/LDAP sync, deactivating the account only inside Mattermost (via System Console or mmctl) does not stop future syncs from reactivating it. As long as the user still exists and matches the configured LDAP filter in the directory, the next AD/LDAP sync will re-enable the account in Mattermost, because sync treats "present in the directory query" as the source of truth for who should be active.

Symptoms

Error: failed to create client: cannot read user credentials, maybe you need to use login first: stat /root/.config/mmctl/config: no such file or directory
  • mmctl commands fail with a login/credentials error even when run directly on the Mattermost server as root or another privileged OS user.
  • A user deactivated through the System Console automatically reverts to an active "Member" state after the next AD/LDAP sync.

Solution

Use mmctl local mode (or log in first) to run admin commands, and remove or disable the account at the directory level, not just in Mattermost, to stop it from being resynced.

Fix the mmctl credentials error

Choose one of two options:

  1. Local mode: Confirm EnableLocalMode is set to true in config.json (this is a config-file-only setting, not available in the System Console), then restart the server if you changed it. Run commands with the --local flag, for example:

    mmctl --local user delete <username>

    On Mattermost v10.8 and later, mmctl automatically uses local mode when no saved credentials exist, so --local is typically only needed on earlier versions.

  2. Log in first:

    mmctl auth login <server-url> --name myserver --username <admin-username> --password <password>
    mmctl user delete <username>

mmctl user delete will prompt for two confirmations: whether you've taken a database backup (informational only; it does not perform a backup for you), and a final confirmation that the deletion is permanent. Both must be answered yes to proceed.

Stop an AD/LDAP-synced user from reactivating

  1. Remove or disable the user in the AD/LDAP directory itself, or adjust the LDAP filter so the account is no longer returned by the sync query.
  2. Wait for, or manually trigger, the next AD/LDAP sync. Mattermost will then deactivate the account automatically since it's no longer present in the directory results.
  3. If full removal (not just deactivation) is required afterward, run mmctl user delete using either method above.

Important: mmctl user delete is permanent and cannot be undone; take a database backup first. Deactivating or deleting a user only in Mattermost, without removing them from the directory, will not prevent them from being recreated or reactivated on the next AD/LDAP sync.

Additional Resources

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.