D
@dev-cb I had the same issue with an empty Zabbix folder. Restoring the old version, deleting the empty folder, and updating to the latest version worked. But I thought it had nothing to do with the app package and was just an issue with my instance.
Yes. Just did the same, backup, update, restart went all though.
Hello @dev-cb
Where didn8n-nodes-xlsxcome from, with your statement:/app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/
This was not in the log you posted above, so how did you figure out it was this folder?
Copied the wrong event. My bad... Sorry for sloppiness.
I’ve adjusted the post with the log.
I removed the empty directory /app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/ and restarted.
At first the app was not responding, then was running.
@chrishvd Could you please check if the same behaviour matches your issue?
/app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/ is indeed empty. Was created a few days ago, which differs from the other node packages.
Sorry, was cut. Yes..
...
2026-05-27T07:59:20.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41: 8080
2026-05-27T07:59:30.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41: 8080
2026-05-27T07:59:35+02:00 ==> Ensure directories
2026-05-27T07:59:35+02:00 ==> Setting permissions
2026-05-27T07:59:35+02:00 ==> Starting N8N
2026-05-27T07:59:37+02:00 Error: ENOENT: no such file or directory, open '/app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/package.json'
2026-05-27T07:59:37+02:00 at /app/code/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_<HASH_REDACTED>/node_modules/n8n-core/src/nodes-loader/scan-directory-for-packages.ts:29:4
2026-05-27T07:59:37+02:00 at Array.map (<anonymous>)
2026-05-27T07:59:37+02:00 at CommandRegistry.execute (/app/code/src/command-registry.ts:46:3)
2026-05-27T07:59:37+02:00 at CommunityPackagesModule.nodeLoaders (/app/code/src/modules/community-packages/community-packages.module.ts:41:10)
2026-05-27T07:59:37+02:00 at LazyPackageDirectoryLoader.readJSONSync (/app/code/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_<HASH_REDACTED>/node_modules/n8n-core/src/nodes-loader/package-directory-loader.ts:96:34)
2026-05-27T07:59:37+02:00 at ModuleRegistry.loadModules (/app/code/node_modules/.pnpm/@n8n+backend-common@file+packages+@n8n+backend-common_zod@3.25.67/node_modules/@n8n/backend-common/src/modules/module-registry.ts:124:20)
2026-05-27T07:59:37+02:00 at new LazyPackageDirectoryLoader (/app/code/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_<HASH_REDACTED>/node_modules/n8n-core/src/nodes-loader/lazy-package-directory-loader.ts:6:1)
2026-05-27T07:59:37+02:00 at new PackageDirectoryLoader (/app/code/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_<HASH_REDACTED>/node_modules/n8n-core/src/nodes-loader/package-directory-loader.ts:20:27)
2026-05-27T07:59:37+02:00 at readFileSync (node:fs:439:20)
2026-05-27T07:59:37+02:00 at scanDirectoryForPackages (/app/code/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_<HASH_REDACTED>/node_modules/n8n-core/src/nodes-loader/scan-directory-for-packages.ts:27:31)
2026-05-27T07:59:40.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41: 8080
2026-05-27T07:59:50.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41: 8080
So it looks indeed like n8n attempts to load a package but can not find the required package.json so it exits.
Hi, I need help with debugging this issue.
Git Commit: Update package version to 4.24.0
The update in the log (anonymized/redacted):
2026-05-24T03:03:13.325Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":172,"total":172},"id":"a7c19e4b2d10"}
2026-05-24T03:03:13.343Z docker: pullImage: {"status":"Pull complete","progressDetail":{},"id":"a7c19e4b2d10"}
2026-05-24T03:03:13.348Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":147,"total":147},"id":"c2d884f109ab"}
2026-05-24T03:03:13.348Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":147,"total":147},"id":"c2d884f109ab"}
2026-05-24T03:03:13.365Z docker: pullImage: {"status":"Pull complete","progressDetail":{},"id":"c2d884f109ab"}
2026-05-24T03:03:13.369Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":165,"total":165},"id":"e91a7c03bd45"}
2026-05-24T03:03:13.370Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":165,"total":165},"id":"e91a7c03bd45"}
2026-05-24T03:03:13.387Z docker: pullImage: {"status":"Pull complete","progressDetail":{},"id":"e91a7c03bd45"}
2026-05-24T03:03:13.392Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":1347,"total":1347},"id":"49fd10e8c732"}
2026-05-24T03:03:13.392Z docker: pullImage: {"status":"Extracting","progressDetail":{"current":1347,"total":1347},"id":"49fd10e8c732"}
2026-05-24T03:03:13.408Z docker: pullImage: {"status":"Pull complete","progressDetail":{},"id":"49fd10e8c732"}
2026-05-24T03:03:13.422Z docker: pullImage: {"status":"Digest: sha256:8e174f9c50d7a629ab340be51cfd8267ee4d3a6192045b8cc7329a607f1e48bd"}
2026-05-24T03:03:13.426Z docker: pullImage: {"status":"Status: Downloaded newer image for registry.example.invalid/vendor/io.app.example:202605220101010000"}
2026-05-24T03:03:13.430Z docker: downloadImage: tagging registry.example.invalid/vendor/io.app.example:202605220101010000 as vendor/io.app.example:202605220101010000
2026-05-24T03:03:13.430Z docker: downloaded image registry.example.invalid/vendor/io.app.example:202605220101010000 . error: false
2026-05-24T03:03:13.435Z docker: deleteImage: removing registry.example.invalid/vendor/io.app.example:202605220101010000
2026-05-24T03:03:13.435Z docker: downloadImage: untagging registry.example.invalid/vendor/io.app.example:202605220101010000
2026-05-24T03:03:13.442Z tasks: updating task 78431 with: {"percent":35,"message":"Deleting old containers"}
2026-05-24T03:03:13.444Z apptask: deleteContainer: deleting app containers (app, scheduler)
2026-05-24T03:03:13.444Z shell: apptask: /usr/bin/sudo --non-interactive /home/service/platform/src/scripts/configurelogrotate.sh remove 4c18ad72-9b40-4f26-8e51-d9b2037fa684
2026-05-24T03:03:13.479Z docker: stopContainer: stopping container 4d90c71eac82f019be61a2f73a0d846c51e2018f8d3a97cd4fb53026c2e711a9
2026-05-24T03:03:14.517Z docker: deleteContainer: deleting 4d90c71eac82f019be61a2f73a0d846c51e2018f8d3a97cd4fb53026c2e711a9
2026-05-24T03:03:14.554Z docker: deleteImage: removing vendor/io.app.example:202605200202020000
2026-05-24T03:03:24.706Z services: teardownAddons: Tearing down []
2026-05-24T03:03:24.722Z tasks: updating task 78431 with: {"percent":45,"message":"Downloading icon"}
2026-05-24T03:03:24.724Z apptask: downloadIcon: Downloading icon of io.app.example@9.8.7
2026-05-24T03:03:25.201Z tasks: updating task 78431 with: {"percent":60,"message":"Updating addons"}
2026-05-24T03:03:25.204Z services: setupAddons: Setting up ["localstorage","postgresql","sendmail","redis"]
2026-05-24T03:03:25.204Z services: setupAddons: setting up addon localstorage with options {}
2026-05-24T03:03:25.204Z services: setupLocalStorage
2026-05-24T03:03:25.204Z shell: services: /usr/bin/sudo --non-interactive /home/service/appsdata/4c18ad72-9b40-4f26-8e51-d9b2037fa684/data
2026-05-24T03:03:25.226Z services: Setting up postgresql
2026-05-24T03:03:25.226Z services: setupAddons: setting up addon postgresql with options {}
2026-05-24T03:03:25.264Z services: Setting postgresql addon config to [{"name":"CLOUDRON_POSTGRESQL_URL","value":"postgres://user4c18ad729b404f268e51d9b2037fa684:<REDACTED_SECRET_01>@db-internal/db4c18ad729b404f268e51d9b2037fa684"},{"name":"CLOUDRON_POSTGRESQL_USERNAME","value":"user4c18ad729b404f268e51d9b2037fa684"},{"name":"CLOUDRON_POSTGRESQL_PASSWORD","value":"<REDACTED_SECRET_01>"},{"name":"CLOUDRON_POSTGRESQL_HOST","value":"db-internal"},{"name":"CLOUDRON_POSTGRESQL_PORT","value":"5432"},{"name":"CLOUDRON_POSTGRESQL_DATABASE","value":"db4c18ad729b404f268e51d9b2037fa684"}]
2026-05-24T03:03:25.267Z services: Setting up SendMail
2026-05-24T03:03:25.267Z services: setupAddons: setting up addon sendmail with options {"supportsDisplayName":true}
2026-05-24T03:03:25.268Z services: Setting sendmail addon config to [{"name":"CLOUDRON_MAIL_SMTP_SERVER","value":"mail-internal"},{"name":"CLOUDRON_MAIL_SMTP_PORT","value":"2525"},{"name":"CLOUDRON_MAIL_SMTPS_PORT","value":"2465"},{"name":"CLOUDRON_MAIL_STARTTLS_PORT","value":"2587"},{"name":"CLOUDRON_MAIL_SMTP_USERNAME","value":"automation@tenant.example.invalid"},{"name":"CLOUDRON_MAIL_SMTP_PASSWORD","value":"<REDACTED_SECRET_02>"},{"name":"CLOUDRON_MAIL_FROM","value":"automation@tenant.example.invalid"},{"name":"CLOUDRON_MAIL_DOMAIN","value":"tenant.example.invalid"},{"name":"CLOUDRON_MAIL_FROM_DISPLAY_NAME","value":""}]
2026-05-24T03:03:25.271Z services: setupAddons: setting up addon redis with options {"optional":true}
2026-05-24T03:03:25.275Z services: Re-using existing redis container with state: {"Status":"running","Running":true,"Paused":false,"Restarting":false,"OOMKilled":false,"Dead":false,"Pid":28417,"ExitCode":0,"Error":"","StartedAt":"2026-04-30T03:58:18.834618381Z","FinishedAt":"0001-01-01T00:00:00Z"}
2026-05-24T03:03:25.275Z services: Waiting for redis-4c18ad72-9b40-4f26-8e51-d9b2037fa684
2026-05-24T03:03:25.474Z tasks: updating task 78431 with: {"percent":70,"message":"Creating container"}
2026-05-24T03:03:25.476Z apptask: createContainer: creating container
2026-05-24T03:03:25.575Z shell: apptask: /usr/bin/sudo --non-interactive /home/service/platform/src/scripts/configurelogrotate.sh add 4c18ad72-9b40-4f26-8e51-d9b2037fa684 /tmp/4c18ad72-9b40-4f26-8e51-d9b2037fa684.logrotate
2026-05-24T03:03:25.597Z apptask: startApp: starting container
2026-05-24T03:03:25.785Z tasks: updating task 78431 with: {"percent":90,"message":"Configuring reverse proxy"}
2026-05-24T03:03:25.788Z tasks: updating task 78431 with: {"percent":100,"message":"Done"}
2026-05-24T03:03:25.792Z tasks: setCompleted - 78431: {"result":null,"error":null,"percent":100}
2026-05-24T03:03:25.792Z tasks: updating task 78431 with: {"completed":true,"result":null,"error":null,"percent":100}
2026-05-24T03:03:25.794Z Exiting with code 0
2026-05-24T03:03:25.794Z taskworker: Task took 203.464 seconds
2026-05-24T03:03:30.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41:8080
2026-05-24T03:03:40.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41:8080
2026-05-24T03:03:51.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41:8080
2026-05-24T03:04:00.000Z => Healthcheck error: Error: connect ECONNREFUSED 10.254.87.41:8080
2026-05-24T03:04:13.000Z => Healthcheck error: Error: connect EHOSTUNREACH 10.254.87.41:8080
2026-05-24T03:04:27.000Z => Healthcheck error: AbortError: The operation was aborted
2026-05-24T03:04:33.000Z => Healthcheck error: Error: connect EHOSTUNREACH 10.254.87.41:8080
2026-05-24T03:04:43.000Z => Healthcheck error: Error: connect EHOSTUNREACH 10.254.87.41:8080
2026-05-24T03:04:56.000Z => Healthcheck error: Error: connect EHOSTUNREACH 10.254.87.41:8080
Restoring to v4.23.3 sets status back to normal.
Cloning a backup from affected version results in not responding app.
Root cause was a missing database entry for the new setting AccessibilityStatement. The frontend now always requests it:
/api/v1/site_settings.json?names[]=Terms&names[]=PrivacyPolicy&names[]=AccessibilityStatement
On existing installations, this setting may not exist (the data migration isn’t applied automatically), which causes the endpoint to return:
null
This leads to a frontend crash with error Cannot read properties of null (reading 'data').
Workaround (Confirmed)
Manually create the missing records:
settingsINSERT INTO settings (id, name, created_at, updated_at) VALUES (gen_random_uuid(), 'AccessibilityStatement', NOW(), NOW());
site_settings for all providersINSERT INTO site_settings (id, setting_id, value, provider, created_at, updated_at)
SELECT
gen_random_uuid(),
s.id,
'',
p.provider,
NOW(),
NOW()
FROM
(SELECT DISTINCT provider FROM site_settings) p
CROSS JOIN
(SELECT id FROM settings WHERE name = 'AccessibilityStatement') s
WHERE NOT EXISTS (
SELECT 1
FROM site_settings ss
WHERE ss.setting_id = s.id
AND ss.provider = p.provider
);
After this, the endpoint returns valid data and the application works correctly.
Details and full context here:
https://github.com/bigbluebutton/greenlight/issues/6259
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.
# 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.
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
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
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?