claudetools/session-logs/2026-06/2026-06-27-mike-jupiter-plexrequest-seerr-dns-relay.md

User

• User: Mike Swanson (mike)
• Machine: GURU-5070
• Role: admin

Work performed 2026-06-26 (Phoenix); log saved just after midnight 2026-06-27. UOS Rocky update and Wolkin SMB fix from earlier in the same session are logged separately (session-logs/2026-06/2026-06-26-mike-uos-rocky-update.md, clients/wolkin/session-logs/2026-06/2026-06-26-mike-wolkin-smb-zerotier-adapter.md).

Session Summary

Restored the plexrequest.azcomputerguru.com service on Jupiter, which the user reported down. NPM proxies that hostname to 172.16.3.31:5055. Diagnosis showed the backing container ("Seerr", Unraid template my-Seerr.xml, appdata /mnt/user/appdata/seerr) had been removed entirely from Docker (gone from docker ps -a; every other container came back after a Docker restart ~15h prior, Seerr did not). The image (ghcr.io/seerr-team/seerr:latest) and appdata were intact, so the container was recreated on br0 172.16.3.31. It served, but redirected to /setup — initialized:false. Investigation found this Seerr instance was a half-finished May-27 migration that was never configured; the real working data lived in the old binhex-overseerr appdata (/mnt/user/appdata/binhex-overseerr/overseerr), whose container was also gone.

The user confirmed Seerr is the maintained successor to Overseerr (Overseerr being abandoned) and asked to migrate. Verified the old Overseerr data was a genuine configured instance (initialized:true, Plex + Radarr/Sonarr configured, real user accounts, 191 requests in a 180KB db + 4MB uncommitted WAL). Backed up, copied the Overseerr config into Seerr's appdata, fixed ownership to 99:100, and started Seerr — its built-in auto-migration ran ("Overseerr to Seerr migration completed successfully"), preserving all data (191 requests, users, Plex/Radarr/Sonarr config). Verified public access (HTTP 200 -> /login, Cloudflare-fronted).

The user then reported it was "REALLY slow." Backend measured fast (8ms API, 110ms login), so the cause was elsewhere: every external lookup inside the container took ~4s. Root cause was DNS — Jupiter's primary resolver 172.16.3.50 is dead (100% ping loss, :53 times out ~5s), yet it is first in the host /etc/resolv.conf, so every cache-miss lookup waited for it before falling back to 8.8.8.8. Seerr (very DNS-heavy via TMDB) was worst hit. Fixed Seerr by recreating it with --dns 1.1.1.1 --dns 8.8.8.8 and LOG_LEVEL=info (was debug, dumping a full Radarr JSON per title), and added it to the Unraid autostart list. In-container lookups dropped 4s -> ~0s.

Finally, to revive .50 for every other device/config still pointed at it, deployed a dns-relay container (dnsmasq 4km3/dnsmasq) on br0 172.16.3.50 forwarding all queries to the gateway 172.16.0.1 (pfSense unbound, verified healthy). Verified resolution through .50 from a sibling container and a LAN client (0.32s cold / 0.04s cached). Also fixed the Unraid my-Seerr.xml template (was bridge; set to br0/.31) so a UI re-apply won't break the NPM target. Closed with a general advisory on forcing SharePoint docs to open in desktop Office (no changes made).

Key Decisions

• Recreated Seerr on br0 172.16.3.31 (not bridge) to match the NPM target and the sibling binhex containers' addressing; the template's bridge was stale.
• Chose to migrate Overseerr -> Seerr rather than finish a fresh Seerr setup, to preserve the 191 requests / users / Plex config. Migration is the official supported path (auto on first boot).
• Copied the Overseerr appdata (cp -a, all three sqlite files) so the 4MB WAL replayed rather than checkpointing the source — source left untouched as a rollback.
• Fixed Seerr slowness with a per-container --dns override (immediate, low-risk) instead of changing the host DNS config, then solved the broader problem with a relay at .50 so no LAN devices need repointing.
• Set LOG_LEVEL=info — the template default debug generated heavy per-title log IO.
• Left the dead .50 host-DNS-config decision (Unraid Network Settings) to the user; only flagged it. The relay covers LAN clients; Jupiter's own host can't use it (ipvlan host->own-container).

Problems Encountered

