TheBazlow

Here's the docker section I noticed that if the Preferences fields are populated, adding the claim token doesn't seem to change anything, wiping them seems to be necessary before claiming. I didn't sign out of every device prior to doing all of this, i'm pretty sure this would have been a lot easier if I had.

I think i'm fully back up and running. Here's a rundown of my adventure. I've reset my password Opened /appdata/plex/Library/Application Support/Plex Media Server/Preferences.xml Made a backup Removed the values from PlexOnlineHome, PlexOnlineMail, PlexOnlineToken, PlexOnlineUsername from xml file and saved. Stopped the container Added a new variable with a key of "PLEX_CLAIM" to container Opened https://www.plex.tv/claim/ Copied the claim code into the value for the docker variable Restarted the plex docker It populates the Preferences.xml file with new data At this stage I can access the web ui from direct IP. Trying to reach it from plex.tv, apps or custom domain wouldn't work I went to settings, remote access and disabled it, enabled it, restarted docker again and now finally it's started working again.

Overnight extended smart test came back with a clean bill of health, packed it up and returned it today anyway since I could. Unraid is rebuilding parity right now minus one drive and it's much quieter too. The drive definitely made a lot more noise than all the other drives combined, very frequent clicking like the head was jumping between sectors and didn't do it quietly. I'm still not sure what would cause a hard drive to be much louder at moving the head than comparable others but regardless I don't fancy my chances with that in my NAS especially since it started giving IDNF erorrs and read failures to unraid.

I'm leaving it overnight to run the extended test and swapping out cables would mean swapping out a HBA card and a SAS backplane that seems to work fine with every other drive including the previous drive in the same spot. Anyway the drive is not a month old so the retailer is sending a courier to collect it tomorrow since it's still new. Since i'm sending it back, any testing is all academic now. I did find a poster on the WD forums complaining of ZFS constant stream write errors and the same model of drive, the drive model is only half a year old now so maybe this is a thing. My drive seemed to choke on parity and preclear so anecdotally i'm left thinking these Red Plus drives are NAS unfriendly. Then again I could have got a bad batch, I bought 3 and this is the 2nd to be sent back, the first one sounded like an angle grinder and this one plays basehunter with its head.

My NAS started its parity check last night and this morning had read errors The drive is a WD Red Plus 8tb (WD80EFBX), a selective smart scan of these sectors returned no issues however the read errors occurred at the same time as the smart error log recorded an IDNF error. Honestly i'm not well versed in IDNF errors so this one has me in the dark. Is the drive FUBAR/DOA or is this something that could be correctable in software? storage-diagnostics-20210701-1237.zip