Mail + terminal/ssh - not working at all. Need help

[odie]

Hello

Something serious has happened to my Cloudron. I'm not exactly sure about timing (I've been away for family reasons), but my mail clients cannot connect to the Cloudron mail server at all. What's worse, I cannot connect to the SSH service of my Cloudron. It gives "connection refused", so I cannot run the cloudron-support --troubleshoot command.

What are my options? Any way to fix this?

Update: Here's the logs:

2026-08-12T08:25:44Z setup_fts: fts is disabled in config
2026-08-12T08:25:44Z setup_dovecot: Changing ownership
2026-08-12T08:25:45Z setup_haraka: Copying config template
2026-08-12T08:25:45Z setup_haraka: removing any 0 length queue files
2026-08-12T08:25:45Z setup_spamd: Changing ownership
2026-08-12T08:25:45Z Starting supervisor
2026-08-12T08:25:45Z 2026-08-12 08:25:45,765 INFO Included extra file "/etc/supervisor/conf.d/dovecot.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/haraka.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/mail-service.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/solr.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/spamd.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Included extra file "/etc/supervisor/conf.d/tika.conf" during parsing
2026-08-12T08:25:45Z 2026-08-12 08:25:45,766 INFO Set uid to user 0 succeeded
2026-08-12T08:25:45Z 2026-08-12 08:25:45,774 INFO RPC interface 'supervisor' initialized
2026-08-12T08:25:45Z 2026-08-12 08:25:45,774 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2026-08-12T08:25:45Z 2026-08-12 08:25:45,775 INFO supervisord started with pid 1
2026-08-12T08:25:46Z 2026-08-12 08:25:46,779 INFO spawned: 'dovecot' with pid 64
2026-08-12T08:25:46Z 2026-08-12 08:25:46,787 INFO spawned: 'haraka' with pid 65
2026-08-12T08:25:46Z 2026-08-12 08:25:46,794 INFO spawned: 'mail-service' with pid 66
2026-08-12T08:25:46Z 2026-08-12 08:25:46,798 INFO spawned: 'redis' with pid 67
2026-08-12T08:25:46Z 2026-08-12 08:25:46,808 INFO spawned: 'spamd' with pid 68
2026-08-12T08:25:46Z 67:C 12 Aug 2026 08:25:46.915 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. 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.
2026-08-12T08:25:46Z 67:C 12 Aug 2026 08:25:46.915 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2026-08-12T08:25:46Z 67:C 12 Aug 2026 08:25:46.915 * Redis version=8.4.0, bits=64, commit=00000000, modified=1, pid=67, just started
2026-08-12T08:25:46Z 67:C 12 Aug 2026 08:25:46.915 * Configuration loaded
2026-08-12T08:25:46Z 67:M 12 Aug 2026 08:25:46.918 * Increased maximum number of open files to 10032 (it was originally set to 1024).
2026-08-12T08:25:46Z 67:M 12 Aug 2026 08:25:46.918 * monotonic clock: POSIX clock_gettime
2026-08-12T08:25:46Z 67:M 12 Aug 2026 08:25:46.934 * Running mode=standalone, port=6379.
2026-08-12T08:25:46Z 67:M 12 Aug 2026 08:25:46.944 * Server initialized
2026-08-12T08:25:46Z 67:M 12 Aug 2026 08:25:46.945 * Ready to accept connections tcp
2026-08-12T08:25:46Z Warning: fd limit (ulimit -n) is lower than required under max. load (1024 < 1500), because of default_client_limit
2026-08-12T08:25:47Z loaded TLD files:
2026-08-12T08:25:47Z 1=1436
2026-08-12T08:25:47Z 2=7838
2026-08-12T08:25:47Z 3=3768
2026-08-12T08:25:47Z loaded 10156 Public Suffixes
2026-08-12T08:25:47Z Using iconv-lite only. To support rare encodings: npm install iconv
2026-08-12T08:25:47Z 2026-08-12 08:25:47,970 INFO success: dovecot entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-08-12T08:25:47Z 2026-08-12 08:25:47,970 INFO success: haraka entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-08-12T08:25:47Z 2026-08-12 08:25:47,970 INFO success: mail-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-08-12T08:25:47Z 2026-08-12 08:25:47,970 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-08-12T08:25:47Z 2026-08-12 08:25:47,970 INFO success: spamd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-08-12T08:25:48Z Mail service endpoint listening on http://:::3000
2026-08-12T08:25:54Z loglevel: INFO
2026-08-12T08:25:54Z log format: DEFAULT
2026-08-12T08:25:54Z Starting up Haraka version 3.1.4
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading delay_deny
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading dns-list
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading helo.checks
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading headers
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading tls
2026-08-12T08:25:54Z [INFO] [-] [core] loading tls.ini
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading spf
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading cloudron
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading rcpt_to.in_host_list
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading dkim
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading spamassassin
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading queue/smtp_forward
2026-08-12T08:25:54Z [INFO] [-] [plugins] loading limit
2026-08-12T08:25:54Z [NOTICE] [-] [server] Listening on [::0]:2525
2026-08-12T08:25:54Z [INFO] [-] [server] getting SocketOpts for SMTPS server
2026-08-12T08:25:54Z 2.0.0.127.zen.spamhaus.org. -> Error: queryA ECONNREFUSED 2.0.0.127.zen.spamhaus.org.
2026-08-12T08:25:54Z [INFO] [-] [dns-list] will re-test list zones every 30 minutes
2026-08-12T08:25:54Z [INFO] [-] [server] Creating TLS server on [::0]:2465
2026-08-12T08:25:54Z [NOTICE] [-] [server] Listening on [::0]:2465
2026-08-12T08:25:54Z [NOTICE] [-] [server] Listening on [::0]:2587
2026-08-12T08:25:54Z [INFO] [-] [cloudron] Initializing queue server on port 6000
2026-08-12T08:25:54Z [INFO] [-] [limit] connected to redis://127.0.0.1:6379/4
2026-08-12T08:25:54Z [INFO] [-] [outbound/queue] Loading outbound queue from /app/data/haraka-queue
2026-08-12T08:25:54Z [INFO] [-] [outbound/queue] Loading the queue...
2026-08-12T08:25:54Z [INFO] [-] [outbound/queue] [pid: undefined] 0 files in my delivery queue
2026-08-12T08:25:54Z [INFO] [-] [outbound/queue] [pid: undefined] 0 files in my load queue
2026-08-12T08:25:54Z [INFO] [-] [outbound/queue] [pid: undefined] 0 files in my temp fail queue

