Hi @james,
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_netfiltermodule is loaded. - Both IPv4 and IPv6 bridge netfilter settings are enabled.
- UFW is inactive.
- The nftables service is inactive and disabled.
- No
netfilter-persistentservice 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:
- Identifying why the Docker-managed firewall chains and NAT rules are missing.
- Restoring
cloudron-firewall.servicewithout disrupting existing application data. - Completing the pending Cloudron database migrations safely.
- 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.