A
They were only being embedded for the staff on our Nextcloud, not for the public. And we did restrict to our internal domains and had the same issues.
Just thought people should know that some apps don't work at all with CSP, causing these apps GUI to stop loading complely making it look like the app no longer works.
So I found an issue with 3 apps when setting the ability to embed.
Freescout, Chatwoot and Open WebUI
Using the preset configuration to allow embedding
# Allow embedding from all sites
default-src 'self';
frame-ancestors 'none';
It cause a issue with Freescout and Chatwoot loading at all when going directly and shows an error on the website embedding it.
I thought the app became currupt so I installed the setup again and tried to add the CSP again to face the same issue. Chatwoot after removing the CSP did not work but freescout worked again.
Open WebUI just shows a huge Open WebUI logo.
Ok so I deleted the alias we had for it under development and tried to add the mailbox and now its worked. Bare in mind I only added the alias after the error to see if I get the error adding as a alias.
No mailing lists at all. Another strange thing is I can add them as an alias without error.
I am trying to add a mailbox, but it says it already exsists but when I search the mailbox, nothing shows.
Thanks all fixed now. I found this worked even with the line brake.
I have run the command sed -i 's/\r$//g' /app/data/fix_db.sh to fix the new line characters and then run bash /app/data/fix_db.sh again and it ran as expected. Disabled recover mode and confirmed things are back to working as expected.
@james I get this problem.
root@bf8db951-7632-4ddf-bf9b-8b58cd65ffe5:/app/code# bash /app/data/fix_db.sh
/app/data/fix_db.sh: line 2: $'\r': command not found
=> Checking if DEFAULT_CHARACTER_SET_NAME and DEFAULT_COLLATION_NAME are set to utf8mb4 and utf8mb4_unicode_ci
/app/data/fix_db.sh: line 4: $'\r': command not found
/app/data/fix_db.sh: line 8: $'\r': command not found
/app/data/fix_db.sh: line 22: syntax error near unexpected token `$'in\r''
'app/data/fix_db.sh: line 22: ` case $yn in
root@bf8db951-7632-4ddf-bf9b-8b58cd65ffe5:/app/code#
So everytime I upgrade from Vaultwarden 1.34.3 to 1.35.0 the instance becomes unresponsive, saying connection failure in the terminal and nothing really in the logs apart from connection failure again.
Jan 06 12:13:28 0: vaultwarden::init_logging::{{closure}}
Jan 06 12:13:28 10: std::sys::backtrace::__rust_begin_short_backtrace
Jan 06 12:13:28 11: main
Jan 06 12:13:28 12: <unknown>
Jan 06 12:13:28 13: __libc_start_main
Jan 06 12:13:28 14: _start
Jan 06 12:13:28 1: std::panicking::panic_with_hook
Jan 06 12:13:28 2: std::panicking::panic_handler::{{closure}}
Jan 06 12:13:28 3: std::sys::backtrace::__rust_end_short_backtrace
Jan 06 12:13:28 4: __rustc::rust_begin_unwind
Jan 06 12:13:28 5: core::panicking::panic_fmt
Jan 06 12:13:28 6: core::result::unwrap_failed
Jan 06 12:13:28 7: vaultwarden::db::DbPool::from_config
Jan 06 12:13:28 8: vaultwarden::main::{{closure}}
Jan 06 12:13:28 9: vaultwarden::main
Jan 06 12:13:28 Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`.
Jan 06 12:13:28 See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token
Jan 06 12:13:28 [2026-01-06 12:13:28.418][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible."))': src/db/mod.rs:505
Jan 06 12:13:28 [INFO] Using saved config from `/app/data/config.json` for configuration.
Jan 06 12:13:28 [NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure.
Jan 06 12:13:28 \--------------------------------------------------------------------/
Jan 06 12:13:28 | https://github.com/dani-garcia/vaultwarden/discussions or |
Jan 06 12:13:28 | https://github.com/dani-garcia/vaultwarden/issues/new |
Jan 06 12:13:28 | https://vaultwarden.discourse.group/ |
Jan 06 12:13:28 | Report suspected bugs/issues in the software itself at: |
Jan 06 12:13:28 | Send usage/configuration questions or feature requests to: |
Jan 06 12:13:28 | official channels to report bugs/features, regardless of client. |
Jan 06 12:13:37 => Healthcheck error: AbortError: The operation was aborted
Jan 06 12:13:41 => Healthcheck error: Error: connect ECONNREFUSED 172.18.16.123:3000
Jan 06 12:13:41 2026-01-06T12:13:41Z
Jan 06 12:13:41 2026-01-06T12:13:41Z
Jan 06 12:13:41 2026-01-06T12:13:41Z
Jan 06 12:13:41 2026-01-06T12:13:41Z
Jan 06 12:13:41 /--------------------------------------------------------------------\
Jan 06 12:13:41 0: vaultwarden::init_logging::{{closure}}
Jan 06 12:13:41 10: std::sys::backtrace::__rust_begin_short_backtrace
Jan 06 12:13:41 11: main
Jan 06 12:13:41 12: <unknown>
Jan 06 12:13:41 13: __libc_start_main
Jan 06 12:13:41 14: _start
Jan 06 12:13:41 1: std::panicking::panic_with_hook
Jan 06 12:13:41 2: std::panicking::panic_handler::{{closure}}
Jan 06 12:13:41 3: std::sys::backtrace::__rust_end_short_backtrace
Jan 06 12:13:41 4: __rustc::rust_begin_unwind
Jan 06 12:13:41 5: core::panicking::panic_fmt
Jan 06 12:13:41 6: core::result::unwrap_failed
Jan 06 12:13:41 7: vaultwarden::db::DbPool::from_config
Jan 06 12:13:41 8: vaultwarden::main::{{closure}}
Jan 06 12:13:41 9: vaultwarden::main
Jan 06 12:13:41 => Exporting env vars expected by Vaultwarden
Jan 06 12:13:41 => Starting Bitwarden
Jan 06 12:13:41 Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`.
Jan 06 12:13:41 See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token
Jan 06 12:13:41 [2026-01-06 12:13:41.691][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible."))': src/db/mod.rs:505
Jan 06 12:13:41 [INFO] Using saved config from `/app/data/config.json` for configuration.
Jan 06 12:13:41 [NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure.
Jan 06 12:13:41 \--------------------------------------------------------------------/
Jan 06 12:13:41 | Starting Vaultwarden |
Jan 06 12:13:41 | https://github.com/dani-garcia/vaultwarden/discussions or |
Jan 06 12:13:41 | https://github.com/dani-garcia/vaultwarden/issues/new |
Jan 06 12:13:41 | https://vaultwarden.discourse.group/ |
Jan 06 12:13:41 | Report suspected bugs/issues in the software itself at: |
Jan 06 12:13:41 | Send usage/configuration questions or feature requests to: |
Jan 06 12:13:41 | This is an *unofficial* Bitwarden implementation, DO NOT use the |
Jan 06 12:13:41 | official channels to report bugs/features, regardless of client. |
Jan 06 12:13:41 |--------------------------------------------------------------------|
Jan 06 12:13:52 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.16.123:3000
I then have to restore the 1.34.3 version for vaultwarden to work again. I have also had to disable auto update. Please note that I know there are two updates from 1.34.3, but both updates have the same connection issue.
@joseph I might test as the instance of it on Plesk is great, just login lags, as we notice no login lag when run on the Cloudron Server. Thanks for letting us know.
@nebulon That's great. Apart from that, it seems to be running smoothly; it still takes time to propagate the usage stats, but that doesn't really affect us.
I am not sure what version we had; we gave up after 3-4 errors. I can say it was about 6-7 months ago, even though we tried a few times before the 7 months, and we had the problem then. The only fields we had were first name, last name; the communication tab was not even there.
Let's just admit to it, the default fields all need to be reinstated so that modules and HumHub in general work as intended.
Not a problem for us as we get a free license from Plesk and Grants from Akamai.
@girish One other thing
Seeing the menu to edit mailboxes is hidden as the list doesn't utilise the full screen. I thought this was an error at first, until I scrolled all the way to he bottom. The scroller doesn't show until reaching the bottom of the page.
It is a pain to have to scroll down to move across to access the mailbox menu. Especially when deleting multiple mailboxes by domain. Although we found that using the left and right keys on the keyboard sometimes allowed for horizontal scrolling. But still a pain to have to move left and right to make sure you're deleting the correct mailbox or editing it.
It would be so much easier to read if the list utilised the full screen.
Hi Cloudron Team,
We wanted to provide some detailed feedback regarding the current HumHub package on Cloudron. We recently conducted a side-by-side test, installing HumHub on Cloudron and simultaneously on a standard Plesk server.
We encountered several significant issues with the Cloudron package that seem to stem from how the default schema/profile fields are handled compared to a standard installation.
Here are the specific findings:
It appears the Cloudron package removes standard default profile fields that usually ship with HumHub. This causes immediate issues with popular Marketplace Modules:
Birthday Module: Because the DOB (Date of Birth) field was removed/missing in the Cloudron package, installing this module causes an Internal Error immediately.
Maps Module: Similarly, the Address fields are missing, causing the Maps module to throw an Internal Error upon installation.
To attempt a fix, we manually re-added the missing fields to the Cloudron instance by cross-referencing our working Plesk installation (since documentation on the specific default fields was hard to find).
Even after manually recreating the missing fields to match the standard schema, we continued to experience Internal Errors with various other modules.
This suggests the issue might go deeper than just the visible profile fields in the UI.
We encountered a separate issue regarding the Cloudron LDAP integration:
When adding new profile fields, the LDAP setup seems to aggressively lock these fields for new users.
Neither the user nor the Admin can edit these fields; they appear "greyed out" and unclickable in the UI, even though permissions should allow for editing. We could not determine the root cause of this locking behavior.
To verify these weren't upstream HumHub bugs, we tested the exact same scenarios on our Plesk installation:
We had zero issues with module installations.
All default fields were present out-of-the-box.
Modules that crashed on Cloudron (Birthday, Maps) worked perfectly on Plesk.
Due to the stability of the modules on the standard install, we have decided to stick with the Plesk installation for the application itself, but we are using Cloudron as the LDAP provider for user management.
However, we have noticed a performance bottleneck here:
Authentication communication between the external Plesk HumHub and Cloudron's LDAP service is very slow.
Logins can take up to one minute to process.
We hope this feedback helps in refining the HumHub package, specifically regarding the retention of default profile fields to ensure compatibility with Marketplace modules.
Thanks!
So I found that while trying to load mailboxes, it crashes the Mailbox Service. I have had to increase the mailbox to 7GB to get it to load, but still very slow at loading.