[SOLVED] Email notification settings don't stick

I’ve just installed MM3.9.0 in AWS using Docker. I’m trying to enable email notifications. At this stage I mainly just want to verify users via email. I have two possibilities: (a) a Postfix server in our private subnet (no authentication required), and (b) Amazon SES (authnz over StartTLS).

I’ve tried both of these with exactly the same effect:
the test email succeeds
when I save, the settings appear in my config.json file
the UI reverts the notifications enablement to “false”
the UI retains all the other settings
if I stop and restart the server, all settings reappear except notifications are still disabled
if I log out and log in again, all settings reappear except notifications are still disabled
config.json still has all settings and email is still enabled
if I re-enable in the UI and re-save, none of the above changes

It seems as though settings are correctly saved to disk, but the enablement is masked out to false when settings are loaded. No verification email ever reaches me, but I can test and test and the tests always come through.

1 Like

Hi @dgc - I’m not sure what’s going on with the email setting UI not matching the config, but for the email verification can you check that “Require Email Verification” under System Console > Security > Sign Up is set to true?

Thanks for your response. Yes, that option is set to true.

Another datum: when I tail the log and “resend notification” on my non-admin user’s signin page, I see this:

[2017/06/13 00:40:46 UTC] [DEBG] Email batching job ran. 0 user(s) still have notifications pending.
[2017/06/13 00:40:53 UTC] [DEBG] Email batching job starting. Checking for pending emails every 30 seconds.
[2017/06/13 00:40:53 UTC] [DEBG] /api/v3/admin/config
[2017/06/13 00:41:04 UTC] [DEBG] POST - /api/v4/users/email/verify/send
[2017/06/13 00:41:07 UTC] [DEBG] /should_verify_email
[2017/06/13 00:41:08 UTC] [DEBG] GET - /api/v4/config/client
[2017/06/13 00:41:08 UTC] [DEBG] GET - /api/v4/license/client
[2017/06/13 00:41:10 UTC] [DEBG] POST - /api/v4/users/email/verify/send
[2017/06/13 00:41:23 UTC] [DEBG] Email batching job ran. 0 user(s) still have notifications pending.

I see that the db_1 container appears to have exim4. I know Postfix and Sendmail well, but not Exim. However, at a glance, it doesn’t look like the exim configuration has been updated with any of my transport settings, and no exim daemon seems to be running. I can’t tell that any MTA is running in either of the other containers.

I had the same issue but it was fixed by specifying Docker image version.

services:
  mattermost:
    image: mattermost/mattermost-prod-app:3.9.0

I found image size is different between 3.9.0 and latest. The latest may be unstable.
https://hub.docker.com/r/mattermost/mattermost-prod-app/tags/

Thanks for this tip. I was following the instructions at https://docs.mattermost.com/install/prod-docker.html#production-docker-setup-on-ubuntu, which involve a git clone and docker-compose build and apparently do result in a latest product. I started over, but after cloning I did a git checkout 3.9.0 to detach the 3.9.0 tagged release. This version works more as advertised. With the same configuration, email now goes and the email notification setting sticks when I change it.

To prove I hadn’t screwed anything up I did the following:

git clone https://github.com/mattermost/mattermost-docker.git
cd mattermost-docker
git checkout 3.9.0
docker-compose build
# modify the Dockerfile to also `apt-get install libffi-dev libssl-dev`, which are missing in the 3.9.0 tagged dockerfile
docker-compose up -d
# create my initial admin user
docker-compose down
cp saved_config.json volumes/app/mattermost/config/config.json
docker-compose up -d
# as admin, generate a signup link
# visit that link in another browser
# sign in

Hope this helps the dev team or another thwarted adopter.

Hello,

I have just experienced the same problem today, and spent some time looking into it. The fact that it worked for @dgc when using the tagged release 3.9.0 was a hint that something changed in the meantime, and I think I have figured it out. Here’s the culprit: https://github.com/mattermost/mattermost-docker/commit/6512a09608c5a3566aa973c9359451d37023ea61#diff-7bfa124914e2e8affd23055295839cb8R14

This line adds an environment variable for the Email Notification option, set to false by default. I assume what happens is that this env variable always applies, whatever the actual value is in config.json.

Solution: add - MM_EMAILSETTINGS_SENDEMAILNOTIFICATIONS=true to the environment namespace of the app service in your docker-compose.yml file, and re-run the service.

I have filed an issue on github: https://github.com/mattermost/mattermost-docker/issues/140

1 Like

https://github.com/mattermost/mattermost-docker/commit/87b26e155e1242972fad8d31381089631510e3dc fixes this for me using HEAD. Thanks all!