Server stuck at provides="sync" with phantom productVersion=4.18.1

Plex Media Server
1

**Server Version#:** 1.43.0.10492-121068a07 (Docker container, the official `linuxserver/plex` image, `network_mode: host`, Linux x86_64). Pinned at 1.43.0 because 1.43.1 had a worse version of this same regression for me — but the bug affects 1.43.0 too.

**Player Version#:** Server-side bug at the Plex resources layer — affects every client uniformly because the server itself becomes invisible. Verified across: Plex Web (Chrome 124), Plex for iOS, Plex for LG WebOS, Plex for Android TV. No player-side workaround possible.

**Logs**: debug-level only (no verbose). Excerpts attached / linked.

-–

# Server stuck at `provides=“sync”` with phantom `productVersion=“4.18.1”` — only device-delete + re-claim resets it (recurs every 8–12 days)

## Symptom

Every 8–12 days my server becomes invisible to all clients (admin + 12 shared users): the Plex web app shows “Your home screen is empty” and the settings page returns “There was an unexpected error loading the settings”. The local web UI on port 32400 (bypassing the Plex cloud) keeps working — only Plex-cloud-mediated discovery breaks.

## Diagnosis

The active device entry returned by the Plex resources XML endpoint reverts to:

```

<Device name=“Fawaz” product=“Plex Media Server”

    productVersion="4.18.1" provides="sync"

    clientIdentifier="<active-mid>" ...>

```

`productVersion=“4.18.1”` is a phantom. My PMS has only ever been on 1.27.x → 1.42.x → 1.43.0 builds. `grep -r “4.18.1”` across `/config/Library/Application\ Support/Plex\ Media\ Server/` returns zero matches. The value lives only on Plex’s cloud side.

Because every Plex client filters resources by `provides=“server”`, a `provides=“sync”` registration makes the server invisible to all of them — even though PMS itself is healthy and serving requests fine on the LAN.

## What PMS is doing during the failure (it thinks everything is fine)

```

PublicAddressManager: Got public IP from v4:

NAT: UPnP, mapped port 27814 to :32400

PublicAddressManager: Mapping succeeded for :27814

HTTP requesting GET ..plex direct:27814/identity

200 response from GET ..plex direct:27814/identity ← reachability OK

PUT plex tv /devices/?Connection[][uri]=…&httpsEnabled=1&dnsRebindingProtection=0… → 200 OK

MyPlex: Last published value didn’t change, we’re done.

```

PMS’s self-reachability test passes. PMS publishes the correct connection URIs. The Plex cloud accepts the publish (HTTP 200). PMS reports that the published value matches what it expects. **And yet the resources XML endpoint still returns the wrong value.** This is the smoking gun pointing at Plex-cloud-side cache rot, not PMS.

## What does NOT fix it (each empirically tested today)

| Approach | Result |

|—|—|

| `docker compose restart plex` | reverts within seconds |

| `PUT /:/prefs?PublishServerOnPlexOnlineKey=1` (re-publish) | flips to `server` for <30s, then reverts |

| `PUT /:/prefs?ManualPortMappingMode=1` with various ports | UPnP discovery still runs regardless of this flag — instant revert when the new self-test fails |

| Web UI “Disable Remote Access” toggle | counterproductive: sets `PublishServerOnPlexOnlineKey=0`, the Plex cloud defaults unpublished servers to `provides=sync`, making the stuck cache the winning value |

| Strip `PlexOnlineToken` from Preferences.xml + restart unclaimed + auto re-claim via the claim-token API (a script I run on cron) | works **temporarily** (8–12 days) — cache reverts again |

## What DOES fix it (the “nuclear” path)

1. `DELETE /devices/{id}.xml` against the Plex API — evicts the stuck device entry on the Plex cloud (also invalidates the token).

2. Strip `PlexOnlineToken` / `PlexOnlineUsername` / `PlexOnlineMail` / `PlexOnlineHome` from Preferences.xml.

3. Restart PMS, wait ~2 min for full init.

4. Fetch a fresh `claim-XXX` from the Plex claim page.

5. `POST localhost:32400/myplex/claim?token=claim-XXX`.

