Server Version#:1.13.5.291
Player Version#:Web
QNAP - TVS-471 Version - 4.3.5.0760Plex Media Server.1.log (463.7 KB)
Did you initialize the server and sign it into your Plex account?
If not, you must first complete the setup wizard:
http://ip.addr.of.qnap:32400/web (with your browser signed OUT of your account)
Yes - I even downloaded firefox to ensure no browser settings were getting in the way.
- stop PMS
- ssh into it
- Go into “/share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Library/Plex Media Server”
- Remove Preferences.xml
- Start PMS.
- Open the address by IP address.
It’s now fully in ‘reset’ mode.
If you previously had created libary sections, skip creating any new ones. They will be waiting for you when you arrive at the dashboard again
Note: IF the IP address of your NAS isn’t RFC-1918 compliant, (192.168.x.x, 10.x.x.x, or 172.16.x.x -> 172.31.x.x) it will never respond until you change the LAN subnet IP range
I have tried that several times. As well as stopping, uninstalling, rebooting and installing. The IP is RFC-1918 (Using a 192.168.4.2 ip address).
What’s the IP of your computer and what’s the IP of the NAS? I presume both are on the same subnet?
Also, would you please make a tar.gz of the Logs directory and attach it so I can see the entire sequence of what PMS is doing?
I am access via VPN currently (192.168.100.2. This was working before a Plex upgrade as well as a Qnap upgrade, so my firewall rules for VPN traffic should not be the issue). I can attempt to access from the same subnet as the NAS when I get home. logs.tar.gz (76.3 KB)
IP of NAS is 192.168.4.2
VPN is killing you… You “Referrer IP” is forwarded through the VPN. PMS detects this. You aren’t “SAME LAN” to it. In truth, you’re not on the same subnet as the LAN. PMS security won’t let you claim it…
SSH tunnel to it and you will be fine.
ssh -l admin -L 8888:127.0.0.1:32400 ip.addr.of.qnap
Now open http://127.0.0.1:8888/web in your browser.
You will run through the tunnel, which is in the VPN but will come out the other end at the loopback adapter (127.0.0.1) without any fingerprints of your real address…
So PMS is no longer routable across network segments (storage vlan 104 to wifi vlan 103 or vpn vlan 100)? I have had routable multicast protocol (mDNS via chromecast) issues in the past that I have over come. I still think there is something with the version upgrade of the Qnap/Plex that is not getting along. I have not had a chance to place a device on my storage vlan to test access but it just seems odd that after an upgrade this all stopped working.
Also, I attempted the ssh session while on my WiFi vlan and received the following error:
[~] # channel 3: open failed: administratively prohibited: open failed
channel 3: open failed: administratively prohibited: open failed
channel 4: open failed: administratively prohibited: open failed
channel 3: open failed: administratively prohibited: open failed
PMS is routable across VPN, just as it always has been, if you setup the iptables / routing correctly.
It is not for the weak of heart.
Those channel errors tell me your vlan is also making your life miserable.
You should have STDIN, STDOUT, and STDERR (channels 1,2, and 3). If there is a tunnel, that becomes 4)
I have two LAN segments, each tagged.
Wired is VLAN 1 (the default when no tagging is used).
The main WiFi is on VLAN 1 also
Guest WiFi is VLAN 1003 and only sees the internet.
Too much management is as bad as, if not worse than, not enough.
I really appreciate the help. I am using a pfsense router/firewall and am about to flatten the entire thing to make things less complicated. Nothing in my routing tables or rules have changed since the upgrade - that is what is driving me crazy.
I use the SG-2220 Netgate box. Makes my life EASY 
Yes, flatten it like a pancake.
I added VLAN 1003 tagging to the port the WiFi AP is plugged into and to the port from the pfSense and the tag in pfSense.
Thats all it took.
The resultant behavior:
- Main SSID falls out on VLAN 1
- Guest SSID falls out on VLAN 1003 (thanks Apple)
- Wired is VLAN 1 (default for wired)
I am more confused now - previously you stated “You “Referrer IP” is forwarded through the VPN. PMS detects this. You aren’t “SAME LAN” to it. In truth, you’re not on the same subnet as the LAN. PMS security won’t let you claim it” - I dont know if I am reading that incorrectly but, to me, it seems that if you are not on the same subnet as the PMS you will not be “trusted” because of security. I am still working on flattening. This is a bigger project than I set out for in one night lol.
Let me try again. I probably made it sound weird. Sorry
When using a VPN, your real IP (before you transit the VPN) is what gets forwarded.
If you’re at remote: 111.222.111.121, and run through the VPN to your LAN, PMS will see the IP it has on the LAN (VPN exit point) as well as the 111.222.111.121. Both IP’s are in there.
That’s why we have to use the SSH tunnel
When we use the SSH tunnel,
it goes through the tunnel and exits in the PMS server at 127.0.0.1 .
This is why we say ssh -L 8888:127.0.0.1:32400 ip.addr.of.host
We’re also telling it to accept local port 8888 and send all traffic to the host’s loopback 127.0.0.1, port 32400. There are no intermediate IPs and hence no referring IP… All “remote identification” of where you really are isn’t carried forward through the tunnel.
So after some time I have finally flattened my network. I am now able to access pms. I am still a bit confused because I am now able to access pms from my vpn again (separate VLAN). Anyways, thank you for the help!
VLAN tagging, applied correctly, is amazing. Stufff ‘just works’. I learned a lot too when I did it.
I am glad you’ve got it all sorted.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