• plexrequest down — backing Seerr container removed from Docker. Recreated from intact image+appdata on br0 .31.
• Recreated Seerr showed /setup — appdata was a never-configured half-migration. Resolved by migrating the real Overseerr data in.
• "REALLY slow" — root cause dead primary DNS 172.16.3.50 adding ~5s per cache-miss lookup. Fixed Seerr via --dns; deployed dns-relay at .50 -> 0.1 for everything else.
• plink first connect hung in -batch (host key uncached). Resolved by pinning -hostkey SHA256:czsrHxWg1cPekUeyn1D5V+u8oXgI0f5QUXRdJBv9tPc.
• python3 absent on Unraid host — used grep + host /usr/bin/sqlite3 for db/settings checks.
• ipvlan off-subnet TCP — curl to 172.16.3.31:5055 from GURU-5070 returned 000 while ping worked; verified the service from the Jupiter host / sibling container instead (a vantage-point artifact, not a fault).

Configuration Changes

• Jupiter (live, not in git):
  • Recreated container Seerr (br0 172.16.3.31:5055, --init --user 99:100, --restart unless-stopped, --dns 1.1.1.1 --dns 8.8.8.8, LOG_LEVEL=info, image ghcr.io/seerr-team/seerr:latest, appdata /mnt/user/appdata/seerr).
  • Migrated /mnt/user/appdata/binhex-overseerr/overseerr -> /mnt/user/appdata/seerr (chown 99:100).
  • New container dns-relay (br0 172.16.3.50:53, dnsmasq 4km3/dnsmasq, --no-resolv --no-hosts --server=172.16.0.1 --cache-size=1000, --restart unless-stopped).
  • /var/lib/docker/unraid-autostart: added dns-relay (first), replaced stale binhex-overseerr with Seerr. Backup *.bak-20260626.
  • /boot/config/plugins/dockerMan/templates-user/my-Seerr.xml: <Network>bridge</Network> -> <Network>br0</Network>, <MyIP/> -> <MyIP>172.16.3.31</MyIP>. Backup *.bak-20260626.
• Repo (this commit): wiki/systems/jupiter.md — Docker table (Seerr + dns-relay rows), NPM table (plexrequest=Seerr), Known Issues (plexrequest migration + slowness/DNS fix, dead .50 resolver entry), frontmatter bumped.

Credentials & Secrets

• Jupiter (Unraid) root SSH — already vaulted: infrastructure/jupiter-unraid-primary.sops.yaml (credentials.username=root, credentials.password). Used via PuTTY plink. No new credentials created. Jupiter SSH host key fingerprint: SHA256:czsrHxWg1cPekUeyn1D5V+u8oXgI0f5QUXRdJBv9tPc.

Infrastructure & Servers

• Jupiter 172.16.3.20 (Unraid, Dell, br0 ipvlan subnet 172.16.0.0/22, gw 172.16.0.1).
• plexrequest = Seerr container, br0 172.16.3.31:5055, behind NPM (plexrequest.azcomputerguru.com, Cloudflare-fronted -> bare curl returns 403, use browser UA).
• dns-relay container, br0 172.16.3.50:53 -> forwards 172.16.0.1.
• Dead resolver: 172.16.3.50 (old primary DNS, host down) — now impersonated by the relay.
• pfSense gateway / DNS: 172.16.0.1:53 (unbound), healthy (0.06s lookups).
• Plex server (binhex-plexpass) br0 172.16.3.32:32400 — Seerr's configured media server.

Commands & Outputs

• SSH: plink -ssh -pw <pw> -batch -hostkey SHA256:czsr... root@172.16.3.20 '<cmd>'
• Migration (key): cp -a /mnt/user/appdata/binhex-overseerr/overseerr /mnt/user/appdata/seerr; chown -R 99:100 /mnt/user/appdata/seerr; docker start Seerr -> [Seerr Migration]: Yeah! Overseerr to Seerr migration completed successfully!
• DNS proof: in-container nslookup api.themoviedb.org 4.02s (before) -> ~0s (after --dns). nslookup api.themoviedb.org 172.16.3.50 from host = timeout/host-unreachable; ... 172.16.0.1 = 0.06s. LAN client via relay: 0.32s cold / 0.04s cached.
• Verify: curl -sk http://172.16.3.31:5055/api/v1/status -> {"version":"3.2.0",...}; public (browser UA) / -> 200 -> /login. DB: 191 media_request rows.

Pending / Incomplete Tasks

