Thank you for your help, I'll try this!

Looks like the fix in https://forum.cloudron.io/topic/15767/mysql-service-still-runs-with-the-default-128m-innodb_buffer_pool_size might be the regression .

Thanks @james . Fixed now.

Hello @milohiss @milohiss said: Are maintenance emails sent only when a notice is first created? Can its dashboard timestamp change without another email being sent? Yes to both, and that is exactly what you are seeing. Email fires when the notification is first created, or when an already-acknowledged notice is re-raised. An unacknowledged notice that keeps re-pinning gets its creationTime bumped every run and the dashboard renders that field and sorts by it, so it looks brand-new at the top of the bell while no mail is generated. The August email was the original send, nothing has been "missed" since, by design. @milohiss said: What read-only diagnostic can distinguish expected suppression of repeat notifications from a failure to generate or send the email? In the box.log you could find lines like: mailer: Email "..." sent to ... for a successful send Error sending Email ... for a real failure notifications: add: <type> <title> for a notification being added logged only on insert not on update @milohiss said: All available email notification categories are now enabled. Does this cover every new bell notification? If not, which are dashboard-only? They cover every notification that can produce an email. But several bell notices have no mailer and are dashboard-only and these are: cloudronInstalled, cloudronUpdated, ubuntuUpdate (for EOL warnings like Ubuntu 20), mailStatus (Email configuration error), domainConfigCheckFailed, appUpdateCheckFailed Maybe this is something we could improve. @milohiss said: Is there a supported way to receive email reminders for unresolved urgent notices? Currently, there is no reminder/re-nag timer. The one supported lever is the acknowledge transition: dismiss the notice in the bell, and the next check (≤24h for reboot, ≤4h for updates) re-raises it and sends a fresh email.

The difference is just a technical one, where we solve a potential case of misalignment, not a change in behavior. I don't think there is much to document as such. I guess one can see the previous flow as a bug which got fixed.

Oh so you guys did change the pricing. Are we grandfathered at the account level or at the existing plan level? Nevermind. The answer is a few posts above this. (I didn't originally read that far)

Hello @arta On what Cloudron version are you now exactly? Have you tried clearing the cache? Also, how many users and groups are on this system?

Hello @dsp76 I have just tested this flow. User with TOTP and passkey configured. Attempt login with username and password: opens the passkey context of bitwarden and shows only the passkey for this user clicking the passkey login success Attempt login with username and password: opens the passkey context of bitwarden closing the bitwarden context without selecting the passkey, falls back to device passkey cancel that as well UI prints Failed to login with passkey, now I can input a TOTP enter TOTP and pressing Login login success Attempt login with passkey: bitwarden context opens showing all passkeys available for this domain selecting my passkey for the user login success Does this flow not work with 1password? Or do you think the flow should be changed so that if multiple 2FA options are configured for a user, the UI asks the user which one to use? Similar to our NodeBB forum when having TOTP and Passkey configured? [image: image.jpeg]

@Nozy I replied from support. The issue seems to be that the box code was created by hand as "CREATE DATABASE box" . However, this gets the incorrect default collation and migrations fail. The correct command is CREATE DATABASE IF NOT EXISTS box CHARACTER SET utf8mb4 COLLATE utf8mb4_bin . I have fixed the docs to state this.

@LoudLemur said: @necrevistonnezr has a valid point, too. What else can we do, though? "Understand it better?" This problem meant people were not receiving emails. Not sending a bug report, particularly when the ai had found a fix, didn't seem public spirited. It also is a bit like self-censorship. It’s pretty simple: Read the output, work with it it, make it your own. Don‘t just forward it unfiltered. If that’s too much, leave it. In case of a bug report, if you don’t want to put in the work, what’s the point? How does the team know your report was verified by you and has merits? It would probably more helpful to leave the team your result in 3-4 sentences and provide the prompt - then they can see for themselves.

That is interesting...

@tobiasb Fixed https://git.cloudron.io/platform/box/-/commit/99cf399454217b113cff1d67ee9ad76a6feadc3f Thanks for reporting.

Hi @james I think it means that - once Cloudron receives an error like NoSuchKey oder 404 not found when polling the object directly after upload - it still retries a number of times with exponentially growing delays added with some random delays ("Jitter"). So the error might only be temporal.

Great, thank you very much @girish !

Oh no, sorry about that regression and thanks for reporting again! This is fixed then for next release with https://git.cloudron.io/platform/box/-/commit/8a65d11fd176d54f868c2b0067087c4ed07e0a24

does it make sense to disable the feature he keeps using?

you are right. https://git.cloudron.io/platform/box/-/work_items/895 is the work item.

@girish said: @xarp Cloudron does not update or switch the kernel or enable any kernel features, no . There is no code for this. Could it be your VPS provider has switched this by mistake? Thanks for confirming girish.

@girish yes, working now!