Server Version#: 1.18.7.2457-77cb9455c (CentOS 7 x86_64)
Player Version#: N/A
This is more of a report/PSA than a request for help. (Does Plex have a public issue tracker anywhere?)
It seems that in order to run the PMS setup wizard, one must not only connect from the local subnet, but the connection must be over IPv4. If the connection is made over IPv6, the PMS behaves as if the connection were from a non-local subnet. (My IPv6 subnet is within the fd00::/8 ULA range.)
This is easy to work around, once one knows what is going on, but the PMS does not provide any indication (that I’ve been able to find) as to why the setup wizard is not running.
(And lest you think that I’m some sort of masochist who enjoys typing IPv6 addresses, IPv6 connections are the default these days when using a hostname to connect on an IPv6-enabled network.)
As I mentioned, it was easy to work around. In this case, my client actually was on the same subnet, so I just had to type the IPv4 address. My post was more of a PSA than anything else.
$DIETY knows that IPv6 has been a long time coming, but we are at the point where a fair number of ISPs at least offer it, and some of them are starting to enable prefix delegation by default on the “routers” that they provide to customers. When that happens (often without the customer’s knowledge) it only takes someone connecting to their new PMS with its hostname, rather than its IPv4 address to hit this issue. (I didn’t test “localhost,” but it wouldn’t surprise me if that also hits this issue when it resolves to ::1, rather than 127.0.0.1.)
I thought it was pretty well know, but do thank you for the PSA, that Plex only has partial IPv6 support at this time.
By that, I mean “Plex as a whole” (your individual server and Plex.tv services).
IPv4 is still the defacto standard because the majority of customers don’t have IPv6 service yet from their ISPs. Those with IPv6 from their ISPs are silently served by V6<->V4 translation at their ISP level.
