Cloudron Forum

d19dotca

Hello,

I believe there is a limitation somewhere (undocumented though) for contact imports. The HTTP response is a 500 because the request entity too large in the payload upon import.

For context: I have a VCF file with around 1,700 contacts that I was trying to import for testing purposes, and it errored out with Failed to import contacts (500). The VCF file I was using to import was 14.2 MB in size.

I could not find this documented, but the stack trace generated in the logs was pretty clear this was a size issue overall. Logs below.

Sep 03 22:31:11 ==> Starting contacts
Sep 03 22:31:12 CardDAV discovery: http://0.0.0.0:3000/.well-known/carddav
Sep 03 22:31:12 CardDAV server running at http://0.0.0.0:3000
Sep 03 22:31:12 Users authenticate with their email and app-specific passwords
Sep 03 22:32:59 at file:///app/code/node_modules/@cloudron/tegel/index.js:262:14
Sep 03 22:32:59 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:32:59 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:32:59 at Route.dispatch (/app/code/node_modules/router/lib/route.js:117:3) {
Sep 03 22:32:59 at getRawBody (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:116:12)
Sep 03 22:32:59 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:32:59 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:32:59 at read (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/read.js:113:3)
Sep 03 22:32:59 at readStream (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:163:17)
Sep 03 22:32:59 at textParser (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/types/text.js:34:5)
Sep 03 22:32:59 error: PayloadTooLargeError: request entity too large
Sep 03 22:32:59 expected: 14165817,
Sep 03 22:32:59 length: 14165817,
Sep 03 22:32:59 limit: 10485760,
Sep 03 22:32:59 path: '/api/addressbooks/5fa3c363/import',
Sep 03 22:32:59 status: 500,
Sep 03 22:32:59 type: 'entity.too.large'
Sep 03 22:32:59 {
Sep 03 22:32:59 }
Sep 03 22:32:59 }
Sep 03 22:34:29 at file:///app/code/node_modules/@cloudron/tegel/index.js:262:14
Sep 03 22:34:29 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:34:29 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:34:29 at Route.dispatch (/app/code/node_modules/router/lib/route.js:117:3) {
Sep 03 22:34:29 at getRawBody (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:116:12)
Sep 03 22:34:29 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:34:29 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:34:29 at read (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/read.js:113:3)
Sep 03 22:34:29 at readStream (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:163:17)
Sep 03 22:34:29 at textParser (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/types/text.js:34:5)
Sep 03 22:34:29 error: PayloadTooLargeError: request entity too large
Sep 03 22:34:29 expected: 14165817,
Sep 03 22:34:29 length: 14165817,
Sep 03 22:34:29 limit: 10485760,
Sep 03 22:34:29 path: '/api/addressbooks/5fa3c363/import',
Sep 03 22:34:29 status: 500,
Sep 03 22:34:29 type: 'entity.too.large'
Sep 03 22:34:29 {
Sep 03 22:34:29 }
Sep 03 22:34:29 }

d19dotca

Hello,

I was just deploying the Mail app to test with (I love the modern UX by the way, thank you for building this app!), and I see that the Spam tab in mailbox settings has a few things which I wanted to provide feedback on (and a question to ask too). Screenshot below for reference as well.

At least while in dark mode, I find the placeholder text in the Allowlist and Blocklist divs to be bright enough that they almost look at first glance like real text rather than placeholders. And I think the reason I think that way is because it's brighter than the text under the "Allowlist & blocklist" heading. It may just be a my own perspective, but I would maybe suggest darkening the placeholder text a little bit to make it less obvious, either that or perhaps increase the contrast between that and the descriptive text under the various headings on the same tab.

For the spam filter is active part with the statistics on how much is spam vs not spam... it took me a while to understand what the / 20 part represented? At first I thought it was a bug or that text was cut-off. From re-reading the text above though, I guess the "100%" part is representative of at least 20 messages in each classification, is that correct? I don't necessarily have a solution here, but I just feel like this part could use a little work in terms of how to display that information. But I might just be sour because I was embarrassed on how long it took me to understand it.

For the blocklist and allowlists... this might be obvious to most users perhaps, but for an admin side of things, it might be helpful if there was descriptions there (or at least maybe in the documentation for the app?) to confirm that this is a per mailbox setting but more importantly explain how this affects the spam filters server-wide in Cloudron if there is ever a conflict between what's set server-side and what's set in the Mail app (client-side).

