I can’t seem to find anything relating to this… I am trying to avoid --net=“host” and using docker-compose w/links between my media applications (which are all working fine)
If I browse to host:32400/web I get the UI just fine, and if I kick off gnome and test Plex locally things appear to work fine, as soon as I go to another device on the network (in spite of remote access showing fully green) I can get the /web UI but I get 406 not authorized for all API requests and basically get shutdown from accessing anything that way.
Worth noting that even locally host:32400/ responds with 401 Not Authorized (but works from inside the /web UI
I am stumped, and frustrated, just on day 3 of attempting to finalize migration from my old server to a newer setup and am out of solutions beyond giving up on containers or cheating and using the --net=“host” route
I am not trying to access the API via the URL, I am merely testing the behavior that worked before without any special considerations…
accessing the UI from /web should “just work” those API requests are being generated by code from the PMS backend itself
the base URL (no /web) has always dumped a brief XML output, which is why I was including that information
As it turns out, I was just informed by a family member that full outside access is working, so it is something relating directly to LAN access which is even more boggling to me now.
I have never accessed it from the IP Net and it worked previously…
I have Plex Pass Home group is that Home mode?
re: #2 - my server has dual NIC and one is setup for network egress only while the other is used for downloading and internal LAN traffic - PMS always bound to the egress IP and it was the only device assigned to that subnet (172.16.1.x) vs the rest of the internal subnet (192.168.1.x) of course with Docker that adds a 3rd layer (172.17.x.x) from the container mgmt side)
Still confused to learn that it works from outside the house but not inside…
So, latest update (just got home). If I login from plex.tv, I do not get any plex token added to the URL, headers or any requests made (checked via the network tab of the dev console). I tried from both the local machine (only way I can see my server) and from my laptop.
I can hit the resources URL from both devices though, it reports 2 connections for my local server (assuming one is itself and the other is my laptop). One IP is the Docker container IP (172.17.x.x local=1) and the other points to my public WAN IP… (local=0)
It does seem to point back to the Docker IP (but as long as I am outside the network it appears to work fine)… Oddly enough every other Docker service (sab, sonarr, couch) is also working fine… which is why I am truly puzzled by this.
Docker is grabbing a docker host IP 172.17.x.x network is 192.168.x.x (I removed the 172.16.1.x network for now)
As for PM, I think it might be a good idea at this point (particularly if nobody else is chomping at the bit to help that would make details get scattered).
The fact that it is asking for auth is expected, the fact that once I auth I cannot access fully the server from inside the house (from 192.168.1.x) is unexpected and I do not see how that can be ‘working as designed’ if I can then fully utilize the server from outside the network…
If anything, this would all make since if these situations were reversed and WAN was not working fully and LAN was working fully but as it sits it does not.
I do have each of my IP subnets on the auth not required list, but that did not anything work more or less better.
I disabled the 2nd nic last night, it had no effect on things. So all non localhost traffic is now guaranteed to arrive through the 192.168.x.x network (WAN and LAN).
I am beginning to think that I may need to add some tricky routing rule to rewrite 172.17.x.x requests on the LAN to the servers 192.168.1.42 IP but Docker supposedly shouldnt need that (but still pulling teeth on their support channel trying to get a definitive answer here)
