I would expect it to respond properly using the loopback address as well, but that’s just me.
No because thats not the preferred network interface is why it shouldnt work like that
Yes, when the preferred network interface is set. I don’t have it set and leave it as “Any”. So I’d assume loopback would respond and not provide a 401.
The server communicating with itself via the localhost address is completely normal; the same can be seen in my normally-functioning systems. It’s a form of inter-process communication and is very common when two processes need to pass data between one another (or one process to itself).
Unfortunately PMS doesn’t log the full request URI or headers. It leaves out the X-Plex-Token which, if logged, could pose a security/privacy issue if someone were to post logs which contained it.
To see what is being passed for the Plex token you’d need to grab a packet capture (via tcpdump or Wireshark) and examine the GET to 127.0.0.1:32400. You don’t have to wait for the 401 to occur, it is sufficient to simply restart PMS while capturing. There should be several such local loopback requests captured during startup. Something like the following should work:
tcpdump -i lo -Anvv dst host 127.0.0.1 and tcp port 32400 | grep X-Plex-Token
If you then append &X-Plex-Token='your-token' to the request URI to 127.0.0.1:32400 (in either of your examples) you should see 200 OK responses.
Testing with curl on one of my Linux servers (using your second example to 127.0.0.1:32400)…
No token response:
<html><head><title>Unauthorized</title></head><body><h1>401 Unauthorized</h1></body></html>
With token response:
<?xml version='1.0' encoding='utf-8'?>
<MediaContainer noHistory="0" replaceParent="0" size="2" identifier="com.plexapp.system">
<SearchResult lang="en" score="100" year="1970" guid="com.plexapp.agents.themoviedb://38765?lang=en" name="Chisum"/>
<SearchResult lang="en" score="80" year="1970" guid="com.plexapp.agents.themoviedb://327017?lang=en" name="John Wayne and Chisum"/>
</MediaContainer>
So:
- Internal requests to 127.0.0.1:32400 are completely normal on a functioning system.
- Such requests require the X-Plex-Token to be provided in the URI.
- The token isn’t logged.
Also, I think there may be some confusion regarding the function of the ‘Preferred Network Interface’ setting. It’s sole purpose is to specify which interface’s IP address(es), in a multi-homed system, are advertised to Plex’s servers for use by local clients.
Regardless of whether or not a specific interface is selected, Plex Media Server always listens on all interfaces (0.0.0.0:32400 or *:32400 or :::32400 depending on the tool used to show socket statuses).
1 Like
Unfortunately I can’t explain that fully. They didn’t specifically say they were using ‘curl’ to test, did they (I may have missed it and will need to re-read)? But if they were instead testing in a browser, the new tab could be using the session token from an open tab. Maybe. Similar to if you have an existing logged in tab open, you can open a second without re-authenticating.
[Edit]
Oops, I just noticed the message I was replying to is gone. This was intended to speculate on the cause of seeming incongruity between the localhost request failing and the host IP address succeeding, neither with a Plex token supplied.
I deleted the reply after posting because I realized I was probably being dense. Your write up was super solid. Thought I snagged it before you saw it. Dangit! 
1 Like
No worries, thanks!
1 Like
No it using localhost locally is not working. It only works if I use the internal IP. Doing the same curl locally IS NOT WORKING. Hence why I said something
Maybe the PMS has been configured to allow access on the LAN without auth?
1 Like
Using Postman and curl, using the localhost address with or without a token is NOT WORKING when done locally. Using the 192 address works fine every time with or without a token.
Now I get absolutely zero back when trying to match. I’ve been a Plex user from the beginning and now I’m going to have to find an alternative since Plex has decided they don’t care what happens to their server software.
This post has been up for a while now and no one is taking it seriously or bothered to give us any kind of update on if they’re even looking at it. Nothing about any of our setups changed, so obviously they broke something.
It feels lately Plex only cares about their own FAST server.
2 Likes
Yep, that would explain it. I tested with the localhost address range in ‘… without auth’ (which did not allow it to succeed sans token) but not my subnet. It was one of those ‘can’t see the forest for the trees’ moments, focusing more on the localhost “problem.” Thanks!
1 Like
I’ve performed some additional testing. In short, I was able to reproduce the issue you’re currently seeing (401 responses to localhost requests when using the TMDB agent). I was able to correct it by downgrading to PMS version 1.41.6.9685.
There was another thread recently regarding a regression in plug-in behavior (failure) on 1.41.7.9817. I can’t find the thread now, but I’m pretty sure it was found and will be corrected in the next beta. I believe these issues are related since the legacy agents are plug-ins.
It still doesn’t explain why the modern agents are working for some folks, but downgrading to the last “stable” release should allow the use of legacy agents at least.
Is this (downgrading to 1.41.6.9685) something you can confirm on your side? To see if it “fixes” the legacy agents?
[Edit]
Here’s the thread I referred to above:
Thats the version I had to downgrade to as well as stay on the legacy agents to get things to work. The new agents still fail for me on 1.41.6.9685
1 Like
Yep. Unfortunately (fortunately?) I can’t reproduce that particular issue and so can’t troubleshoot it. I was really interested in understanding the localhost/401 issue though. It’s unfortunate that these issues overlapped. It’s got to be frustrating.
Folks:
There is a HOTFIX coming for 1.41.7
- WD OS5 new installations (WD MyCloud devices)
- Conversion queue would stall after a single item (drops remainder of queue)
- Requests to legacy agents would fail - 3rd party Agents no longer scanning / matching
- Anon/unauthorized requests to server root
/were not being redirected to/web
8 Likes
THANK YOU @ChuckPa and the rest of the dev team!
1 Like
Downgrading worked. Thanks @ChuckPa !
1 Like
To what version did you downgrade to?
So an upgrade? You initially reported the issue on 1.41.6.9606. I’m confused.
