Cloudron Forum

Created an issue. https://github.com/haraka/Haraka/issues/3516

said in Haraka crashes with FATAL state. SMTP service not reachable. users with incorrect password attempts:

In recovery mode, I could probably manipulate the queued email in /app/data/haraka-queue/ so that the To header is another domain which has a normal MX record and allows inbound mails.

Then restart. That could to the quick fix.

Or instead of manipulating, just delete the one.

Yes. Moving the affected mail from haraka-queue to /app/data/tmp was helping.
Mail starts as expected now, clients can connect.

In recovery mode, I could probably manipulate the queued email in /app/data/haraka-queue/ so that the To header is another domain which has a normal MX record and allows inbound mails.

Then restart. That could to the quick fix.

Or instead of manipulating, just delete the one.

@girish Currently trying that. But, so far no luck in recovery mode either

...
[CRIT] [-] [core] TypeError: err.map is not a function
[CRIT] [-] [core]     at pluggableStream.<anonymous> (/app/code/haraka/outbound/client_pool.js:40:21)
[CRIT] [-] [core]     at Object.onceWrapper (node:events:633:26)
[CRIT] [-] [core]     at pluggableStream.emit (node:events:518:28)
[CRIT] [-] [core]     at Socket.<anonymous> (/app/code/haraka/tls_socket.js:79:18)
[CRIT] [-] [core]     at Object.onceWrapper (node:events:633:26)
[CRIT] [-] [core]     at Socket.emit (node:events:518:28)
[CRIT] [-] [core]     at emitErrorNT (node:internal/streams/destroy:170:8)
[CRIT] [-] [core]     at emitErrorCloseNT (node:internal/streams/destroy:129:3)
[CRIT] [-] [core]     at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
[NOTICE] [-] [core] Shutting down
2026-01-23 08:58:44,438 WARN exited: haraka (exit status 1; not expected)
2026-01-23 08:58:45,439 INFO gave up: haraka entered FATAL state, too many start retries too quickly

so I switched recovery mode off.

@necrevistonnezr

# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 5.15.0-164-generic
Ubuntu: jammy 22.04
Execution environment: kvm
Processor: AMD EPYC 9634 84-Core Processor x 8
RAM: 16371028KB
Disk: /dev/sda3       270G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.15 is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	Dashboard is reachable via domain name
[OK]	Domain monospace.design is valid and has not expired
[OK]	unbound is running

After more investigation I can most likely say, that the problem is rooted in a stuck outbound email which was sent to a mailbox on a domain which has a MX 10 record with value ".".

So Haraka wants to deliver outbound, resolver delivers MX ".", Haraka tries to establish a connection and fails. Node is returning an error as AggregateError.

Why does Haraka crash when doing this?
As soon as an outbound error comes in as an AggregateError without a useful err.message (or message is empty), the code runs into the AggregateError branch and crashes with: TypeError: err.map is not a function.

I am not deep enough in Node development but I assume that the relevant code snippet is located here:

/* /app/code/haraka/outbound/client_pool.js:37-42 */

const errMsg = err.message ?
  err.message :
  err instanceof AggregateError ?
    err.map(e => e.message).join(', ') :
    util.inspect(err, { depth: 3 });

I am going to check if this is still the case in Haraka 3.1.2 and if not Update Cloudron to 9.0.17 which also updates Haraka to the latest version. If not I’ll address this as an issue in the Haraka Github project.

Outgoing mail via the Cloudron mail server is not working. SMTP connections on ports 587 / 465 are refused from outside, while IMAP works as expected.

After further investigation, the Cloudron mail service (Haraka) repeatedly crashes during startup and enters a FATAL state, which explains why no SMTP ports are exposed externally.

The issue seems to be caused by a runtime error in Haraka during outbound TLS handling:

TypeError: err.map is not a function

Once this happens, Haraka shuts down and Cloudron stops retrying after multiple failures.

As a result:
• No SMTP service is reachable externally
• Mail clients cannot send mail via Cloudron
• IMAP continues to work

This appears to be a bug or incompatibility between Haraka, Node.js, and/or TLS configuration.

Relevant Haraka logs:

Starting up Haraka version 3.1.1
[NOTICE] [server] Listening on [::0]:2525
[NOTICE] [server] Listening on [::0]:2465
[NOTICE] [server] Listening on [::0]:2587
[INFO] [cloudron] Initializing queue server on port 6000
[CRIT] [core] TypeError: err.map is not a function
[CRIT] [core] at /app/code/haraka/outbound/client_pool.js:40:21
[CRIT] [core] at /app/code/haraka/tls_socket.js:79:18
[NOTICE] [core] Shutting down
WARN exited: haraka (exit status 1; not expected)
INFO gave up: haraka entered FATAL state, too many start retries too quickly

Troubleshooting Already Performed

• Verified DNS (A / AAAA records correct)
• Confirmed IMAP (993) works
• Verified SMTP ports are refused externally
• Checked listening ports inside the container (Haraka binds briefly, then crashes)
• Restarted Cloudron mail service
• Checked TLS certificate validity
• Verified this is not a firewall or provider port-blocking issue
• Confirmed issue persists across restarts

