gurulee

Plex on Unraid invisible to app.plex.tv and modern apps — RCA + fix (linuxserver/plex)

Symptom:
- Plex Media Server running in Docker on Unraid (linuxserver/plex, ipvlan on a tagged VLAN).
- Server was reachable just fine for some clients (Samsung TV native app, Plexamp Android, LAN clients using cached direct IPs) , but completely invisible to others:
- app.plex.tv in any browser (showed "No content available" or "Unable to connect to '<server>' securely")
- Google TV / Fire TV native Plex apps
- Several remote users on TV / streaming-stick clients
- Restarting the Plex container restored access for ~15–30 minutes, then it disappeared again.
- Direct hits to the server's plex.direct HTTPS URL worked perfectly. TLS cert was valid. LAN access on
http://<server-ip>:32400/web worked.

The intermittent "works for 15–30 min after restart" pattern strongly resembled a firewall state-table eviction problem, which sent me down a long wrong rabbit hole.

Things I (incorrectly) suspected first:
- DNS rebind protection / Unbound stripping plex.direct
- NAT reflection / hairpin NAT
- VLAN firewall rules
- Custom server access URL
- Container DNS
- OPNsense pf state engine reaping idle WebSockets (I changed Firewall Optimization from Normal to Conservative — this was not the fix)

All of those were red herrings.

Actual root cause:
PMS was not publishing HTTPS endpoints to plex.tv's /api/v2/resources discovery catalog. The catalog was advertising only plain http:// URIs for my server. Modern Plex clients (app.plex.tv browser, Google TV apps, etc.) run in an HTTPS context and refuse to fall back to plain HTTP due to mixed-content rules — so to them the server looks unreachable. Older / cached-connection clients bypass v2 and kept working, which made it look like a client-specific problem.

The chain that produced the broken state:
1. secureConnections="0" (Disabled) in Preferences.xml — easy to miss because the WebUI dropdown order is Disabled / Preferred / Required, and "Disabled" looked like Preferred at a glance. With this set to Disabled, PMS will not publish HTTPS endpoints to plex.tv at all, regardless of cert validity.
2. PMS rewrites Preferences.xml on every startup, so sed edits to flip the value were silently clobbered.
3. Even after fixing it to Required via the WebUI, internal publish state was stuck — MyPlex: attempted a reachability check but we're not yet mapped kept appearing in logs and v2 still showed HTTP only.
4. PLEX_CLAIM is not a re-claim mechanism on linuxserver/plex. It's only honored on first start when PlexOnlineToken is empty in Preferences.xml. Setting it on an already-claimed server is silently ignored.
5. Even after a forced re-registration that pulled a brand-new cert, plex.tv still had the old HTTP-only connection list cached. PMS only pushes a fresh connection list when something explicitly triggers it.

Diagnostic command (the one that finally pinpointed it)

This compares what plex.tv is telling clients about your server. Run on the Unraid host:
```
cd "/mnt/user/appdata/plex/Library/Application Support/Plex Media Server"
TOKEN=$(grep -oP 'PlexOnlineToken="\K[^"]+' Preferences.xml)
curl -s "https://plex.tv/api/v2/resources?X-Plex-Token=$TOKEN&includeHttps=1" \
-H "Accept: application/json" \
-H "X-Plex-Client-Identifier: diag-test" \
| jq '.[] | select(.name=="YOUR_SERVER_NAME") | .connections'
```
Note: the v2 endpoint requires an X-Plex-Client-Identifier header or it returns 400. v1 doesn't.

If you see only "protocol": "http" entries and no https://*.plex.direct:32400 URIs — this is your problem. A working server returns both an HTTPS LAN and an HTTPS WAN plex.direct URI.
Fix (verified working, preserves MachineIdentifier so shares/library state are intact)
1. In the Plex WebUI: Settings → Server → Network → set Secure connections to Required (or at least Preferred). Save.
2. Stop the Plex container in the Unraid WebUI.
3. From a terminal on the Unraid host: PMS="/mnt/user/appdata/plex/Library/Application Support/Plex Media Server"
```
cd "$PMS"
cp Preferences.xml "Preferences.xml.bak-$(date +%Y%m%d-%H%M%S)"
sed -i 's/ PlexOnlineToken="[^"]*"//g;
s/ PlexOnlineUsername="[^"]*"//g;
s/ PlexOnlineMail="[^"]*"//g;
s/ PlexOnlineHome="[^"]*"//g' Preferences.xml
rm -f Cache/cert-v2.p12
```
4. Get a fresh claim token from https://plex.tv/claim (4-minute lifetime).
5. Edit the Plex container template in Unraid and add an env var PLEX_CLAIM=claim-xxxxxxxxxxxx. Apply (container starts).
6. Wait ~60 seconds for PMS to re-claim and pull a fresh cert. Then remove the PLEX_CLAIM env var from the template — it's one-shot and a stale claim token sitting in your template is a footgun on future restarts.
7. In the Plex WebUI: Settings → Server → Remote Access → Disable, then Enable. This is what actually triggers PMS to push a fresh connection list (HTTPS endpoints) up to plex.tv — without this step, the v2 catalog stays stale.
8. Re-run the diagnostic curl above and confirm the connections array now contains https://...plex.direct:32400 URIs for both LAN and WAN.
9. Test app.plex.tv in a browser. Remote users seeing stale state should sign out/in.

Things worth knowing:
- secureConnections="0" = "do not publish HTTPS to plex.tv", full stop. The local cert can be perfect; doesn't matter.
- PMS rewrites Preferences.xml on every startup. Editing XML by hand for most settings is futile — PMS will clobber it. The token-strip step in this procedure works because PMS will accept a fresh token rather than overwrite the missing one.
- PLEX_CLAIM on linuxserver/plex only fires on first start with an empty token. To force re-claim you must strip the token attrs AND delete Cache/cert-v2.p12.
- Changing publish-related settings does not auto-republish. PMS only pushes a new connection list to plex.tv on specific triggers — the Remote Access OFF→ON toggle is the most reliable one. PublishServerOnPlexOnlineKey=false → =true appears in Plex
Media Server.log when it fires.
- mappingState="mapped" in /myplex/account only means plex.tv knows your public IP/port. It does NOT mean HTTPS endpoints are published. Two separate pieces of state.
- NAT: PMP, timed out log warnings are noise if you don't run NAT-PMP/UPnP (e.g., manual port-forward on OPNsense/pfSense).
- [CERT] TLS connection ... unrecognized plex.direct SNI name warnings = clients still using a cached old cert hash. They self-resolve as clients refresh from the v2 catalog.
- Compare your server's v2 output to a friend's working server early. If yours shows only HTTP URIs and theirs shows HTTPS plex.direct URIs, you've found the bug in minutes instead of days.

Hope this saves someone a couple of days. The "works for 15 minutes after a restart" pattern is incredibly misleading — it screams "firewall state eviction" but in my case it was actually plex.tv's discovery catalog falling back to stale data after each restart.

I was able to enforce login with SSO (Authentik) and disable Jellyfin manual login, and hide forgot password using this Jellyfin custom CSS code under Branding:

a.raised.emby-button {
padding: 0.9em 1em;
color: inherit !important;
}
.disclaimerContainer {
display: block;
}
/* Hide manual login form */
.manualLoginForm {
display: none !important;
}
/* Hide 'Forgot password' button */
.btnForgotPassword {
display: none !important;
}

====
I did not need to use Authentik include or explicit location blocks in my Swag / NGNIX subdomain conf file.