That's all my feedback for now on that tab. Thank you again for considering it and for building such a replacement webmail app for everyone using Cloudron.

d19dotca

This CMS is fantastic. Been playing around with it the past few weeks, it's great!

I used AI to help me create a Cloudron package, I'm still exploring it and will try to publish it when it's safe. It took me a while to get the email portion working, but it seems to be working in my latest tests. Would love Cloudron to implement this one natively, but community apps can definitely fill in the gap in the meantime. I'm hoping Instatic comes up big.

d19dotca

@joseph Maybe an alternative UX could be for an app admin to have the ability to “disable” the Cloudron robots.txt feature on apps like WordPress so that it’s clear to other admins that the app is managing the robots.txt instead of Cloudron. Just an idea at least.

d19dotca

@girish No I wasn’t and still don’t, that’s why I mentioned in an earlier comment that it was a little bit misleading. I’m just saying now though since this was marked as solved because you weren’t sure what more could be done, I’m just adding that exposing the ability to set rate limits in Haraka could be nice as a workaround and giving more control to users.

d19dotca

@james Hi James. I think you may have misunderstood my current status. Sorry for any confusion there.

I already found the root cause and worked around it by manually flattening the forwards I had in place which were affected, so by going from A to B to C to instead using A to C directly, cutting out the middle layer forwarding chain. It’s all fixed for me at the moment, although I would prefer to use the original chain so that aliasing works well whenever C needs to be updated so that only one account needs to be updated instead of several.

But I am reporting it here to the Cloudron team because it still should be a use-case that is handled by Cloudron in the migration from mailing lists to the new forwarding style.

Cloudron either needs to flatten the mailing lists so that A goes directly to C instead of via B, or else Cloudron needs to properly support A to B to C as it did before.

Otherwise when 10.0 goes out to more people you’re going to have a lot of complaints from users who use the same forwarding scheme.

d19dotca

@girish Having the option to add rate limiting outbound to certain domains in Haraka would be nice to have.

d19dotca

I encountered what appears to be a mail-forwarding migration regression after upgrading from approximately Cloudron 9.2.0 to 10.0.1.

Before the upgrade, I had forwarding chains like:

address-a@example.com
→ address-b@example.com
→ external-recipient@example.net

Cloudron 10 migrated the former forwarding addresses into mailboxes with forwarding enabled, but these multi-stage chains no longer worked.

Mail sent to the first address was accepted and redirected to the second local mailbox, but never reached the external recipient. The messages remained in:

/home/yellowtent/boxdata/mail/haraka-queue

The queued messages confirmed that the first redirect occurred:

X-Sieve-Redirected-From: address-a@example.com
Delivered-To: address-a@example.com

After affected messages entered the queue, the entire mail service became unreliable. Roundcube reported:

SMTP Error (0): Connection to server failed.

Sending and receiving mail stopped working. Restarting the mail service did not resolve it because the problematic queue entries and forwarding configuration remained.

I recovered by:

Moving the four stranded messages out of haraka-queue.
Changing each affected mailbox to forward directly to its final external recipient, eliminating the intermediate local forwarding mailbox.
Restarting the mail service.
Replaying the preserved messages through SMTP.

All replayed messages received SMTP 250 responses and appeared as Sent in Cloudron’s event log. New mail is also working normally.

Possible reproduction

On Cloudron 9, create a forwarding address A that forwards to another local forwarding address B.
Configure B to forward externally to C.
Upgrade to Cloudron 10.0.1.
Send mail to A.
Check whether it reaches C or remains in haraka-queue.

It may also be reproducible directly on 10.0.1 by configuring forwarding-enabled mailboxes as:

A → B → external C

My suspicion is that the migration preserves each forwarding relationship without flattening the chain, while the new forwarding implementation does not safely handle mailbox-to-mailbox forwarding chains.

d19dotca

@girish said:

Also, the plan is not to expose spamassassin and it's features/plugins. We will simply integrate the use cases and never implementation details. Currently, the custom SA config is allowed in the UI but this was a mistake on our side.

Hmm, I am not sure if I agree with that view. Why do you think that was a mistake? If it wasn't customizable, many of us would be getting many more times the spam we already do because the default SpamAssassin rules are pretty awful these days with the aggressive spam nature as a result of so many more bots and more sophisticated spam attacks.

Please don't remove that. If anything, I am in agreement with @imc67 that we need more controls. Cloudron is maturing, and with the help of AI many people are getting more advanced in their skillsets, and hiding things away from technical admins only increase friction with using Cloudron. I do hope that this will be reconsidered, and that more controls can be exposed for us.