System Info

Cloudron v9.0.15
Ubuntu 22.04.4 LTS Linux 5.15.0-164-generic
8 Core "AMD EPYC 9634 84-Core Processor"
16.76 GB RAM & 4.29 GB Swap

• Main Page: https://www.onlook.com
• Git: https://github.com/onlook-dev/onlook
• Licence: Apache License 2.0
• Dockerfile: Yes
• Docs → Self-hosting → Docker Compose: https://docs.onlook.com/self-hosting/docker-compose
• Demo:
  (Launch video on YouTube)

---

• Summary: Onlook is an Open Source next-generation visual code editor that helps product teams ship faster by building production-ready apps visually. Use code as the source of truth – zero translation errors, instant collaboration across all roles.

---

• Notes: As a brand & digital design agency owner I am closing the gap between unique visual identities and technology. Key is a proper design system and a dev-ready design perspective. This app might be one helpful resource – self-hosted & open source!

---

• Alternative to / Libhunt link: e.g. https://selfhosted.libhunt.com/umap-alternatives

---

Screenshots:

I was digging deeper and found this article in the docs giving closure!

So the correct env vars are:

export CONTENT_SECURITY_POLICY_DIRECTIVES__FRAME_SRC="array:'self',http://localhost:3000"
export CONTENT_SECURITY_POLICY_DIRECTIVES__CONNECT_SRC="array:'self',http://localhost:3000,ws://localhost:3000"
export CONTENT_SECURITY_POLICY_DIRECTIVES__SCRIPT_SRC="array:'self','unsafe-inline'"
export CONTENT_SECURITY_POLICY_DIRECTIVES__STYLE_SRC="array:'self','unsafe-inline'"

Or specifically adjusted to your use case.

I would like to pick this topic up again.

The CORS env variables are set here in the start.sh entry script.

It is possible to override by exporting same var name using /app/data/env.sh.
It is also possible to add other config vars.
So far so good.

But it is not possible to customize the Content-Security-Policy header using the CONTENT_SECURITY_POLICY_* variables which are documented here in the directus docs. Also not the example CONTENT_SECURITY_POLICY_IMG_SRC="'self' https://images.example.com data:" is working.

So the Content-Security-Policy header configuration of nginx seems to be defined somewhere else.

I couldn't figure it out yet. Any idea?

@JUVOJustin Any news on this topic? Would also be interested for mail testing purposes.

@froodle said in New UI Sneak peak and review:

@dev-cb I love all these changes! Please consider raising this as a PR so I can give proper credit

thanks, will do

@osobo said in New UI Sneak peak and review:

@necrevistonnezr Thanks for your feedback. You're right ! I've cleared the cache and ... voila

Also here in the menu noticeable: The icons and their colorful boxes show some indecisiveness in terms of the spacing, sizing and border-radius. They are almost a circle, but not yet. Or in other peoples eyes almost rounded rectangles. In design should be no doubt, always decisions

@froodle thanks for the work. Great application and very useful in daily use!

But the latest UI changes feel a bit imbalanced to me and less organized. I think the biggest driver for that feeling is the border-radius of the icon boxes and the cards. Inconsistencies in sizing and spacing of the icons as well as too less padding for the icons also add to the feeling that something’s off.
The considerably strong stroke-width of the icons in comparison to the light font-weight of the tool titles does rather separating icon and text than connecting them visually to one item.
Also the border-width of the cards is visually too strong. Reducing the border-width or lighten the border-color. By the way, also noticeable inconsistencies in the border-widths (0.1rem in the search input vs. 2px icon cards).

Sounds quite harsh, meant as constructive feedback

I quickly sketched the changes in the dev inspect tool and saved the changes. Here is the comparison and the adjustments. Hope this is helping you to find the right balance!

original:

adjusted:

diff --git a/pdf/css/bootstrap.min.css b/pdf/css-edit/bootstrap.min.css
index 5cfa298..d262c73 100644
--- a/pdf/css/bootstrap.min.css	
+++ b/pdf/css-edit/bootstrap.min.css	
@@ -4389,12 +4389,13 @@ fieldset:disabled .btn {
 }
 
 .nav-link {
-  display: block;
+  display: flex;
   padding: 0.5rem 1rem;
   color: #0d6efd;
   text-decoration: none;
   transition: color 0.15s ease-in-out, background-color 0.15s ease-in-out,
     border-color 0.15s ease-in-out;
+  align-items: center;
 }
 
 @media (prefers-reduced-motion: reduce) {
diff --git a/pdf/css/home.css? b/pdf/css-edit/home.css?
index a6f89ed..91a0204 100644
--- a/pdf/css/home.css?	
+++ b/pdf/css-edit/home.css?	
@@ -5,7 +5,7 @@
   font-size: 16px;
   margin-bottom: 2rem;
   padding: 0.75rem 3.5rem;
-  border: 0.1rem solid var(--md-sys-color-outline-variant);
+  border: 1px solid var(--md-sys-color-outline-variant);
   border-radius: 3rem;
   outline-color: var(--md-sys-color-outline-variant);
 }