A fresh device entry appears with the correct `productVersion=1.43.0.10492-121068a07` and `provides=“server”`. ~3 minutes of downtime, no data loss. Did this today; will see how long it holds.

## Collateral bug — `` records silently wiped on device delete

After the nuclear path, all 12 of my `` grants on the Plex cloud are gone. Friends and home users couldn’t see the server until I re-created them via `POST /api/servers/$MID/shared_servers` with an XML body. Two surface inconsistencies on that endpoint that cost me real time:

- JSON and form-urlencoded bodies both 4xx on this endpoint; only lowercase XML `<shared_server>` with snake_case attributes works.

- Friends use `invited_email`; home users (where `email` is empty in `/api/home/users`) need `invited_id` with the Plex user ID. `invited_email=“”` for a home user 400s.

Neither the wipe behavior nor the recovery API is documented anywhere I could find — had to reverse-engineer from old forum posts.

## Speculation on the root cause

Looks like there are at least two caches behind the resources XML endpoint:

1. A **live cache** updated by PMS heartbeats — tracks correctly during the healthy window after every claim.

2. A **secondary cache** (periodic reconciliation? CDN edge? background metadata refresh?) that holds the `productVersion=4.18.1` ghost and periodically wins over the live cache.

The ghost value (`4.18.1`) is identical across recurrences over a 3-week window and survives full PMS restarts → it’s persisted server-side, not transient. Recurrence appears correlated with WAN IP changes (my ISP rotates IPv4 every 1–2 weeks), which suggests cache 2 might be re-keyed or re-refreshed when the Plex cloud notices the IP change, and the wrong value gets pulled in.

`4.18.1` is suspicious — that looks like it could be a **Plex client app** version (Plex for iOS / Apple TV are in the 4.x range), not a PMS version. I wonder if there’s a code path that, under some condition, mis-keys a server’s metadata to a client app’s record.

## Asks

1. Investigate why a deleted-and-recreated server device entry can resurrect with a `productVersion` that has never existed in any PMS build the customer ran. Where is `4.18.1` coming from?

2. Document, or fix, the device-delete → SharedServer wipe behavior.

3. Provide a supported way to clear the device cache without a destructive re-claim cycle.

## Has anyone else seen `productVersion=4.18.1`?

If you’re hitting “Your home screen is empty” on a server you know is healthy, run this:

```bash

TOKEN=$(grep -oP ‘PlexOnlineToken=“\K[^”]+’ \

“/path/to/Preferences.xml”)

LOCAL_CID=$(curl -s localhost:32400/identity \

| grep -oP ‘machineIdentifier=“\K[^”]+’)

curl -s “RESOURCES_XML_URL_HERE?X-Plex-Token=$TOKEN” \

| python3 -c 'import sys,xml.etree.ElementTree as ET

cid=sys.argv[1]

for d in ET.fromstring(sys.stdin.read()).findall(“Device”):

if d.get(“clientIdentifier”)==cid:

print(d.get(“provides”),d.get(“productVersion”),d.get(“name”));break’ “$LOCAL_CID”

```

(Replace `RESOURCES_XML_URL_HERE` with the standard `pms/resources.xml` URL on the Plex cloud — I can’t paste it here without tripping the new-user link cap.)

If you get back `sync 4.18.1 …` (or any other phantom version that doesn’t match what’s actually running), please reply — would help establish whether the ghost value is universal or per-account.

-–

**Attached** (zip): full diagnostic bundle — pre/post device entries, smoking-gun PMS log excerpt, recurrence timeline log (`fix_plex_provides.log` showing regressions on 2026-04-18, 2026-04-30, 2026-05-08), redacted Preferences.xml. All third-party data, tokens, and IPs redacted.

Happy to debug alongside engineering — full root access, debug logging on, can capture anything specific. Reply or DM.

plex-bug-report-bundle.zip (30.9 KB)

2

Please do not copy/paste the output from whatever AI tool you’re using. If you want to use AI to troubleshoot a problem, that’s on you. However, you will need to summarize your problem and whatever the AI spits out in your own words that isn’t a wall of poorly formatted text. DO NOT paste the AI’s summary. This is a human to human space.

