Whoops, good catch. Fixed.

So, on this server legacy iptable modules are being loaded in the kernel. Maybe some change in your server provider? Cloudron doesn't configure or load these modules (cloudron uses nft backend for iptables). Docker is not configuring iptables properly because of this. root@vmi3573607:~# lsmod | grep -E 'iptable_|ip6table_' ip6table_filter 12288 0 ip6_tables 36864 1 ip6table_filter iptable_filter 12288 0 iptable_nat 12288 0 nf_nat 61440 5 xt_nat,nft_chain_nat,iptable_nat,xt_MASQUERADE,xt_REDIRECT ip_tables 32768 2 iptable_filter,iptable_nat x_tables 65536 18 ip6table_filter,xt_conntrack,iptable_filter,nft_compat,xt_LOG,xt_multiport,xt_tcpudp,xt_hashlimit,xt_addrtype,xt_recent,xt_nat,xt_set,ip6_tables,ip_tables,iptable_nat,xt_limit,xt_MASQUERADE,xt_REDIRECT root@vmi3573607:~# cat /proc/net/ip_tables_names /proc/net/ip6_tables_names filter nat filter I manually unloaded them and it work again: sudo modprobe -r iptable_nat iptable_filter ip6table_filter Could an agent or something have loaded these legacy modules?

instinctively, it looks like the mysql addon is blocking new connections probably because of some rate limits (?). The reboot cleared the limit and let the apps connect again.

@pathab thanks for the follow up. https://github.com/haraka/Haraka/pull/3115 removed it. I even tested it back then but forgot to patch our code looks like. I have fixed it now

Hello @madmax48 @madmax48 said: I need to give a second user admin rights on my Cloudron. Is there any way to do that on the Free plan or is the Max plan the only option? That is only possible in the max plan for new Cloudron.io accounts. If your Cloudron.io account is older (like your friends one) you get grandfathering privileges. Then, this would also be possible in the free plan and pro plan.

@nebulon that fix didn't make it into 10.1.6, right? Will there be another intermediate release or will the next one be 10.2?

Thanks for reporting @huehner and for reproducing @james . I have fixed this now. Docker container IPs are not stable and they are allocated dynamically. For example, during container recreate or docker restart. For IPv4, I had fixed this problem a long time ago by statically allocating IPs in Cloudron code. This was never done for IPv6 because I didn't have a use case yet (until now). IPv6 is also statically allocated now.

Aha ! Now I see.

Hello @bbm_noahgilbert I will update the Cloudron docs https://docs.cloudron.io/services/ to include this information. Thanks for bringing this to my attention.

Thanks for the report, this is fixed for next release with https://git.cloudron.io/platform/box/-/commit/480a96b6567650cae81c0fe14763ee9730a1e79d

@james thanks! Related: cloudron/php-base:8.5-20261021 and the current WordPress package (3.17.1) still ship libbrotli1 1.2.0-3build1, while the Ubuntu fix for CVE-2026-111497 is 1.2.0-3ubuntu0.1. PHP apps reach this through libcurl, as WordPress decodes Brotli on outbound requests (see Patchstack's write-up, https://patchstack.com/articles/wordpress-doesnt-ship-brotli-its-still-exposed-to-cve-2026-111497/). Could the PHP base get a rebuild as well?

I have fixed this now. Thanks for reporting @nostrdev

This is fixed now .

@huehner Good catch, fixed now.

Hi Nebulon, Thank you for your clear explanation and for taking the time to respond publicly. I understand now why the App Store no longer works with Cloudron 7.4.1. As part of my systems and network administration internship, I have been working on a Nextcloud migration scenario involving legacy Cloudron installations. Following the advice received here, I updated my test environment and successfully restored a Nextcloud backup using the Cloudron REST API. My current test environment consists of: Source: Cloudron 10.0.4 Destination: Cloudron 10.1.5 Nextcloud package: 4.17.0 I am now completing the functional checks, particularly user accounts, file integrity, sharing permissions and authentication. Your explanation confirms that upgrading Cloudron was the appropriate approach. Thank you again for your support and for helping me better understand the technical limitations of older Cloudron versions. Best regards, Romuald

@sdeinfo OIDC Implicit flow has been deprecated for a while now and should not be used in new applications - https://oauth.net/2/grant-types/implicit/ . In fact, in the over 200 packages we maintain only one app uses implicit flow. Yup, guacamole. I very reluctantly added a hack in the manifest to get that package working. I found that a fix is being worked on upstream - https://github.com/apache/guacamole-client/pull/1219 . You can also try https://github.com/Gerry9000/guacamole-auth-sso-oauth2 which fixes this exact issue . We will be moving to that repo shortly if upstream doesn't fix it soonish.