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?

Thank you for your response and for sharing the related discussion.

Unfortunately, I've already tried the suggested recovery procedure, but the issue remains unresolved.

1. Database migration recovery already attempted

I previously ran the following command as the root user:

sudo cloudron-support --apply-db-migrations

The process started but failed when attempting to initialize Cloudron's firewall:

Job for cloudron-firewall.service failed because the control process exited with error code.
[FAIL] Database migrations failed

I also verified that root has working sudo permissions:

sudo -n true && echo "ROOT SUDO WORKS" || echo "ROOT SUDO FAILED"

Result:

ROOT SUDO WORKS

Therefore, the sudo permission issue mentioned in the linked discussion doesn't appear to be the cause in my case.

I haven't separately executed /home/yellowtent/box/setup/start.sh, since the migration recovery command already invokes that startup process and stops at the firewall error.

2. Cloudron firewall failure

The cloudron-firewall.service repeatedly fails with:

iptables: Bad rule (does a matching rule exist in that chain?).
ip6tables: Bad rule (does a matching rule exist in that chain?).
iptables: No chain/target/match by that name.

The firewall initialization script attempts to insert a rule into the DOCKER-USER chain, but that chain appears to be missing or unavailable.

3. Docker networking troubleshooting completed

I have checked the following:

• Docker 29.6.2 is running, with the iptables firewall backend.
• IPv4 forwarding is enabled.
• The br_netfilter module is loaded.
• Both IPv4 and IPv6 bridge netfilter settings are enabled.
• UFW is inactive.
• The nftables service is inactive and disabled.
• No netfilter-persistent service is installed.
• No explicit Docker firewall configuration exists in /etc/docker/daemon.json.
• The Cloudron Docker network uses the bridge driver and is not marked internal.
• Docker's NAT/MASQUERADE rules are absent from both iptables backends.
• Docker's standard forwarding/filtering chains are also missing.

I have also restarted Docker:

sudo systemctl restart docker

Immediately afterward, the DOCKER-USER chain appeared, but subsequent checks showed that it was missing again.

Restarting the Cloudron firewall service did not resolve the issue:

sudo systemctl restart cloudron-firewall.service

The same error persists.

4. Cloudron login is still broken

The login page loads, but attempting to sign in results in:

Internal error, try again later

The box log reports:

Unknown column 'inviteTokenCreationTime' in 'field list'
ER_BAD_FIELD_ERROR (1054)

The diagnostic tool reports pending database migrations, while the other 32 checks passed.

5. Application networking is also affected

My Chatwoot application cannot establish outbound HTTPS connections to Meta or Google from inside its container, although the Ubuntu host can reach both.

Chatwoot's Sidekiq logs repeatedly show:

Net::OpenTimeout:
Failed to open TCP connection to graph.facebook.com:443

As a result, approved WhatsApp templates remain stuck on "Sending."

This suggests that the Docker networking and Cloudron firewall issues may be related.

6. Urgent concern about application data

I'm now particularly concerned about the safety of my application data.

One of the applications hosted on this Cloudron server has not been backed up for approximately one week, and it contains important data that I cannot afford to lose.

The application data may still be intact, but with the Cloudron dashboard inaccessible and the platform update incomplete, I'm concerned that further recovery attempts could put this data at risk.

Before proceeding with additional repairs, could you please advise on the safest way to preserve the existing application data and database in their current state?

Specifically, I would appreciate guidance on whether we should create a server-level snapshot or perform an application/database backup through SSH before attempting any further recovery.

I would also appreciate your help with the following:

1. Identifying why the Docker-managed firewall chains and NAT rules are missing.
2. Restoring cloudron-firewall.service without disrupting existing application data.
3. Completing the pending Cloudron database migrations safely.
4. Restoring the Cloudron dashboard and application connectivity.

I've already spent considerable time diagnosing this issue, and I'm hesitant to perform further restarts, upgrades, or firewall changes without guidance because of the risk to my application data.

Could a Cloudron engineer please review this and recommend the safest recovery procedure?

Thank you for your continued assistance.

I think you might be running into the same or similar issue as here https://forum.cloudron.io/topic/14652/could-not-load-dashboard-website-with-loopback-check-boxerror-unknown-column-pending-in-field-list-update-from-8.3.2-to-9.0.13

the solution was:

@joseph said:

Please run this manually and it should start again:

/home/yellowtent/box/setup/start.sh

Although cloudron-support --apply-db-migrations does run /home/yellowtent/box/setup/start.sh.

You did run cloudron-support with sudo, which might not work correctly.
Just to make sure, please run cloudron-support as the root user:

sudo su -
cloudron-support --apply-db-migrations

and report back, if that resolves the issue.