Long term Plex user, from the very beginning, used to use it across Windows, and then later Synology NAS, stopped using it because there was a change which broke it for me, because it’s used on a Public IP range! Somewhere there is a post, to this effect.
But recently added into to a new Synology NAS and it works - no idea why, nothing has changed still a Public IP, when I mean it works, I can use it internally on my TV and PCs to watch films etc
The only issue, is Synology CPU is pants for transcoding, and is not fast, so I thought I would run Plex in Docker on UnRAID.
It’s running it’s installed, but I cannot login and configure, and I wonder if this is the same issue as Public LAN again, when I cannect to the Public IP http://xxx.xxx.xxx.xxx:32400/web/index.html
It just not show the server, just Plex Web, although if I go to Authrorised Devices I can see Plex Media server on UnRAID etc listed. UnRAID box has an Intel processor, so hoping it will transcode or perform better.
Any ideas to get this working ? or am I suffering the public IP issue, but not sure why it works on Synology NAS!
Server Version#:1.42.2.10156, Docker Container, Linux 6.12.54-Unraid
Player Version#:4.147.1
<If providing server logs please do NOT turn on verbose logging, only debug logging should be enabled>
It’s a security mitigation. The server must be claimed initially via a private IP range.
It would seriously be in your best interest for compatibility (not just with Plex) to renumber your network correctly. The subnet you’re using is from the 141.245.0.0/16 block, which is a public “owned” by British Aerospace.
No, it’s not really. You’re running in a completely unsupported configuration. When things fail or work in an unsupported environment, you don’t have the luxury of pointing and saying “look, here’s my proof it should work (or fail).” The test is getting into a supported configuration and testing there.
I’m not sure why you’re hanging onto your IP address scheme, but whatever the reason is, it’s not good enough. Just fix it.
I apologize if I sound inflexible. But you should always start from a configuration you expect to work and then move out from there.
This means that the script was able to communicate with Plex’s servers and obtain a claim token.
You’re using Docker, so you have the option of obtaining and providing a claim token at container creation time (https://plex.tv/claim). That can be added to your compose file or your docker run or however Synology or Unraid do it to claim the server right from the start.
But you’re completely ignoring the larger issue. Your IP numbering.
I mentioned previously. It’s a security mitigation. It’s primarily aimed at folks who actually run their servers on the public Internet (cloud hosted servers). There’s a chance during the period between these servers are stood up to when they are claimed, that some who is not the server owner could attempt to claim it.
In order to mitigate that, Plex changed the claim requirements such that the Plex Media Server and the client from which the claim originates must be on the same local network. They document it in their installation guide (which I highly recommend you peruse).
Naturally, if you’ve numbered your local area network with a publicly routable IP address, shenanigans. You have to resort to one of the supported methods for claiming such servers:
Pre-obtained claim tokens, in the case of Docker; or,
The claim script provided above; or,
Claiming via an SSH proxy tunnel from your local machine.
Again, why stick to the unsupported IP numbering? There are very good reasons for keeping publicly routable and private IP addresses separate, security being the primary reason. Random, unexpected issues with local software being the second.
Notice I stated local network. Again, referencing the RFC (1918) linked above, local (private) IP ranges must be in the following:
192.168.0.0/16
172.16.0.0/12
10.0.0.0/8
Your comment disappeared, so I can’t quote the “Absolute Foo!” part of it. But failing to adhere to the guidance above will cause problems whenever you need to host servers which need to be accessed from outside your network. Your “private” network address will collide with real public ones, causing problems.
(And I don’t use ChatGPT my friend. I use decades of experience.)
For pity’s sake, why is this even an argument anymore? Don’t use publicly routable IP ranges for your private LAN.