Uninstall PMS. The default install location is /usr/lib/plexmediaserver/. After uninstalling double check this path to make sure everything has been removed. If there is anything remaining, report back what it is, then delete it. Install PMS again.

The default data directory is /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/ this location should not be impacted by the uninstall.

The issue is likely due to an old Resource file that has not been removed/replaced during your previous upgrades.

3

Thanks for taking the time.

On the uninstall/reinstall idea, my install isn’t a native package. It’s the official linuxserver Docker image, so there’s no /usr/lib/plexmediaserver/ on the host. The entire PMS binary tree lives inside the container, which is destroyed and recreated from a fresh image on every docker compose up -d. I’ve cycled versions a few times (1.42.x to 1.43.0 to 1.43.1 and back to 1.43.0), and each pull is a clean filesystem. There’s no path for an old Resource file to survive across versions the way it could on a bare-metal install.

The persistent data lives in a bind-mounted /config directory (Preferences.xml, the library DB, plug-ins). I’ve grep’d that entire tree and the running container filesystem for the phantom productVersion 4.18.1 and it appears in zero files. The value only shows up in what the Plex resources endpoint returns to clients.

The destroy-and-recreate cycle is essentially what the “nuclear” recovery I described does — device entry deleted on the Plex side, token stripped, container recreated from image, fresh claim. The new device entry comes back correct (right productVersion, provides=server) and then the phantom value reappears 8 to 12 days later on a device id that has never seen 4.18.1 locally. That’s what makes me think the cache is server-side rather than in any PMS file on my host.

If there’s a specific path inside the container that could survive image replacement (some cached value the container reads from /config that I might be missing), I’d genuinely like to check it. Happy to run any specific command and post the output.

4

Can you try the official Plex docker container instead or move/delete your preferences.xml and restart. If you have any users with shared access you would need to invite them again as a new preferences.xml will create a new server ID which is used for allowing access.

5

Update — tried the Preferences.xml wipe. Stopped PMS, moved the file aside, restarted, got a brand-new MachineIdentifier, re-claimed, re-invited the shares. Within five minutes the new device record was showing provides="sync" and productVersion="4.18.1" again — same phantom version as before, on a server identity that didn’t exist this morning.

PMS log this run: the publish PUT succeeded (HTTP 200, no error) and PMS logged “Last published value didn’t change, we’re done.” About two minutes later the device record on the backend had been rewritten with the corrupt fields, without PMS issuing anything else. So this isn’t a write rejection — PMS gets accepted, and then something asynchronous overwrites the record.

So the corruption isn’t keyed to the old MachineIdentifier. A fresh CID on the same account / same WAN IP gets the same phantom values written on top of a successful publish. And PMS doesn’t self-correct because its idempotency check still matches what it sent — its local view is correct, only the cloud-side record is wrong.

Timestamps from this run: 21:04:20 PMS PUT → 200, 21:05:42 PMS “value didn’t change”, 21:07:01 resources XML shows the corrupt record. Brand-new MachineIdentifier e0082d301f…, same account and same WAN IP as the original report. Happy to share the full debug log slice and the IP via DM if it helps you grep server-side.

6

Are you using the token from your Preferences.xml for any 3rd party application like Kometa or anything that uses python-plexapi?

7

Yes, Kometa. It runs daily at 04:00. I also have a small Python script using PlexAPI that runs weekly to pull library size stats. Both use the same server token.

8

There is your problem. Do not use your server token for anything else but the server. You need to generate unique tokens for each of these tools.

See https://github.com/Kometa-Team/Kometa/issues/2894

9

That’s the fix, thank you Atomatth!. Linked Kometa #2894 in particular nailed it.

Split the tokens via two PIN flows, each with its own X-Plex-Client-Identifier.

Within a couple of minutes Kometa’s own device record on plex.tv got rewritten to productVersion="4.18.1", provides="sync" (as expected, python-plexapi’s own headers landing on its own device, no longer the server’s). The active PMS device record stayed productVersion="1.43.0.10492-121068a07", provides="server" and has held there through a full Kometa restart and a python-plexapi systemAccounts() call from the stats script.