All my containers inside Portainer stopped working right after the Portainer update. I can’t ping 8.8.8.8 from inside any container, and internal DNS resolution is completely broken, containers can’t resolve each other’s names, and I can’t even ping other containers directly.
Before anyone asks, the answer is yes. I have already restarted Umbrel several times.
For those encountering the same issue, I managed to resolve the issue by purging the Docker image and subsequently redeploying the container.
Unfortunatelly it didn’t solve the problem. I am still with problems.
Hey! This looks like the same networking issue reported here on GitHub.
Portainer 2.39.4 briefly included a newer Docker runtime that could mess up the container networking rules. The 2.39.4-1 update rolled that change back, but on some systems the broken rules remained afterward. That would explain why deleting and redeploying the containers only helped temporarily.
First, check that the Umbrel App Store shows Portainer 2.39.4-1. Portainer itself may still display 2.39.4, which is normal.
If you’re already on 2.39.4-1 and restarting hasn’t helped, someone with the same issue recovered by running this over SSH:
sudo systemctl stop docker
sudo systemctl stop docker.socket
sudo iptables-legacy -F
sudo iptables-legacy -t nat -F
sudo iptables-legacy -t mangle -F
sudo iptables-legacy -t raw -F
sudo iptables-legacy -X
sudo iptables-legacy -t nat -X
sudo iptables-legacy -t mangle -X
sudo iptables-legacy -t raw -X
sudo nft flush ruleset
sudo reboot
This doesn’t delete your containers, stacks, or volumes. It clears the old networking rules so Docker can recreate them after reboot. If you’ve manually added firewall rules to the Umbrel host, don’t run this since those rules would be cleared too. Hopefully that gets everything talking again.
Works! Thank you!
Hey @aidencole, the problem persists. It’s back. Everything stops here again.
Ah, that’s frustrating. Since clearing the firewall rules only fixed it temporarily, I wouldn’t keep repeating that workaround.
Portainer 2.39.5 is available now and still uses the older Docker runtime from the rollback, so I’d check for that update first. After updating, try stopping Portainer from the Umbrel dashboard and restarting Umbrel. If the networking stays up while Portainer is stopped, that would confirm Portainer is still triggering it.
Could you also say whether this is affecting regular Umbrel apps, Portainer-managed containers, or both? That should help narrow down whether the host networking rules are being broken again or whether it’s isolated to Portainer’s own Docker network.
It affects only containers running within Portainer. All containers are inaccessible.
That detail narrows it down a lot. This looks like the issue described in #5867 and #5919, rather than the original host-wide outage.
Portainer’s nested Docker can end up creating its published-port rules through iptables-legacy, while umbrelOS handles incoming LAN traffic through nftables. That would explain why clearing the firewall fixed it temporarily, then it returned once those rules were recreated. Even the current Portainer 2.39.6 package still uses the same Docker 27.2.0 runtime.
Before clearing anything again, could you test one affected container from the Umbrel itself over SSH? Replace 8090 with one of its published ports:
curl -v --max-time 5 http://127.0.0.1:8090
If that works locally but http://<umbrel-ip>:8090 times out from another device, it’s an exact match for those reports. I wouldn’t delete any Portainer data or repeat the full firewall flush, since this needs a lasting fix to Portainer’s nested Docker networking rather than another container redeploy.