docs
docs copied to clipboard
Add a note about enabling EnableLocalMode to fix an mmctl error
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.
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.
-
set
"EnableLocalMode": true,
in theconfig.json
-
delete
/var/run/mattermost_local.socket
if exists (I'm not sure if this is a good advice, but it worked for me) -
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
-
reset the password for the user mattermost. I used same as in
config.json
line"DataSource":
sudo passwd mattermost
-
restart service
sudo systemctl restart mattermost.service
now/var/run/mattermost_local.socket
reappeared with proper 0600 permissions -
log in as user mattermost
done! mmctl --local
works now
@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?
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.
Closed via https://github.com/mattermost/docs/pull/6026