@ChuckPa Anything I can do to make this happen? I can request whatever you need to Feral.
If they have a PoC here, that would be helpful and a good starting point.
A PoC of what exactly?
Someone who can detail and discuss:
- How user accounts are isolated
- How are network adapters presented to the installed host OS.
- How should they be visible to the guest applications on those hosts.
The end goal being a procedure by which PMS can be installed and properly run.
If such a procedure can be created, I will post it.
In my home setup I have an Nginx in front of my server, but it’s not rewriting any request headers or anything. That’s what I can share from my side at least.
I will ask feral for more info too.
- Plex runs in a separate network namespace. (Just “ip netns add user.$userID”).
- Inside the network namespace is the loopback and a single Ethernet interface with your internal (to the server) point-to-point IP.
Here is the how the network ns looks:
[~] ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if74: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 100
link/ether d6:aa:fb:e2:f5:ef brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.13.53/31 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::d4aa:fbff:fee2:f5ef/64 scope link
valid_lft forever preferred_lft forever
Here is iptables:
[~] iptables -t nat -L -vn
Chain PREROUTING (policy ACCEPT 100M packets, 5555M bytes)
pkts bytes target prot opt in out source destinationChain INPUT (policy ACCEPT 100M packets, 5537M bytes)
pkts bytes target prot opt in out source destination
316K 16M SNAT tcp – * * 185.21.216.188 0.0.0.0/0 tcp dpt:32400 to:10.0.13.52Chain OUTPUT (policy ACCEPT 136M packets, 9668M bytes)
pkts bytes target prot opt in out source destinationChain POSTROUTING (policy ACCEPT 136M packets, 9668M bytes)
pkts bytes target prot opt in out source destination
To quote:
The box doesn’t namespace IPC nor processes (although hidepid=2 is enabled).
I would agree that it looks like a firewall interfering with the requests, there is no proxy or middleman for outgoing requests on our side. I have checked iptables on the box and the rules are standard: fail2ban, upnp, and DNAT port forwarding for incoming requests; none of these would interfere with outgoing requests from Plex.
This does look like a blanket IP ban that users sometimes report with other services. Perhaps a load balancer or an nginx module that makes an (hopefully erroneous) assessment on the IP.
Extra question, can you give me the full URL that seems to be having this 403 issue and the header that’s most probably failing? I can’t see any of those in the logs.
Sorry for delay. I got overloaded.
Please refine this:
Plex runs in a separate network namespace. (Just “ip netns add user.$userID”).
You’re using a Linux Namespace ? PMS isn’t coded to support it.
Like I mentioned earlier, other user processes are not visible for your own space, so it’s not that, and I would greatly appreciate if you stop being dismissive and we move on. Lets please focus on the request problem which is the real error here and what logs show.
Can you also please answer my question too?
Should you review everything I previously stated:
- All PMS processes on the main host were visible. – This has been changed / improved. Good
- Linux Namespaces are used. Plex Media Server is not coded to use Linux Namespaces. Use of namespaces is not a common or mainstream consumer configuration scenario.
I am not being dismissive.
These are the facts.
Still not addressing the issue about the request, can we please?
I have filed a feature request.
Possible outcomes:
- The feature request is approved (1 in 1000 chance – being candid) with no idea when it will actually be implemented for all PMS platforms and clients.
- The feature request is denied on ground there is no demand for it. (Most likely).
In any event, maintaining the current configuration, based on namespaces, will continue to result in a non-operational PMS system.
As has always been recommended: Selection of a new provider/networking solution is the quickest and best remedy. There are many well-established providers currently hosting PMS customers without issue.
Thanks for that. I guess that sort of addresses the namespace stuff.
You’re still not addressing my issue with the request and the 403. Can you answer my question please and help me solve that?
I just wanna be as candid and say that namespaces have nothing to do with my original problem and since I mentioned it you sort of dismissed all of the other things and focused solely on that. This is partly the reason I didn’t want to mention Feral, cause in the past and now as well, I’ve seen that the moment somebody says “Feral” you just dismiss the issue saying “PMS doesnt support namespaces” and disregard some other possible problem.
I understand your point about namespaces and how PMS shuts down other “duplicated” processes if it finds any, but we already discarded that idea since Feral already hid user processes from one another and, not that I wanna be a smartass here, but based on my knowledge and experience in systems, networking and development, I’m still pretty sure my bug is related to a header in a request and not the process shutting down because there’s multiple instances of it running in the same system. Meaning namespaces have nothing to do here.
So PLEASE, can you help me debug that specific issue and treat it with the same interest as you would if the word “Feral” wasn’t part of this?
Thanks
I also having some similar issues after updating my plex instance, and I also happen to be on feral. To be clear I did not have these issues before updating. And running ps -ef | grep -i plex yields only my user’s processes.
Here’s what I’ve gathered.
My updated instance at:
https://<server>.feralhosting.com:<port>/web/index.html
is accessible. And is showing duplicate plex library names, of which I’m unable to delete the dead instance. I’ve tried multiple times and even rebooting my plex instance to no avail.
My updated instance is NOT accessible via:
https://app.plex.tv
and displays the error message
The server “<my plex library name>” is unavailable
Plex will automatically try to reconnect to this server
However, this shows my updated plex instance as connectable:
http://app.plex.tv/desktop?secure=0
But I’m still unable to delete my dead (duplicate) plex instance no matter how I try.
Also my iOS Plex app is connecting just fine (maybe connecting insecurely?), and it’s also showing my dead instance.
** I’ve tried multiple Network settings “Secure connections: Disabled, Preferred, and Required” as well as attempted to change the setting “Enable server support for IPv6” to true and false.
Currently my instance network settings are:
Enable server support for IPv6: True
Secure Connections: Preferred
And I’m running Plex Version 1.16.6.1592-b9d49bdb7
Here are the errors I’m getting in my debug log.
Sep 13, 2019 20:37:10.078 [0x7fd0644d1700] Debug — EventSource: Resolving 82.94.168.25 port 443
Sep 13, 2019 20:37:10.079 [0x7fd0644d1700] Debug — EventSource: Resolved 82.94.168.25 to 82.94.168.25
Sep 13, 2019 20:37:10.146 [0x7fd0644d1700] Debug — EventSource: Connected in 55 ms.
Sep 13, 2019 20:37:10.146 [0x7fd0644d1700] Debug — EventSource: Wrote data, reading reply.
Sep 13, 2019 20:37:10.263 [0x7fd0644d1700] Debug — EventSource: Read HTTP reply header.
Sep 13, 2019 20:37:10.263 [0x7fd0644d1700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 13 Sep 2019 20:37:10 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
(0 - Success).
Sep 13, 2019 20:37:10.275 [0x7fd0644d1700] Debug — EventSource: Stopping.
Sep 13, 2019 20:37:10.275 [0x7fd0644d1700] Debug — PubsubServerManager: Switching to next host in region: 82.94.168.22
Sep 13, 2019 20:37:10.276 [0x7fd0644d1700] Debug — EventSource: Stopping.
Sep 13, 2019 20:37:10.276 [0x7fd0644d1700] Debug — EventSource: Resolving 82.94.168.22 port 443
Sep 13, 2019 20:37:10.276 [0x7fd0644d1700] Debug — EventSource: Resolved 82.94.168.22 to 82.94.168.22
Sep 13, 2019 20:37:10.285 [0x7fd0644d1700] Debug — EventSource: Connected in 7 ms.
Sep 13, 2019 20:37:10.286 [0x7fd0644d1700] Debug — EventSource: Wrote data, reading reply.
Sep 13, 2019 20:37:10.373 [0x7fd0644d1700] Debug — EventSource: Read HTTP reply header.
Sep 13, 2019 20:37:10.373 [0x7fd0644d1700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 13 Sep 2019 20:37:10 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
(0 - Success).
Sep 13, 2019 20:37:10.373 [0x7fd0644d1700] Error — EventSource: Retrying in 15 seconds.
Sep 13, 2019 20:37:25.373 [0x7fd0647c0700] Debug — EventSource: Resolving 82.94.168.22 port 443
Sep 13, 2019 20:37:25.374 [0x7fd0647c0700] Debug — EventSource: Resolved 82.94.168.22 to 82.94.168.22
Sep 13, 2019 20:37:25.382 [0x7fd0644d1700] Debug — EventSource: Connected in 7 ms.
Sep 13, 2019 20:37:25.383 [0x7fd0644d1700] Debug — EventSource: Wrote data, reading reply.
Sep 13, 2019 20:37:25.483 [0x7fd0644d1700] Debug — EventSource: Read HTTP reply header.
Sep 13, 2019 20:37:25.483 [0x7fd0644d1700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 13 Sep 2019 20:37:25 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
(0 - Success).
Sep 13, 2019 20:37:25.492 [0x7fd0644d1700] Debug — EventSource: Stopping.
Sep 13, 2019 20:37:25.492 [0x7fd0644d1700] Debug — PubsubServerManager: Switching to next host in region: 82.94.168.25
Sep 13, 2019 20:37:25.493 [0x7fd0644d1700] Debug — EventSource: Stopping.
Sep 13, 2019 20:37:25.493 [0x7fd0644d1700] Debug — EventSource: Resolving 82.94.168.25 port 443
Sep 13, 2019 20:37:25.493 [0x7fd0647c0700] Debug — EventSource: Resolved 82.94.168.25 to 82.94.168.25
Sep 13, 2019 20:37:25.502 [0x7fd0647c0700] Debug — EventSource: Connected in 6 ms.
Sep 13, 2019 20:37:25.502 [0x7fd0647c0700] Debug — EventSource: Wrote data, reading reply.
Sep 13, 2019 20:37:25.607 [0x7fd0647c0700] Debug — EventSource: Read HTTP reply header.
Sep 13, 2019 20:37:25.607 [0x7fd0647c0700] Debug — EventSource: Failure in ParseHeader: HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 13 Sep 2019 20:37:25 GMT
Content-Type: text/html
Content-Length: 162
Connection: close
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
(0 - Success).
I will repeat my offer one final time. This is all we can do. It’s no different than if someone was trying to host PMS on a new NAS which wasn’t already supported.
I am available and open to a dialog with a representative from Feral Hosting to determine how, if possible, to configure Plex Media Server so it operates in Feral’s environment.
Thanks @ChuckPa for your offer. I’ve already opened a ticket with Feral mentioning the issue and linking directly to this thread. @feralhosting please take @ChuckPa up on their offer. There are plenty of us in this forum having the same issue as of late.
I’ve got a response from feral support and in my reply suggested they get in touch with you @ChuckPa.
Hello,
Plex is returning a 403 error under some certain circumstance - it remains unclear what those circumstances are (and is even more unclear why running Plex in separate user namespaces with no interaction with each other could be responsible).
Has something Plex’s end meant that subsequent tokens/authentication attempts from different Plex servers (but from the same IP) are now rejected?
This issue has been escalated and we will follow-up with you as soon as we have an update.
Regards,
<REDACTED>
In response to their question,
I can start multiple VMs on my QNAP NAS and sign them into Plex.tv. Each comes from the same WAN IP address without difficulty.
Adapter configuration is very simple. Each has a, non-namespaced, different LAN IP (aka. adapter bridge mode).
This is and always has been how I do my development.
Hi,
I have been following this thread and I have the same issue regarding duplicate PMS showing on my account and 403 error.
Did you come up with a solution or did the thread just “die”? 
//glomme
The thread is largely dead because attempts to work with Feral have gone unanswered.
As has been previously stated, until such time as there is an effort / interest, there is nothing which we can do and Feral remains the one known provider PMS will not work with.
It might be in everyone’s best interest if is closed to provide some form of closure.
In the future, should there be renewed interest, we can link here and begin again.