On a separate note about the SpamAssassin sa-update and sa-learn stuff that Cloudron has a script for, I was recently looking into that myself and comparing it with a script I wrote myself for running some SpamAssassin scans for learning ham and spam (BAYES training). Here is an AI summary of this for reference:

The bundled /app/code/spamassassin-config/learn-from-user-mail.sh, scheduled daily at 22:00 UTC by /app/code/service.js, only identifies paths under .Spam as spam.

Its ham search excludes exact .Drafts, .Spam, and .Trash paths, but it does not correctly handle:

- .Junk or nested Junk folders, which are learned as ham
- .Deleted Messages, which is learned as ham
- nested Trash folders such as .Trash.CANCELLATIONS
- Sent/Sent Messages, with no option for administrators to exclude them
- folder and message paths containing spaces, because results from find are processed through whitespace-splitting shell variables
- messages above the default spamc 512 KB limit

The script also applies head -n 200 to unsorted find output, so the selected messages are not necessarily the newest 200.

Could the learner use Dovecot special-use metadata (\Junk, \Trash, \Sent, and \Drafts) or, at minimum, robust Maildir folder-name matching with NUL-delimited paths?

It would also be helpful to make Sent-folder learning configurable and provide an administrator option to disable or customize the bundled automatic learner.

d19dotca

I love the idea of handling bots. Currently I use a script from some sites but it’s more spam-based and unfortunately the API in Cloudron will only handle so many network addresses (or specifically a max size of PUT I believe) so I can’t keep expanding the list of IP firewall lists I want to use for blocking traffic.

Lately this has become an issue for me for a few reasons but notably I’m finding too much bot traffic showing up in website analytics when using Matomo or Umami, and even third-party app Rybbit, and I have been trying to find a way to fight this so that the analytics is more accurate. If there’s a way to better fight this at the network layer in Cloudron I think that would be fantastic. At the very least though I think increasing the size allowed for network lists would be very helpful so that we can include more IP addresses.

Also, I love that mail is finally getting the attention it much deserves. Looking forward to that.

I think apart from what one person mentioned which is domain-based SpamAssassin rules or changing scores for example depending on the type of spam they receive, it’d be really nice if we could easily configure SpamAssaasin in the UI for resetting training data and forcing a rescan of spam and ham folders, as well as the ability to note which folders should or should not be treated as ham or spam so that we can add in our own for example.

Just something else to consider.

Thank you for all the hard work! Looking forward to v10.

d19dotca

