Add a note about enabling EnableLocalMode to fix an mmctl error

[amyblais]

mmctl can fail with the following error:

Error: socket file "/var/tmp/mattermost_local.socket" doesn't exists, please check the server configuration for local mode

This issue is fixed by setting EnableLocalMode to true in config.json. This resolution could be documented at the docs here: https://docs.mattermost.com/configure/configuration-settings.html#enable-local-mode.

See: https://github.com/mattermost/mattermost-server/issues/20221.

[smilster]

Thanks. This was helpful! Only setting "EnableLocalMode": true, and restarting service was not enough in my case. I guess I missed some steps during installation and messed around a little afterwards.

Eventually I solved my issue with the following steps (on Ubuntu 20.04, mattermost 7.2.0). I don't know which steps are necessary, but I hope they won't harm.

1. set "EnableLocalMode": true, in the config.json

2. delete /var/run/mattermost_local.socket if exists (I'm not sure if this is a good advice, but it worked for me)

3. give ownership and permissions to installation directory (although I did during installation) sudo chown -R mattermost:mattermost /opt/mattermost sudo chmod -R g+w /opt/mattermost

4. reset the password for the user mattermost. I used same as in config.json line "DataSource": sudo passwd mattermost

5. restart service sudo systemctl restart mattermost.service now /var/run/mattermost_local.socket reappeared with proper 0600 permissions

6. log in as user mattermost

done! mmctl --local works now

[cwarnermm]

@isacikgoz - @smilster needed to perform additional steps to enable local mode for mmctl beyond setting EnableLocalMode to true. He's kindly shared the steps he followed in this docs issue.

Can you confirm whether all users would need to perform these additional steps to enable local mode? If not all users need to perform these steps, can you comment on the conditions under which a user would need to follow these additional steps, please?

[isacikgoz]

Thanks for the ping @cwarnermm, actually we programmatically do what @smilster did :) The only key here is the owner of the process, it should be same for both mmctl and the mattermost-server. If the user doesn't have privileges to delete the socket (if it exists) it would fail. It doesn't matter changing the ownership of the /opt/mattermost as the socket file ownership is managed by the OS.

https://github.com/mattermost/mattermost-server/blob/a8154ddae01e66c1d2a4cd90401227957f09d96f/app/server.go#L1339

The actual logic is as given here:

socket := *s.platform.Config().ServiceSettings.LocalModeSocketLocation
if err := os.RemoveAll(socket); err != nil { // <- Removes file if exists (Step 2)
	return errors.Wrapf(err, i18n.T("api.server.start_server.starting.critical"), err)
}

unixListener, err := net.Listen("unix", socket) // <- Creates the socket file
if err != nil {
	return errors.Wrapf(err, i18n.T("api.server.start_server.starting.critical"), err)
}
if err = os.Chmod(socket, 0600); err != nil { // <- Check the permissions
	return errors.Wrapf(err, i18n.T("api.server.start_server.starting.critical"), err)
}

The improvement on the docs would be just a note about some debug steps; Either using same user whenever you run mattermost-server and mmctl, or, cleaning up the socket file before switching to a new user.

[cwarnermm]

Closed via https://github.com/mattermost/docs/pull/6026