Problems connecting to own library, docker-compose

Server Version#:4.147.1

Since yesterday, my long running Plex-Server (docker-compose setup) lost access to my media. It claims that I have no server and I should get one. It happened after I restarted the docker service in order to pull latest image.

Unfortunately I also changed some network configs during the last days and thus I’m now unsure, what may cause the problem.

I read, that there have been some problems with latest version and I already tried a lot of those mentioned solutions (e.g. change PUIDPLEX_UID, used GitHub - ChuckPa/UserCredentialReset: User Credential Reset utility for Plex to reclaim server, removed CertificateUUID and CertificateVersion from Preferences.xml because I had an error message about Cert, etc.)

I’m quite confident, that my Network configs should not have affected my docker setup and it seems as if I can connect with a different user to my library, but my normal user just gets this:

And I see an error within logs that might tell me, that my network is broken after all (i.e. docker service can’t connect via host network to the outer world):

Aug 14, 2025 22:12:51.029 [136532367387448] DEBUG - [EventSourceClient/pubsub/139.162.170.32:443] Failure: 125 - Operation canceled.
Aug 14, 2025 22:12:51.029 [136532367387448] DEBUG - [EventSourceClient/pubsub/139.162.170.32:443/PubsubServerManager/getNextWorkingHost/fra] 0 total hosts available in region, starting tests
Aug 14, 2025 22:12:51.029 [136532367387448] DEBUG - [EventSourceClient/pubsub/139.162.170.32:443/PubsubServerManager/getNextWorkingHost/fra] No working hosts in region, refreshing full host list
Aug 14, 2025 22:12:55.509 [136532338686776] DEBUG - Request: [[::1]:37938 (Loopback)] GET /identity (2 live) #94c Signed-in
Aug 14, 2025 22:12:55.509 [136532365278008] DEBUG - Completed: [[::1]:37938] 200 GET /identity (2 live) #94c 0ms 418 bytes (pipelined: 1)
Aug 14, 2025 22:12:56.029 [136532367387448] WARN - [EventSourceClient/pubsub/139.162.170.32:443/PubsubServerManager/getNextWorkingHost/fra/process] Connection to 139.162.170.32 failed: Operation timed out.
Aug 14, 2025 22:12:56.029 [136532367387448] ERROR - [EventSourceClient/pubsub/139.162.170.32:443] Retrying in 600 seconds.

Further info:

docker network ls

gives following output:

NETWORK ID     NAME           DRIVER    SCOPE
7fde102c263f   bridge         bridge    local
8077378294ec   host           host      local
0d6365aaad3a   none           null      local
0e5426dd3771   plex_default   bridge    local

My docker-compose.yml

looks like this:

version: '3'
services:
  plex:
    container_name: plex
    image: plexinc/pms-docker:latest
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
      - PLEX_UID=1000
      - PLEX_GID=1000
      - ADVERTISE_IP=http://192.168.66.66:32400/
    ports:
      - 32400:32400/tcp
      - 3005:3005/tcp
      - 8324:8324/tcp
      - 32469:32469/tcp
      - 11900:1900/udp
      - 32410:32410/udp
      - 32412:32412/udp
      - 32413:32413/udp
      - 32414:32414/udp

I think I am missing something here. Anyone able to help? (if more information is needed, please tell me, I’ll try to provide)

Sounds like a network issue, without the server logs its going to be hard to diagnose.,

That’s what I think as well. I thought, the relevant part of the log was enough. But here we go, a server.log with more info

server.log (463.2 KB)

Log excerpts are never the right logs.

Looking at your logs I am not seeing anything obvious except perhaps that your LAN and docker IP ranges are on different subnets.

Since I only have partial censored logs its hard to see anything definitively

What else is missing? It’s the log from plex start until about 90 minutes later, so enough to see any failures due to network or other problems.

Actually, the log-entries repeat themselves on each retry.

And what censored parts are making analysis difficult? Most of those parts are censored by plex on logging itself. I only censored username/mail-address which should not help in any way.

As I already said in my first post, it’s quite obvious, that there is a network problem, plex server doesn’t seem to get outside. I’m just wondering why. I use the default network, that the container is creating itself and which is a bridged one.

Should be ok, I presume. The private IP of the plex docker container doesn’t matter as far as I know, as it is used internally only. The ports are all bound to host system and plex advertises itself with the IP address of the host with the port I bound it to.

That’s why I have no problems to connect to the UI on http://192.168.66.66:32400.

However, plex server tries to connect to some services and fails to do so (as far as I can tell).

As you said, I also think that this looks strange:

Aug 14, 2025 22:38:10.908 [123817468422800] DEBUG - Network change.
Aug 14, 2025 22:38:10.908 [123817468422800] DEBUG - NetworkInterface: Notified of network changed (force=0)
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG - Detected primary interface: 172.17.0.3
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG - Network interfaces:
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG -  * 1 lo (127.0.0.1) (00-00-00-00-00-00) (loopback: 1)
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG -  * 283 eth0 (172.17.0.3) (02-42-AC-11-00-03) (loopback: 0)
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG -  * 1 lo (::1) (00-00-00-00-00-00) (loopback: 1)
Aug 14, 2025 22:38:10.909 [123817468422800] DEBUG - Creating NetworkServices singleton.
Aug 14, 2025 22:38:10.910 [123817468422800] DEBUG - NetworkServices: Initializing...

But I have no glue what it is expected to look like. And if that really is the root cause.

I probably messed up networking.

Does anybody have a link to documentation plex wants networking to be configured in docker-compose environment?

Thx in advance.

Couple of points:
My comment about censored logs is often people will remove a fair amount of info in the logs without knowing what they are removing. Any time I run into undisclosed log censoring I stop. A) I know the logs have been tampered with in an unknown way 2) often items IPs are either removed or changed 3) Those changes affect debugging which means if not caught a lot of time can be wasted looking at information that was changed and not knowing it.

Often times going back thru multiple startup sequences or older log files can show information that may not have been obvious in the first log file. Or what data we are looking for may not be in the specific log file you posted. Which is why there is an article about how to get the zip of your logs and upload it at the Plex Server logs article

Per the Plex Docker readme I would recommend using the host networking, Plex DOES check the IP address it has vs the IP address of the person trying to claim it. Both devices must be on RFC 1918 complaint subnets, and they must be on the same subnet.

At this time I would say that the docker container is using bride mode, and using 172.xxx subnetting while your local router is using 192.xxx subneting

Fair enough. But I can ensure you, that I knew what I was doing and did not remove any relevant information.

Unfortunately I was not able to follow those instructions, because there was no such option in Web-UI. That’s why I tried to get the data from the host itself. Unfortunately the log-rotation settings seem to rotate the logs on each server restart and as I already restarted the server multiple times before I asked for help here, any logs from previous successful startups have already been overwritten.

That’s strange, because trying to start it using host networking, I’ll get the error message:

ERROR: for plex  "host" network_mode is incompatible with port_bindings

And I’m pretty sure, that it worked with bridged mode before. So, did something change here?

Yeah, that’s how bridged setups work AFAIK. I still think, that I have some kind of routing/forwarding problem, because my docker container is not able to communicate with the outside. I can’t figure out, what caused that though.

Will try some different settings and see, if I can narrow it down.

Thanks for your help anyway. Much appreciated.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.