403 error accessing admin

[SJS28092018]

Hi, would appreciate any help. Have just setup mailu on a coreOS VM. Have set TLS_FLAVOR to notls to ensure I don't have a Cert issue and docker-compose seems to start OK but when I try to access admin (172.16.1.42/admin), I get a nginx 403 error.

Logs provided below

core@codmz01 /mailu $ docker-compose logs -f --tail=5
Attaching to mailu_imap_1, mailu_smtp_1, mailu_antispam_1, mailu_front_1, mailu_admin_1, mailu_webmail_1, mailu_fetchmail_1, mailu_webdav_1, mailu_antivirus_1, mailu_redis_1
imap_1       | Sep 08 11:58:19 master: Info: Dovecot v2.2.34 (874deae) starting up for imap, pop3, lmtp, sieve
imap_1       | Sep 22 06:45:28 master: Info: Dovecot v2.2.34 (874deae) starting up for imap, pop3, lmtp, sieve
imap_1       | Sep 28 09:25:55 master: Info: Dovecot v2.2.34 (874deae) starting up for imap, pop3, lmtp, sieve
imap_1       | Sep 28 10:03:04 master: Info: Dovecot v2.2.34 (874deae) starting up for imap, pop3, lmtp, sieve
imap_1       | Sep 28 10:25:59 master: Info: Dovecot v2.2.34 (874deae) starting up for imap, pop3, lmtp, sieve
smtp_1       | postfix/master[51]: daemon started -- version 3.2.4, configuration /etc/postfix
smtp_1       | rsyslogd:  [origin software="rsyslogd" swVersion="8.31.0" x-pid="6" x-info="http://www.rsyslog.com"] start
smtp_1       | postfix/master[51]: daemon started -- version 3.2.4, configuration /etc/postfix
smtp_1       | rsyslogd:  [origin software="rsyslogd" swVersion="8.31.0" x-pid="6" x-info="http://www.rsyslog.com"] start
smtp_1       | postfix/master[51]: daemon started -- version 3.2.4, configuration /etc/postfix
antispam_1   | 2018-09-28 10:26:00 #7(controller) <dgrnf5>; lua; lua_redis.lua:811: uploaded redis script to 172.18.0.4 with id 2, sha: cbfe3bb48b9884e2aee097935a0b01f32dd05185
antispam_1   | 2018-09-28 10:26:00 #7(controller) <dgrnf5>; lua; lua_redis.lua:811: uploaded redis script to 172.18.0.4 with id 7, sha: fa73e70c19b92af4b51b5508fbfd8ef9d1e8a7b8
antispam_1   | 2018-09-28 10:26:00 #7(controller) <dgrnf5>; lua; lua_redis.lua:811: uploaded redis script to 172.18.0.4 with id 1, sha: 5476f74ad48cca32a6b75ab3b7ff8e54739d139e
antispam_1   | 2018-09-28 10:26:00 #7(controller) <3nxzfe>; monitored; rspamd_monitored_dns_cb: DNS query blocked on multi.uribl.com (127.0.0.1 returned), possibly due to high volume
antispam_1   | 2018-09-28 10:26:04 #7(controller) <pr5857>; map; http_map_finish: data is not modified for server updates.rspamd.com, next check at Fri, 28 Sep 2018 10:31:04 GMT
front_1      | 2018/09/28 10:26:09 [notice] 9#9: exit
front_1      | 2018/09/28 10:26:09 [notice] 6#6: signal 17 (SIGCHLD) received from 9
front_1      | 2018/09/28 10:26:09 [notice] 6#6: worker process 9 exited with code 0
front_1      | 2018/09/28 10:26:09 [notice] 6#6: signal 29 (SIGIO) received
front_1      | 10.10.1.44 - - [28/Sep/2018:10:26:20 +0000] "GET /admin HTTP/1.1" 403 162 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0"
redis_1      | 1:M 28 Sep 10:25:56.995 # Server initialized
redis_1      | 1:M 28 Sep 10:25:56.995 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1      | 1:M 28 Sep 10:25:56.995 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis_1      | 1:M 28 Sep 10:25:56.995 * DB loaded from disk: 0.000 seconds
redis_1      | 1:M 28 Sep 10:25:56.995 * Ready to accept connections
admin_1      | [2018-09-28 10:26:06 +0000] [14] [INFO] Using worker: sync
admin_1      | [2018-09-28 10:26:06 +0000] [18] [INFO] Booting worker with pid: 18
admin_1      | [2018-09-28 10:26:06 +0000] [19] [INFO] Booting worker with pid: 19
admin_1      | [2018-09-28 10:26:06 +0000] [20] [INFO] Booting worker with pid: 20
admin_1      | [2018-09-28 10:26:06 +0000] [21] [INFO] Booting worker with pid: 21
fetchmail_1  |   File "/fetchmail.py", line 90, in <module>
fetchmail_1  |     run(connection, cursor, debug)
fetchmail_1  |   File "/fetchmail.py", line 44, in run
fetchmail_1  |     """)
fetchmail_1  | sqlite3.OperationalError: no such table: fetch
antispam_1   | 2018-09-28 10:26:43 #7(controller) <3nxzfe>; monitored; rspamd_monitored_dns_cb: DNS query blocked on multi.uribl.com (127.0.0.1 returned), possibly due to high volume
antispam_1   | 2018-09-28 10:27:08 #7(controller) <3nxzfe>; monitored; rspamd_monitored_dns_cb: DNS query blocked on multi.uribl.com (127.0.0.1 returned), possibly due to high volume
antispam_1   | 2018-09-28 10:27:20 #7(controller) <3nxzfe>; monitored; rspamd_monitored_dns_cb: DNS query blocked on multi.uribl.com (127.0.0.1 returned), possibly due to high volume
antispam_1   | 2018-09-28 10:27:20 #7(controller) <3nxzfe>; monitored; rspamd_monitored_propagate_error: invalid return on resolving multi.uribl.com, disable object
antispam_1   | 2018-09-28 10:27:20 #7(controller) <dgrnf5>; cfg; rspamd_worker_monitored_on_change: broadcast monitored update for 3nxzfegumbi67tq1kjtuupxnd493zxt: dead
antispam_1   | 2018-09-28 10:27:20 #6(rspamd_proxy) <dgrnf5>; cfg; rspamd_worker_monitored_handler: updated monitored status for 3nxzfegumbi67tq1kjtuupxnd493zxt: dead
front_1      | 10.10.1.44 - - [28/Sep/2018:10:27:48 +0000] "GET /admin HTTP/1.1" 403 162 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0"

Thanks

[SJS28092018]

Resolved.
Issue seemed to be changing TLS_FLAVOR from letsencryp to notls required docker-compose pull to reset. One step forward :=)

[muhlemmer]

Actually, for changes in .env to take effect you need to run:

docker-compose down && docker-compose up -d

The docker-compose pull might have worked if there where new images available and docker-compose recreated the services. This might not work if there are no new images for download.

Also, I would like to note that I found that a docker-compose restart does not re-evaluate .env.

[SJS28092018]

Hi Tim, That's great. Thanks you for your help. Steve Smith

…

On Fri, Oct 12, 2018 at 7:44 PM Tim Möhlmann ***@***.***> wrote: Actually, for changes in .env to take effect you need to run: docker-compose down && docker-compose up -d The docker-compose pull might have worked if there where new images available and docker-compose recreated the services. This might not work if there are no new images for download. Also, I would like to note that I found that a docker-compose restart does not re-evaluate .env. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#615 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AppfosaSsUETBc8dIPc173OFk8xa_GZfks5ukFZygaJpZM4W-Qet> .