• Jupiter host's own DNS still lists dead .50 first; host can't use the relay (ipvlan host->own-container). Optional: set DNS1=172.16.0.1 in Unraid Settings -> Network Settings (/boot/config/network.cfg DNS_SERVER1). Pending user decision on what .50 was.
• Seerr Plex Scan error post-migration: Cannot read properties of undefined (reading 'some') — re-select Plex libraries in Seerr -> Settings -> Plex to clear (UI task).
• dns-relay has no Unraid template (created via docker run) — optional to add one.
• A failed local sign-in by mike@azcomputerguru.com was logged during testing — use Plex SSO or reset the local Seerr password if needed.
• Backups to clean up later: /mnt/user/appdata/_migbackup_20260626/overseerr-source.tgz, /mnt/user/appdata/seerr.empty.preMig.

Reference Information

• Seerr migration docs: https://docs.seerr.dev/migration-guide/
• Image: ghcr.io/seerr-team/seerr:latest (v3.2.0); relay image 4km3/dnsmasq:latest (dnsmasq 2.91).
• SharePoint "open in desktop app" advisory (no change made): per-library Advanced settings -> "Open in the client application"; site-collection feature "Open Documents in Client Applications by Default"; or per-user Sync/"Add shortcut to OneDrive". Caveat: Business Basic (no desktop Office license) users can hit an error instead of browser fallback.

Update: 06:52 PT — finish killing the dead .50 resolver (Jupiter host + pfSense)

Continuation of the DNS-relay work: eradicated the dead 172.16.3.50 from all active config.

1. Jupiter host DNS1 -> 172.16.0.1. /boot/config/network.cfg DNS_SERVER1="172.16.3.50" -> "172.16.0.1" (kept 8.8.8.8/1.1.1.1 as DNS2/3), and live /etc/resolv.conf first nameserver updated. No network restart (would risk the SSH session). Backups network.cfg.bak-20260627, resolv.conf.bak-20260627. Host lookups now fast (was ~5s stall; the host couldn't use the .50 relay container due to ipvlan host->own-container).

2. pfSense LAN DHCP DNS — already correct, no change. Read config.xml: the only DHCP scope (lan, range 172.16.1.1-254) already hands out <dnsserver>172.16.0.1</dnsserver> first, then 8.8.8.8, 1.1.1.1. So DHCP was never the source of the dead .50 — affected hosts were statically configured (e.g. Jupiter, now fixed) and/or covered by the relay. pfSense system DNS = 8.8.8.8/1.1.1.1; unbound (DNS Resolver) running on :53.

3. pfSense OpenVPN wizard state scrubbed. The only other .50 in config.xml was $config['ovpnserver']['step10']['dns1']=172.16.3.50 — pfSense's saved OpenVPN setup-wizard state, NOT a live server (the <openvpn> config is empty; remote access is Tailscale/WireGuard). So it was inert (not pushed to any client) — my earlier "VPN clients get .50" framing was wrong. Scrubbed to 172.16.0.1 anyway (hygiene; prevents a future wizard re-run reintroducing it) via php write_config() using the skill's proven config.inc bootstrap, no service reload. Backup /tmp/config.xml.predns-20260627.bak on the box + pfSense config-history revision. The only remaining .50 string in config is that revision's own change-note (metadata, scrolls off).

Tooling note: all pfSense access went through the unifi-wifi pfSense SSH backend (pfsense-ssh.sh infrastructure/pfsense-firewall run "<cmd>") — authenticated path (askpass + vaulted password, port 2248), not hand-rolled ssh. No dedicated DHCP/DNS verb exists, so used run.

Update — Configuration Changes

• Jupiter (live): /boot/config/network.cfg DNS_SERVER1 -> 172.16.0.1; /etc/resolv.conf live.
• pfSense (live, config.xml via write_config): ovpnserver/step10/dns1 172.16.3.50 -> 172.16.0.1.
• No repo files changed in this update (infra-only). wiki/systems/pfsense.md note still TODO.

Update — Infrastructure & Servers

• pfSense office gateway 172.16.0.1, SSH port 2248, user admin, pfSense 2.8.1 (FreeBSD). Vault infrastructure/pfsense-firewall.sops.yaml. Tailscale 100.79.69.82/100.119.153.74. LAN DHCP scope 172.16.1.1-254; unbound resolver on :53 (verified 0.06s).
• Dead host 172.16.3.50 now fully decommissioned in config; dns-relay container still answers .50 for any static straggler. New DHCP clients get 172.16.0.1 directly.

Update — Pending / Incomplete Tasks

• Optional: note this pfSense .50 cleanup + DHCP finding in wiki/systems/pfsense.md.
• Seerr Plex Scan error follow-up (re-select Plex libraries) still open from earlier.