@@ -19,12 +19,12 @@
 .features-container {
   display: grid;
   grid-template-columns: repeat(auto-fill, minmax(15rem, 3fr));
-  gap: 25px 30px;
+  gap: 30px 30px;
 }
 
 .feature-card {
-  border: 2px solid var(--md-sys-color-surface-5);
-  border-radius: 2rem;
+  border: 1px solid var(--md-sys-color-surface-5);
+  border-radius: 1.75rem;
   padding: 1.25rem;
   display: flex;
   flex-direction: column;
@@ -47,13 +47,13 @@
 }
 
 .feature-card .card-text {
-  flex: 1;
+  font-size: .875rem;
 }
 
 .feature-card:hover {
   cursor: pointer;
-  transform: scale(1.1);
-  box-shadow: var(--md-sys-elevation-3);
+  transform: scale(1.025);
+  box-shadow: var(--md-sys-elevation-2);
 }
 
 .card-title.text-primary {
@@ -79,11 +79,12 @@
 }
 
 #tool-text {
-  margin: 0.5rem 0.5rem 0rem;
+  margin: 0.0rem 0 0 1.25rem;
 }
 
 .card-title {
   margin-bottom: 1rem;
+  font-size: 1rem;
 }
 
 /* Only show the favorite icons when the parent card is being hovered over */
diff --git a/pdf/css/navbar.css? b/pdf/css-edit/navbar.css?
index ddeab5a..a8845f2 100644
--- a/pdf/css/navbar.css?	
+++ b/pdf/css-edit/navbar.css?	
@@ -75,7 +75,7 @@
 }
 
 .icon-text {
-  margin-left: 4px;
+  margin-left: 8px;
   margin-right: 4px;
   display: inline-flex;
   flex-direction: column;
diff --git a/pdf/css/theme/componentes.css? b/pdf/css-edit/theme/componentes.css?
index d767d59..6318212 100644
--- a/pdf/css/theme/componentes.css?	
+++ b/pdf/css-edit/theme/componentes.css?	
@@ -187,8 +187,8 @@ td {
 .feature-card .nav-icon {
   vertical-align: middle;
   font-size: 2rem !important;
-  padding: 0.5rem;
-  border-radius: 1.25rem;
+  padding: 0.75rem;
+  border-radius: 0.9rem;
   color: var(--md-sys-color-surface);
 }
 
diff --git a/pdf/css/theme/font.css b/pdf/css-edit/theme/font.css
index dfb1c1b..f245dd3 100644
--- a/pdf/css/theme/font.css	
+++ b/pdf/css-edit/theme/font.css	
@@ -7,7 +7,7 @@
 
 .material-symbols-rounded {
     font-family: 'Material Symbols Rounded';
-    font-weight: normal;
+    font-weight: 300;
     font-style: normal;
     font-size: 24px;
     line-height: 1;
diff --git a/pdf/css/theme/theme.css? b/pdf/css-edit/theme/theme.css?
index 3c9565d..4f7be33 100644
--- a/pdf/css/theme/theme.css?	
+++ b/pdf/css-edit/theme/theme.css?	
@@ -30,5 +30,5 @@
 }
 
 .no-fill {
-  font-variation-settings: var(--md-sys-icon-fill-0);
+  /* font-variation-settings: var(--md-sys-icon-fill-0); */
 }
\ No newline at end of file

@marcusquinn I took a closer look at Kadence, seems solid work. Thanks for the share.

I was wondering if its possible to register customized blocks based on Kadence default blocks, so registering modified blocks within the Kadence realm, using a plugin or child theme. Do you have experience with that?

Thank you! That seemed to be the issue. Now v7.6.1 is not pre-release flagged anymore.

Hi there,

I am a little confused about the OS requirements for current and past Cloudron versions.

In the docs it does not say.
In the git repo it does not say.
Also in the changelog it does not say.

So when I take a look at the updates section on the settings page of my install, it seems stuck on v7.5.2. Version 7.6.1 is mentioned as a pre-release. But in the changelog I see v8.0.0 as the latest entry.

Therefore I am even not sure what the latest stable Cloudron version is.

Hope somebody can help me out here. What did I miss?

Thanks in advance.

Hi,

I was just noticing that the notification titles in the Cloudron dashboard looked awfully odd. When looking at the theme.scss to check what’s off, I was noticing the following:

The font-weight is set to bold (theme.scss#L1648)

Digging deeper I was noticing, that there were only two @font-face rules defined in (theme.scss#L58-66)

• only two font files are loaded: Light and Regular
• no font-style descriptor, so default font-style: normal would be applied
• no font-weight descriptor, so default font-weight: normal would be applied

Since there are only two font files loaded (Light, Regular) there is no file for the bold/700 weight – unless you’ve installed the font locally on your device.

This will cause the browser to faux bold the notification title. That’s basically just an outline to make the font appear bolder but that leads to crappy results. (more about that phenomenon here)
BTW, the same applies to font-style: If there is no italic font file loaded the browser will slant the font which results in faux italics. (more here)

Here is a comparison of faux (left) and correct (right):

The fix is easy: Load the entire Roboto font family, incl. all italic styles.

Thanks. Great application though.

Thank you! right hints