Recently, I moved my docker plex setup from one device to another. On the old device, I was using host networking, and in the new, I wanted to use bridge networking. The documentation surrounding bridge networking is not complete.
The root issue has to do with the IP address that’s sent to plex, and is used by other devices. The ADVERTISE_IP (https://hub.docker.com/r/plexinc/pms-docker/) isn’t strictly observed by all clients that attempt to connect to the Plex server. IOS seems fine (and worked before the below fixes), the Mac desktop client and android TV ones didn’t. Verbose debugging verified it was attempting to use the internal IP of the docker instance.
To solve this issue, the following steps need to be taken to resolve all client’s connection issues:
Click the gear icon on the upper right, and select “Network” under the settings.
Under the “Custom server access URLs”, enter the IP of your NAS, without quotes (e.g.: http://192.168.1.5:32400)
Under LAN Networks, add the span that covers your environment (e.g.: 192.168.1.0/255.255.255.0)
Click “Apply”
#4 is already documented in the plex instructions, but that whole section could be rewritten like the above. Without these steps, some clients will be able to access the server fine and others won’t.
If possible, please update the documentation to include more details for those that run Bridged. From a security and best practices standpoint, Docker images should be using Bridged networking whenever possible. Host based networking shouldn’t be encouraged and used only as a “last resort”
The ADVERTISE_IP variable sets the exact same preference that Custom server access URLs sets. So setting the pref via the latter method won’t solve the problem when the prior one doesn’t.
Bridged networking in docker has a myriad of problems. The first stems from the fact that the name itself is a foolish choice as it is NOT a bridged network but rather a NAT (whereas the “macvlan” is really a bridged network). Secondly, because it is a NAT, it doesn’t preform well with services that have any sort of discovery (of which Plex falls into this category). If the host itself is behind a NAT, then this will kill any sort of automatic NAT traversal because it is essentially a double-NAT. The list goes on and on. So recommending using either host or macvlan networking is appropriate as it avoids several of the design deficiencies of the “bridged” networking.
Unfortunately ADVERTISE_IP didn’t work on this end. I verified through the configuration file that it was not added. Nor, even with this blank, did that work on this end. I’ll chalk that up to user error til I do more testing (which time is at a premium, so hard to say when I get to it).
I agree with you that the naming itself is incorrect, but I do not agree with the fact that host networking is the “best” way. To be honest, I don’t trust docker containers much when it comes to what they’re executing. This is much like the lack of trust with general applications, and being able to control the explicit ports that come into it, what it opens up and can respond to, and so on, is of value from a security standpoint. But, then again, I also like to lock down my network fairly heavily where hosts don’t trust each other, and there’s some levels of blocking on outgoing, as well as incoming. So, from a security standpoint, NAT/bridged/whatever is still a good step in the right direction.
Sure it avoids configuration problems, but in my opinion, shouldn’t be encouraged.