[joseph]

The mail service seems running fine. But it seem like may be all non-http ports got blocked on your server (if you are unable to connect to SSH port and the Email ports) ? Did some new firewall deploy? Networking change?

[james]

Hello @odie

Let's start with the good old, have you attempted to restart your server to resolve the issue?

@odie said:

What's worse, I cannot connect to the SSH service of my Cloudron. It gives "connection refused", so I cannot run the cloudron-support --troubleshoot command.

Why this is happening I could only assume which brings us nowhere.
Best thing to do is accessing the terminal from your provider and login with root and the password and then figure out why you can't access via ssh.

When a server restart does not help, maybe increase the memory of your mail service?

---

There is this line:

2.0.0.127.zen.spamhaus.org. -> Error: queryA ECONNREFUSED

Which might be a hint towards a DNS resolution issue and if DNS name resolution in that container might be broken at a level below, that could be a plausible explanation for "mail clients cannot connect", but treat that as an assumption and not a statement/analysis.

If you have access to ssh again or via the root terminal of your provider you could test IMAP auth inside the mail container with the following commands:

docker exec -ti mail /bin/bash
doveadm auth test -x service=imap your@mail.inbox

[odie]

Thank you @joseph and @james for coming to the rescue so quickly.

I have no idea what happened, but I reapplied all my firewall rules (which had not been reconfigured) and restarted the mail service (from the system->services menu, where the mail service was had a red light), and suddenly things worked again. The mail log window has started spewing out log entries like the ones I paste below, but that is perhaps normal? There are tons of these, I only pasted a few of them.

Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:04 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:05 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog
Aug 12 12:09:06 [GET] /eventlog

[james]

Hello @odie
These log lines are normal.
Glad to read a simple service restart resolved the issue.