## 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.
