Cloudron Forum

I looked into years ago for our old stack but with Cloudron providing its own mail store and smtp stack on top of the read-only nature of the app container it was not really a fit. Nowadays our stack is even more "heavyweight" (due to the need to be able to scale to 10.000s of users on a single node) so I don't think it would be a good fit for an app.

Cloudron version: 10.0.4 Backup storage: IONOS S3-compatible Object Storage Symptom: The backup upload itself completes successfully, but the immediately following server-side rotate-copy (UploadPartCopy) fails with NoSuchKey, causing the whole backup task to fail with Old backup not found: snapshot/app_<id>.tar.gz.enc. Reproduced on two consecutive daily runs, always on our largest app (~70GB snapshot); other apps (4–70GB) in the same runs succeed. Timeline (Task 11372, millisecond precision): 04:32:30.199 upload stats logged: 72,608,517,172 bytes transferred 04:32:30.285 backupupload: upload completed. error: null (CompleteMultipartUpload -> 200 OK) 04:32:30.466 Copying (multipart) snapshot/app_c08ad55d-...tar.gz.enc (rotate-copy starts, 181ms later) 04:32:30.534 Copying part 1 - ... bytes=0-1073741823 04:32:30.535 Copying part 2 - ... bytes=1073741824-2147483647 04:32:30.535 Copying part 3 - ... bytes=2147483648-3221225471 04:32:30.680 Aborting multipart copy (145ms after part requests) 04:32:30.748 storage/s3: copy error: NoSuchKey: UnknownError 04:32:30.748 copy to .../app_registry.20zen.de_v1.13.0.tar.gz.enc errored. error: Old backup not found Analysis: CompleteMultipartUpload returns success at .285, but the immediately following UploadPartCopy on the exact same key returns NoSuchKey ~150ms later. This looks like a read-after-write consistency delay on the IONOS backend for very large multipart objects — AWS S3 itself has guaranteed strict read-after-write consistency (including for multipart uploads) since Dec 2020, so this is non-standard behavior on the storage backend side. That said, Cloudron's rotate-copy step (s3.js: copyInternal) has no resilience for this: no retry, no backoff, no existence check before issuing the copy. A single transient 404 immediately fails the whole backup task, even though a short retry would very likely succeed. Request: Could a short retry/backoff (or a HeadObject check before copying) be added around the rotate-copy step for large/multipart-uploaded objects, to tolerate brief backend propagation delays on non-AWS S3-compatible providers? (I will also open a ticket at IONOS, but this little improvement would make Cloudron Backups more stable for similar situations with other providers too.) Relevant stack: BoxError: Old backup not found: snapshot/app_c08ad55d-2629-4de5-9d8c-adc28c142aca.tar.gz.enc at throwError (file:///home/yellowtent/box/src/storage/s3.js:568:49) at copyInternal (file:///home/yellowtent/box/src/storage/s3.js:636:16) at process.processTicksAndRejections (node:internal/process/task_queues:104:5) at async Object.copy (file:///home/yellowtent/box/src/storage/s3.js:670:12) at async Object.copy (file:///home/yellowtent/box/src/backupformat/tgz.js:294:5) related: https://forum.cloudron.io/topic/14253/error-400-in-backup-process-with-ionos-s3-object-storage/38?_=1788503267379

I don't have a good solution but we should probably bump up our minimum requirements to 30GB probably... Linux/Ubuntu/Docker images all add up I guess.

Good idea, but password complexity is not measured with characters list or types but with entropy. You can have good password with 7 characters and bad password with 10 characters. An example to understand. I used KeePassXC password generator to measure these passwords entropy: This is 7 characters password: ⊌ӊ⇊ٳ➟⋋О Entropy: 116 bits. Only "special characters". No length, No Alphanumeric, no mixed case. This is 15 characters password: 8&w^3fck%NdMh4W Entropy: 94 bits Length, Alphanumeric, Special characters, Mixed case. The first one only respect one requirement asked but is better than the second that respect all. The difference is huge if try with only 12 characters: gx@V5iZLfuN7 Entropy: 65 bits. All requirements mets as the previous one, and it's not the worst i can have with 12 characters. As it's common mistakes about password complexity, i think Cloudron should never allow to require characters list/types. Instead, password complexity requirements should be technically measured with true entropy/bits algorithm as in KeePassXC that way good password will be allowed based on real complexity not on arbitrary rules. The settings can always be displayed simple in settings with "Weak", "Average", "Good", "Excellent", etc... instead of entropy bits. Finally, asking password to have specific characters list or type will break auto-generated password by password manager because websites has not all the same rules and password generators not the same default settings. I hope this will help.

[1.2.2] Update contacts to 1.2.2 Allow larger addressbook imports Update to latest pankow Reduce UI flickering

@nostrdev E2B ? Kata ? Something else ? (Probably a slippery slope needing its own discuss or off-topic thread, based on your thought-provoking question touching many surfaces).

What's difference this app with app web terminal on file manager?

Thanks for packaging Bitwarden Lite. I am personally not particularly interested in it. However having an alternative to Vaulwarden on Cloudron would be appreciated. Possibly, something like Psono, AliasVault or Passbolt as a suggestion if you needed some But for now, thanks again.

@DualOSWinWiz that’s very useful, thank you.