I assume this may be more of Vaultwarden issue than a Cloudron one but I wanted to say the recent image update (https://forum.cloudron.io/topic/2546/vaultwarden-package-updates/79?_=1778039394241) seems to have broken Vaultwarden, requiring me to restore from backup.

May 05 20:47:32 => Exporting env vars expected by Vaultwarden
May 05 20:47:32 => Starting Bitwarden
May 05 20:47:32 /--------------------------------------------------------------------\
May 05 20:47:32 |                        Starting Vaultwarden                        |
May 05 20:47:32 |--------------------------------------------------------------------|
May 05 20:47:32 | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
May 05 20:47:32 | official channels to report bugs/features, regardless of client.   |
May 05 20:47:32 | Send usage/configuration questions or feature requests to:         |
May 05 20:47:32 |   https://github.com/dani-garcia/vaultwarden/discussions or        |
May 05 20:47:32 |   https://vaultwarden.discourse.group/                             |
May 05 20:47:32 | Report suspected bugs/issues in the software itself at:            |
May 05 20:47:32 |   https://github.com/dani-garcia/vaultwarden/issues/new            |
May 05 20:47:32 \--------------------------------------------------------------------/
May 05 20:47:32 2026-05-06T03:47:32Z 
May 05 20:47:32 [INFO] Using saved config from `/app/data/config.json` for configuration.
May 05 20:47:32 2026-05-06T03:47:32Z 
May 05 20:47:32 [2026-05-06 03:47:32.167][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2026-03-09-005927_add_archives", version: MigrationVersion("20260309005927") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'archives_ibfk_1' are incompatible."))': src/db/mod.rs:501
May 05 20:47:32 0: vaultwarden::init_logging::{{closure}}
May 05 20:47:32 1: std::panicking::panic_with_hook
May 05 20:47:32 2: std::panicking::panic_handler::{closure#0}
May 05 20:47:32 3: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
May 05 20:47:32 4: __rustc::rust_begin_unwind
May 05 20:47:32 5: core::panicking::panic_fmt
May 05 20:47:32 6: core::result::unwrap_failed
May 05 20:47:32 7: vaultwarden::db::DbPool::from_config
May 05 20:47:32 8: vaultwarden::main::{{closure}}
May 05 20:47:32 9: vaultwarden::main
May 05 20:47:32 10: std::sys::backtrace::__rust_begin_short_backtrace
May 05 20:47:32 11: main
May 05 20:47:32 12: <unknown>
May 05 20:47:32 13: __libc_start_main
May 05 20:47:32 14: _start

Any ideas on this one?

d19dotca

@timconsidine So does Umami but it doesn't seem to work too well, haha. I just installed it last night from the community package that you built and will try that out today on a few sites to compare the data. I really appreciate you putting that together!

Not to distract too much from the original topic, but do you have a Claude Skill or something that you use to help package apps for Cloudron? I just realized a Claude Skill may be super helpful for something like this and maybe it'll help me package some apps myself too which I've avoided since I was never too knowledgable of the full process yet.

d19dotca

@timconsidine oh this is fantastic! I love Umami overall but the main trip up for me is the excessive bot requests that it’s tagging as valid analytics. So many hits (multiplier over expected Canadian visitors for a small local business) from Singapore for example, and it’s all basically Petalbot traffic hitting the client sites with a 100% bounce rate. If I exclude bounce rate (a new feature in the Umami dashboard) then it is much closer to expected traffic data. There’s been a few posts from a few users (including myself) in their GitHub repo but seemingly no desire to fix it. ‍️

Because of that, I’d definitely be interested in Rybbit analytics on Cloudron. Happy to beta test the community package if that helps.

d19dotca

@jadudm Agreed. But isn’t that something configurable in the package? Looks like it isn’t a user-facing setting, but I assume this can be taken care of in the code part of the package? I’m not super familiar with packing apps just yet so correct me if I’m wrong.

Probably worth setting the client max body size to 0 for unlimited since there will be all sorts of sizes to an app that’s used for backups. I’m just surprised nobody else has run into this issue, it happens immediately upon backup.

d19dotca

@timconsidine hi Tim,

I tried to use the community app but I get a 413 response code (which suggests the payload is too large). It happens at the very first backup attempt.

Any suggestions? Is there anything I may have missed, or anything you had to do after deploying the app? Did you ever run into the 413?

I’m using tarball and encryption in case that matters at all.

d19dotca

I haven’t used Garage yet but isn’t it just another s3? So it’d basically be a MinIO replacement, right? Do we have any other options for ones with “hardlinks” using rsync? I kind of think the Surfer app would honestly be a great way to use as a backup somehow if it could be used to expose a disk.

d19dotca

I am in a similar position. I currently use iDrive e2 for backups and it’s fine but it does take around 1.5 hours uploading tarballs from my server. I’m looking at possibly deploying a low-budget Kimsufi server in the same OVH data centre and just mounting that disk as SSHFS to Cloudron on my primary server, haven’t tried it out yet. If I go this way I will likely still keep iDrive as a second backup destination and just run it a little less frequently and with lower retention to save on costs a little bit there.

I’m wondering about MinIO alternatives as I tried MinIO on a second Cloudron install but it seemed to take even longer than uploading to iDrive e2 somehow (I expected it’d be quicker not slower). It seemed the project is dead too but then it also looks like there’s an active fork that maybe the Cloudron @staff can look into using instead. Brings back many of the lost MinIO features by the sounds of it too.

Thinking of other avenues to keep backups more “local” or as close to local as possible for rapid quick backups, and then completely offsite as a second backup plan too.

I have around 65 GB compressed to back up, around 125 GB uncompressed, I believe.

d19dotca

@girish , is this perhaps something we can consider adding in one of the next updates? This would be greatly beneficial to be able to specify the IP address for outbound traffic in Cloudron (at least for the mail container but maybe all containers in one setting might be better for some people, not too sure what the best approach is).

I found a couple of other related topics so it seems like there is a need for this. I think my solution should still work but likely just needs to be adapted by Cloudron to be more built-in with a GUI to set the outbound traffic IP (or maybe just have it default to the IP set in the Network page by default as I suspect the DNS record IP would be the same IP outbound traffic would be desired).

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

d19dotca

Posts

Possible reproduction