this is a brand new rasbian build? it hasn’t been reused from something else? no pihole or vpn software running?
can you ping 198.18.1.1 from the Pi?
can you add a -v to the curl command from ChuckPa - it should (hopefully) dump a bunch more info.
About a week since I installed the OS:
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
It is also running nginx/php-fpm, though not with any hostnames, no DNS, I just access it by IP. First thing I tried was shutting nginx down in case it was interfering, but it made no difference (which makes sense because it is on port 80 and Plex is on 32400). No pihole, no VPN.
I have a log of what I’ve installed and the process etc, so I can refer back to it and rebuild fast if I want. I’ve been over it a thousand times in case I missed something obvious, here’s the high level:
- disabled wifi;
- lock down SSH config;
- install nginx/php-fpm;
- install mysql;
- install unattended-upgrades;
- install netatalk for afp for USB disk;
- mount a USB disk for Time Machine targets and Plex;
- install Plex (4000 times);
No:
# ping 198.18.1.1
PING 198.18.1.1 (198.18.1.1) 56(84) bytes of data.
^C
--- 198.18.1.1 ping statistics ---
119 packets transmitted, 0 received, 100% packet loss, time 122742ms
Good idea, though unfortunately I don’t think it shows anything new:
$ curl -v -X POST http://127.0.0.1:32400/myplex/claim?token=claim-xxx
* Trying 127.0.0.1:32400...
* Connected to 127.0.0.1 (127.0.0.1) port 32400 (#0)
> POST /myplex/claim?token=claim-xxx HTTP/1.1
> Host: 127.0.0.1:32400
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< X-Plex-Protocol: 1.0
< Content-Length: 109
< Content-Type: text/html
< Connection: Keep-Alive
< Keep-Alive: timeout=20
< Cache-Control: no-cache
< Date: Tue, 22 Feb 2022 07:50:23 GMT
<
* Connection #0 to host 127.0.0.1 left intact
<html><head><title>Internal Server Error</title></head><body><h1>500 Internal Server Error</h1></body></html>
This is a puzzler. I only thing I can suggest is the nuclear option. Ideally find a new SDcard, put brand new rasbian on it, then install the pms deb before anything else. If it works, add everything else back one at a time testing between each. if it doesn’t, maybe wifi it to a hotspot and see if that changes anything to rule out your ISP doing something super weird somewhere.
I have an old RPI 3 waiting around for another project. I thought I’d try a clean install there as you suggested.
First attempt - flashed a new boot image using the Rasberry imager, with a bunch of the advanced options enabled, since the Pi is headless this speeds up the set up. The advanced options do stuff like set a hostname, set up SSH, etc. Booted it up with a wired connection. Created a plex user. Installed the .deb. Watching the logs I saw the same "Network: 192-168-xyz.plex.direct failed to resolve to 192.168.x.x but instead yielded “198.18.1.1"” msg, and nothing worked.
Next attempt: I repeated the whole process, this time absolute vanilla, no advanced options for the boot image, hooked up a mouse/keyboard/monitor, manually configured wifi. Did not create a plex user, just downloaded and installed the .deb. I saw the same message and mystery IP again in the logs … but this time it works!?
So it looks like that IP and the msg are red herrings, not the cause of the problem at all? The only significant things that I can see that are different:
-
wifi instead of wired ethernet;
-
didn’t create a plex user before install;
-
didn’t specify a host name in Raspberry imager advance options. Previously I specified hostnames like “rpi4.local” and “rpi3.local” in the imager; when I did not use those options it just defaults to “raspberrypi”.
I guess the wifi vs ethernet diff seems the most significant, in terms of the networking trouble I’ve been seeing … ? Or maybe .local part of the hostname? Anyone got any clues?
It is late and it’s been a long day. I’ll investigate the logs properly tomorrow, see if there is anything else to go on.
It worked because when you create user plex in advance, it ends up in /home.
plex's home directory is defined as /var/lib/plexmediaserver by the installer.
The resultant plex user you created isn’t configured correctly (home directory in the wrong place)
This sounds very promising, but unfortunately does not seem to be the problem - or at least not the only problem. On the original RPI 4 where I started:
- I nuked my plex install, and manually removed any plex-related files;
- I removed the plex user’s afp shares from
/etc/netatalk/afp.conf - I nuked my plex user, with
--remove-all-filesto remove everything that user owned; - rebooted the RPI;
- manually installed the
.debagain (new version today, 1.25.6.5577-c8bd13540);
No change.
Interestingly I am not able to log in to the Plex forums in Safari atm (I’m writing this in Chrome). I’ve been using Safari for all Plex related stuff, so I can clear the entire browser history between each attempt. I came here in Safari to post this update, clicked login, and I am bounced to https://app.plex.tv/auth/ which shows a blank page. Browser devtools doesn’t show any errors or failed network requests, but nothing happens and reload without cache does not help. I wonder if I’ve hit some throttling limit with all my logins and failed attempts to claim the server. https://status.plex.tv/ does not show any issues.
I would focus on taking the device when in this working state and getting eth to work. This points at a config problem rather than ISP/router. (or maybe a limit problem given your later login issues - not that I have ever heard of such a thing before)
So you mean media shares, or the Plex database and metadata? If the later this won’t be causing your immediate issue, but be careful as it may corrupt your DB later.
Thanks - think I’ve cracked it. When I restarted that working RPI3 this morning, the server was unclaimed again. Clicking claim did work - but I had to repeat that every reboot. I spent a few hours and a few dozen reboots changing things and rebooting, without identifying anything that helped, nor what caused this.
I went right back to my first assumption - trouble with ipv6. I have been disabling it in Plex (Settings → Network → Show Advanced) as one of the first steps of all my attempts, but I thought I’d try doing it at the OS level. In Raspbian apparently the way to do that is to add
ipv6.disable=1
to the end of the single line in /boot/cmdline.txt. I tried that, rebooted, and bingo, I am able to claim the server. I rebooted, and it is still claimed.
I applied that change to the original RPI4, rebooted, and magic, I can claim it and it persists through a reboot. My Plex clients can see the server. Hurray!
Huge thank you to everyone who chimed in, @BobSnot in particular kept me going when I was ready to toss the Pis out the window 
Thanks also @ChuckPa, it is great to have someone on the Plex team helping out.
Now that I am out of the forest and can see a few trees, I am curious why this happened. My very first suspicion was trouble with IPv6, and so disabling that in Plex under Network → Advanced was the first thing I tried, and I kept that enabled for all my many attempts. Why was that not enough?
Anyone have any clues?
I’ve a full ipv4 and ipv6 stack running, most of my daily web surfing it happening over ipv6 these days.
I know lots of people have issues with ipv6, and there are lots of recommendations throughout these forums to disable it but I’ve always had It enabled. The only issue it gives me is that my remote access only ever appears green for a few seconds after server restart, all other times it’s red but this is purely cosmetic, it works fine 24x7. My best guess for this case was it just didn’t like something about your network + the customisations you were putting in place, but it really is a finger in the air type guess.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
