# Seerr innaccessible **URL:** \ **Category:** Support and Troubleshooting\ **Created:** [June 28, 2026, 2:29pm UTC](https://community.umbrel.com/t/seerr-innaccessible/25243 "2026-06-28T14:29:36Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![FrazzledSysAdmin](https://avatars.discourse-cdn.com/v4/letter/f/dbc845/32.png) [@FrazzledSysAdmin](https://community.umbrel.com/u/FrazzledSysAdmin)\ **Post date:** [June 28, 2026, 2:29pm UTC](https://community.umbrel.com/t/seerr-innaccessible/25243/1 "2026-06-28T14:29:36Z")
Hello, seerr is currently not loading when I attempt to access the page. The app is showing as running however it will not load when I attempt to go to it’s IP:port. > jellyseerr\_app\_proxy\_1 | yarn run v1.22.19 jellyseerr\_app\_proxy\_1 | $ node ./bin/www jellyseerr\_app\_proxy\_1 | [HPM] Proxy created: / → http://jellyseerr\_server\_1:5055 jellyseerr\_app\_proxy\_1 | Waiting for jellyseerr\_server\_1:5055 to open… jellyseerr\_app\_proxy\_1 | Seerr is now ready… jellyseerr\_app\_proxy\_1 | Listening on port: 5056 jellyseerr\_server\_1 | jellyseerr\_server\_1 | \> seerr@3.3.0 start jellyseerr\_server\_1 | \> NODE\_ENV=production node dist/index.js jellyseerr\_server\_1 | jellyseerr\_server\_1 | 2026-06-28T14:19:44.139Z [info]: Commit Tag: 703faf95f454ffecae99a5e86ea761b3b524c6df jellyseerr\_server\_1 | 2026-06-28T14:19:44.375Z [info]: Starting Seerr version 3.3.0 jellyseerr\_server\_1 | 2026-06-28T14:19:45.453Z [debug][Settings Migrator]: Checking migration ‘0001\_migrate\_hostname.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.455Z [debug][Settings Migrator]: Checking migration ‘0002\_migrate\_apitokens.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.456Z [debug][Settings Migrator]: Checking migration ‘0003\_emby\_media\_server\_type.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.456Z [debug][Settings Migrator]: Checking migration ‘0004\_migrate\_region\_setting.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.457Z [debug][Settings Migrator]: Checking migration ‘0005\_migrate\_network\_settings.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.457Z [debug][Settings Migrator]: Checking migration ‘0006\_remove\_lunasea.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.458Z [debug][Settings Migrator]: Checking migration ‘0007\_migrate\_arr\_tags.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.459Z [debug][Settings Migrator]: Checking migration ‘0008\_migrate\_blacklist\_to\_blocklist.js’… jellyseerr\_server\_1 | 2026-06-28T14:19:45.463Z [info][Notifications]: Registered notification agents jellyseerr\_server\_1 | 2026-06-28T14:19:45.478Z [info][Jobs]: Scheduled jobs loaded jellyseerr\_server\_1 | 2026-06-28T14:19:45.524Z [info][Server]: Server ready on port 5055 I’ve already attempted restarting umbrel and reinstalling the app as well. I’m honestly stumped on what could be going on. Any help would be appreciated ---
**Author:** ![FrazzledSysAdmin](https://avatars.discourse-cdn.com/v4/letter/f/dbc845/32.png) [@FrazzledSysAdmin](https://community.umbrel.com/u/FrazzledSysAdmin)\ **Post date:** [July 4, 2026, 5:30pm UTC](https://community.umbrel.com/t/seerr-innaccessible/25243/2 "2026-07-04T17:30:31Z")
I ended up doing a full reimage of the server and I was able to reproduce the issue. I was able to fix it by doing a roll back to prior version of the host image. After that everything was working until I updated Seerr and Portainer… if I leave one of them behind a version everything works fine. So most likely change within one of those apps is causing an issue with the docker network. ---
**Author:** ![aidencole](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@aidencole](https://community.umbrel.com/u/aidencole)\ **Post date:** [July 14, 2026, 2:49pm UTC](https://community.umbrel.com/t/seerr-innaccessible/25243/3 "2026-07-14T14:49:39Z")
hey, i think you pretty much figured it out. seerr itself actually looks fine in those logs — it starts normally and umbrel’s proxy is able to reach it. there was a known bug in Portainer 2.39.4 where its bundled Docker version messed with the host’s firewall rules. that could make completely unrelated apps unreachable, even though they still showed as running. sounds like the exact same issue reported here: > > > \### App ID > > Portainer > > \### umbrelOS version > > 1.7.3 > > \### Device architecture > > I d…on't know > > \### When did this happen? > > App update > > \### What failed? > > Other > > \### Expected behavior > > Portainer's DinD sidecar should not interfere with the host Docker daemon's iptables rules. > > \### Actual behavior > > After the Portainer v2.39.4 update, the DinD container (\`docker:29.6.0-dind\`) starts its own Docker daemon on the host network. This daemon overwrites the host's \`DOCKER-FORWARD\` iptables chain, inserting ACCEPT rules only for its own bridges (\`br-1044f58e916e\`, \`dind0\`) while leaving the chain's default policy at DROP. The host's \`umbrel\_main\_network\` bridge (\`br-d15187fee91b\`) is not included, so all outbound traffic from every other Umbrel app container is silently dropped. In my case, cloudflared lost its tunnel connection and could not re-establish it, effectively taking all Cloudflare-tunneled services offline. DNS resolution, QUIC, TCP, and Cloudflare API connectivity all failed from within containers, while the host itself retained full internet access. > > \### Diagnosis or agent summary > > After updating Portainer from v2.39.3 to v2.39.4, all containers on the \`umbrel\_main\_network\` bridge lose outbound internet connectivity. This breaks cloudflared tunnels, Immich, and any other app that needs to reach the internet. > > \## Root Cause > > The v2.39.4 update bumped the bundled DinD sidecar from \`docker:27.2.0-dind\` to \`docker:29.6.0-dind\`. Because this container runs with \`privileged: true\` and \`network\_mode: host\`, the DinD's Docker daemon takes control of the host's iptables chains (\`DOCKER-FORWARD\`, \`DOCKER-CT\`, \`DOCKER-BRIDGE\`). > > Docker 28+ introduced a new firewall management system. The DinD daemon only adds ACCEPT rules for its own networks (\`br-1044f58e916e\`, \`dind0\`) while the default policy for \`DOCKER-FORWARD\` is DROP. This effectively blocks all traffic for \`umbrel\_main\_network\` (\`br-d15187fee91b\`), killing outbound connectivity for every other Umbrel app. > > \## Steps to Reproduce > > 1. Install Portainer on UmbrelOS 1.7.3 > 2. Update to v2.39.4 (or install fresh) > 3. Wait ~1 minute for the DinD container to start and overwrite iptables > 4. Observe that all other apps lose internet access (e.g. cloudflared tunnel disconnects) > > \## Expected Behavior > > Portainer's DinD sidecar should not interfere with the host Docker daemon's iptables rules. > > \## Workaround > > Manually edit \`/home/umbrel/umbrel/app-data/portainer/docker-compose.yml\` and change the DinD image back to: > > \`\`\` > docker:27.2.0-dind@sha256:f9f72ad901a78f27be922b2d320bbc263174f12919c1b37e6a01f828fa904565 > \`\`\` > > Then reboot Umbrel (or restart Docker). > > \### Logs or screenshots > > \_No response\_ Portainer 2.39.4-1 has the fix, so i’d update Portainer and then reboot the whole Umbrel, not just restart the apps. after that, try opening Seerr from the dashboard or at: `http://YOUR-UMBREL-IP:5056` `5055` is only the internal Seerr port, so that one wont work directly in a browser. you defintely shouldn’t need to reimage everything again. if it’s already on Portainer 2.39.4-1 and still broken, i’d stop Portainer, reboot once more, and test Seerr while Portainer is left stopped.