The pc I’m using to host Plex suffered a drive failure and lost all os data so I’m in the process on setting up Plex again. Previously, I ran into a problem where my network doesn’t use a RFC-1918 IP address range so I have to ssh tunnel from Windows 10 to the server. I followed the same process as last time except now I get “ERR_CONNECTION_REFUSED” when attempting to connect through “http://localhost:8888/web”. I’ve tried using a difference source port and gotten the same results. My only thoughts are a possible conflict since it’s the same machine and same IP as before or a conflict with sambashare since I install that before Plex this time. Any advice?
Did you check your firewall settings? Distros seem to be tightening up the default security each new release, Ubuntu may have those ports all closed as a default.
The Plex port is not 8888
We only use 8888 when performing SSH tunnel operations to a remote host.
Adding to my previous:
On Windows, This is the best example.
Local port is 8888, remote port is 32400
With this active,
open http://127.0.0.1:8888/web
this transits the tunnel and ends up on 32400 on the other end.
However, on an RFC-1918 compliant network, http://ip.addr.of.host:32400/web is all one should need.
Yeah, the ports are open. I tried every solution I came across that seemed relevant on this happening with both trying to setup Plex and ssh tunnels in general and nothing worked. In the end I gave up and redid my network so it uses a RFC-1918 IP range to configure it and it’s setup now. Even after setup I still can’t access it via ssh tunnel, but I’ve really come up with nothing as to why beyond something with the tunnel or some weird thing with Windows 10 especially since the Ubuntu distro is the same media I used to setup the first time with the same selections.
In response to Chuck, I’m aware the Plex port isn’t 8888 that’s just the source port I was using since it’s what’s suggested in the guide here https://support.plex.tv/articles/200288586-installation/ and what worked the first time. The steps in that guide are the same as what I followed which resulted in that error. As for the RFC-1918 compliance, my network previously wasn’t but as mentioned above I switched it be compliant in order to finish the setup as I found no way past this error.
When I’m doing Linux → Linux setup, and the networking isn’t compliant, SSH tunnel will work too. It’s a good way to rule out any networking issues (UDP / SSDP / etc)
In that method:
- ssh -L 8888:127.0.0.1:34200 ip.addr.of.host
- Sign in and leave that session idle
- In local browser, open http://127.0.0.1:8888/web
This works because:
a. ssh connects to the host first and authenticates
b. ssh then opens 8888 to accept connections
c. Connection requests on the local end of 8888 transit to the destination IP (127.0.0.1) port (32400)
Simple, huh? 
If the host isn’t being at all responsive,
- stop Plex
- Drill into /var/lib/plexmediaserver/Library/Application Support/Plex Media Server
- Delete Preferences.xml
- start plex
- Now attempt.
PMS will lock itself it if left unclaimed too long / too many unsuccessful authentication requests.
If this is happening, Grab the contents of the Logs directory in a tar.gz and attach them.
We can see what it’s not liking. It’s usually a DNS network routing issue.
I can’t fully speak for linux -> linux as the closest I come to that is a vm on Windows 10 running either ubuntu, kali, kde neon, or bodhi. But trying it from any one of those vms yields the same results.
When you refer to PMS locking itself I’m not sure if you mean specifically to ssh tunnel connections or to setup in general. If you the server would lock itself and you wouldn’t be able to perform setup through any connection, then it wouldn’t be a case of that. If it would specifically lock out ssh tunnels then this could be the case.
I would like to step back a bit and reflect first.
If you’re installing Plex in a Linux VM thinking you’ll gain performance, you won’t. The VM has overhead.
If you’re doing it to learn Linux, use the VM for only that purpose. There’s plenty of easier things to do in that VM which work super cool.
When you add Linux VM, on Windows (heterogeneous mix), not knowing your Linux skill level, I think you’re headed for more headaches and frustration than it’s worth.
My recommendation therefore would be
-
PMS on Windows:
a. No wasted CPU cycles or resources in the VM
b. Hardware transcoding is far better on Windows than Linux (microsoft driving that effort)
c. You know Windows. You have command of it. -
Keep the VM as your learning tool.
a. Learn all the command line skills needed
b. When it’s time, install Linux natively on a machine
c. Install Plex on that machine and observe what you really gain.
d. You’ll have the Linux skills to do it all at the command line (most important part)
e. NO HEADACHES
How would you like to proceed; Continue with the VM or install native?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
