It’s impossible to get Plex Media Player to treat a plex server as “local” when using bridge networking in docker. Basically, the URL that gets reported as local by Plex Media Server is the 172.19.xx.xx network:
The first (local=“1”) connection is automatically added by Plex. It’s inspecting the IP address of the container and treating that as the local subnet (this is wrong!)
The second is the one I added with the ADVERTISE_IP environment variable
The third is added by Plex due to enabling Remote Access (this has my correct WAN IP)
My plex media player has chosen #3 to use. I do not understand what criteria the clients use to decide which of these 3 endpoints should be used. Ideally, it would have chosen #2 which would have been treated as local, but also the local attribute is set incorrectly to "0", with no way to control it via container parameters.
Ultimately I think what needs to happen is we need a way to specify the IP Address plex should use as the local network it advertises. Right now it treats interfaces it listens on as local and advertises those, but we should have a way to override that. In a bridge-mode setting, the interfaces plex is listening should NOT be reported to clients. It should only report the interface we specify to it (which will be an interface on the host, not inside the container).
Uhm, there is a setting for this?! It can be found in PMS Settings -> Network -> LAN Networks.
My current values are “192.168.200.0/255.255.255.0,172.16.0.0/255.240.0.0”, which declares my LAN 192.168.200.0/24 as a valid LAN network and additionaly the range of possible Docker network IPs as well.
Though, I don’t realy remember whether there is a reason that the second declarion is added or not.
If you are currious how the process of determining the ip works, use plexweb and open the network tab in developer mode. You will see how plex web probes for the different urls - I assume the response with the shortest respones time is selected
Since your container ip is already registered as local, i would assume that you do not have a problem with dns rebind protection.
That’s not the same thing. I do not want the container’s subnet to be exposed outside of the container. Plex is advertising the wrong IP address. No one in the outside world should care about the docker network. More importantly, no one that Plex advertises to has visibility into that network so it’s a useless IP address for public exposure, even on my real LAN.
ADVERTISE_IP is nothing else than container env parameter to update the xml-node “customConnections” in Preferences.xml, which holds the value for the Custom Server Access URL’s.
This behavior of registering all local interfaces it is bound to is independ of whether you install plex on a bare metal system, a virtual system, a docker container with network=host or network=bridged.
The only way to make the container-ip disappear is to set the host’s interface as the “prefered interface”. It would prevent binding plex to the container-ip, thus resulting in not advertising the ip.
Btw. your problem IS A PURE CONSMETIC problem, as your docker host is the only system capable of accessing the container by it’s private ip. If you still want that fixed, make yourself aquinted on how to setup a MACVLAN network in docker allowing to use ip’s of your LAN.
Issue is not cosmetic. This is evident by the issues I described in my first post. And even if my issue has a workaround, it’s just that. The crazy complex level of domain expertise required to do what you suggest is unacceptable. Containers should be designed to be easy to use. And what I’m asking for is a simple matter. This has nothing to do with which interface Plex listens on, more to do with the interface advertised as a local connection which isn’t the same IP address. I haven’t seen a solution to this.
Would love to hear from one of the developers instead.
First make sure that https://docker_host:32400 is accessible to your clients.
Is https://docker_host:32400 in a private IP space (RFC 1918)? I checked a docker container in bridged mode and I clearly see the IP provided in ADVERTISE_IP has local="1" on that IP.
This is due to a fundamental design issue with docker containers using bridged networking. Such containers are intended to not know they are behind a docker NAT nor are they intended to know what the outside IP address is that can be used to reach their ports. That’s why the ADVERTISE_IP is necessary for docker containers in bridged mode and very rarely used anywhere else.
I would suggest that you look into whether host or macvlan networking is applicable in your circumstances. Docker’s bridged networking is not really designed for many of Plex’s needs.
Thanks for the response gbooker02. Why is my docker_host not being treated as local? I do bind port 32400 in the container to the host, so it’s definitely accessible. And my plex media player can access the server via LAN, but it’s being treated as remote due to the local=0.
I would disagree that the docker container bridge mode is a design issue for plex. I run plenty of services via docker containers on a bridged network and it works fine. As long as you map the respective ports to the host, and you allow sufficient flexible configuration of the server so that instead of attempting to deduce the correct interfaces to report to clients you allow it to be explicitly configured, that is enough. I would argue this is a solvable issue irrespective of docker. Basically, don’t automatically assume that listening interfaces are advertised interfaces. Specifically, if ADVERTISE_IP is provided, as in my case, the bridge network IP would be overridden by that IP and not advertised at all. That is not happening today.
Design disagreements aside, that’s not really the issue though. The issue is that I don’t know why local=0 is not local=1 for what I provide to ADVERTISE_IP. How do I force it to be treated as local? This is the requirement to make bridge networking work, since whatever Plex Server is doing programmatically to determine if an IP is local or not isn’t flexible enough for these kinds of network setups.
Am I missing some important configuration here? I’ve specified ADVERTISE_IP here, which uses the LAN hostname of the host machine. I do not want Plex to publicly advertise anything about the docker bridge subnet, which I thought was one of the outcomes of using these environment variables, that it would override detected interfaces.
You can write as much as you want disagreeing with one who knows the details all along the way but I can’t answer your primary question if you don’t answer all of mine.
Is https://docker_host:32400 in a private IP space (RFC 1918)?
Additionally, if it isn’t an IP address, what happens if you try the IP address?
You can write as much as you want disagreeing with one who knows the details
That response feels a bit arrogant. I never claimed to be more knowledgeable, and I can only speak in terms of symptoms. As a customer I am offering feedback. I find it very offensive that someone with the label of “Plex Employee” responds to best-intentions feedback this way. Maybe I’m misunderstanding your tone but it sounds very rude at face value.
Is https://docker_host:32400 in a private IP space (RFC 1918)?
I didn’t explicitly address this question, I guess. I apologize for that. The host IP of my machine, which is represented by docker_host hostname, is part of my LAN network. So it translates to an IP address like 192.168.1.50. So from the perspective of the client on my LAN, which might have IP 192.168.1.51, this should be local=1, but it’s showing up as local=0 when I look at the XML (per my first post).
Hopefully this helps. If you meant something else by “private IP”, then I’ll have to ask you what you mean. Reading the RFC is a non-starter for me.
what happens if you try the IP address?
No difference, since I’ve tried this use case as well (setting advertise IP to https://192.168.1.50:32400)
Your diagram there nearly perfectly explains my set up. While your response seems to have been within the context of accessing Plex via ADVERTISE_IP from WAN, mine is LAN. So ignoring the port forwarding issues (which shouldn’t be required for LAN access I would think), you did mention something relevant here:
The ADVERTISE_IP only instructs the server inside the container to add 192.168.1.6:32400 to the list of addresses where it is reachable when it sends that list to plex.tv. So clients on the 192.168.1.x network will see that entry (among the others normally there) and attempt to contact it there (which should succeed).
Could the issue be that, nothing is local if it’s pulled from plex.tv? Even if some of those advertised IPs are on the same private network? Again this all comes back to the local attribute, which the linked thread doesn’t seem to mention. I haven’t been able to find out much about how addresses are determined to be local or not.
While using ADVERTISE_IP http://docker_host:32400 is perfectly fine for an http conncetion, it is wrong to use https://docker_host:32400 for a https connection!
A https certficate is issued for at least a Common Name (CN) and zero or more Subject Alternative Name (SAN), which for https certificates aretypically domainnames, for instance *.{varnum}.plex.direct for the certificats generated by Plex. Due to the desgin how certificate verification works, the domain in your url MUST either match the CN or the SAN. Everything else (like using any hostname or ip) results in a failed certificate verification.
What you do is basicly forcing plex to register an URL at plex.tv which when tried to be accessed returns an invalid certificate. Why should a bad connection url be considered as local?!
I have tried HTTP too, since my settings say “preferred” instead of “force”, so it didn’t make a difference. Also I’d really love to learn about why the server advertises the IP as local=0 instead of local=1, why it matters, and how this affects the quality settings chosen by the client. As far as I understand, if it’s local=0, it will choose the “internet settings” for quality, instead of “local network” settings, which is not what I want to happen.
Just for the sake of completing the tests:
Regardless whether the ADVERTISED_IP points to https or http, the value for local is always 1.
Obviously the pub-sub service does not care if a https “Custom Server Access URL” has a valid certificate or not. Which now where I think about it makes sense since it rather uses the ip for “connectivity test” and not the domain name.
For each test a new Plex instance using a new PLEX_CLAIM token was created and the Secure Connection setting was set to “Required”, then the remote connection was disable/re-enabled and afterwards the resources.xml was checked.
You should create a new instance and check whether the local recognization is working for the new instance (I used no volume mappings for this) . If it does work as expect, you know there is a problem with your existing config.
@kopfpilot You tested with an IP address, but do you get the same results if you use a local domain name for the LAN IP of your plex server? I tried that as well as setting allowed networks and didn’t get local=1.
