ugnaught

Last update (I hope). I tried rolling back the version of Plex, trying different dockers (binhex, official, etc) and even tried a fresh Plex install. None of that worked. Kept rebooting every night at 2am. Gave up and wiped my cache pool clean and started over. I unmounted the cache drives, started up array with no cache, wiped cache drives, then added them back with the warning "all data will be erased if you add these drives". Only thing I copied over after this was my appdata backup for some other dockers (not Plex). 100% started over with a new Plex docker/server config. Has been three days with no reboots with Plex running 24 hours. Wish I could say exactly what was causing the issue but I grew tired of the reboots before I went scorched earth. Something somewhere on my cache had to have been corrupted/bad permissions/etc. Sometimes it is easier to start over than deal with the troubleshooting headache.

quick update, changing docker privileged to "on" did not affect anything. it still rebooted.

I have plenty of space on my side. So it likely isn't the cause of my issues.

@cmac1982 so bad news, I still had issues with Plex this last night and had a reboot this morning. Another thing I noticed is that my Plex container is set to with "Privileged = off". Most of the reading I can find says to set it to "on". So I just made that change too and will see if results are any different. Another thing I found (finding lots of stuff) is that upon the reboot this morning my server name changed from a unique name to the default "Tower" which could be an indication of a bad USB drive used for my boot device. I just ordered a replacement and it should be here in a couple of days and I will also test swapping that out. Additionally one thing to look at is the last time Plex was able to backup your database. The default action (as can be seen in one of my screenshots in an earlier message above) is to do it every three days. Then it appears to only save the 3 most recent. Looking at my backup folder it hasn't be able to successfully do that since February. Which is around the time I began having random issues. I haven't always had a use for Plex everyday so I sometimes went weeks without turning it on which led me to taking a while to find the issue. All in all........ this is really lining up that when Plex runs it's scheduled maintenance at 2am something is catching and causing a reboot. This doesn't seem like a hardware issue at all.

@EDACerton Unfortunately I tried that already to look for a hint, but no dice. Just begins showing bootup around 2:03 Apr 10 00:00:11 Unraid-Server root: /var/lib/docker: 25.3 GiB (27136815104 bytes) trimmed on /dev/loop2 Apr 10 00:00:11 Unraid-Server root: /mnt/cache: 338.9 GiB (363936219136 bytes) trimmed on /dev/nvme0n1p1 Apr 10 00:16:01 Unraid-Server crond[1142]: failed parsing crontab for user root: Invalid frequency setting of /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 Apr 10 00:20:01 Unraid-Server sSMTP[16636]: Creating SSL connection to host Apr 10 00:20:01 Unraid-Server sSMTP[16636]: SSL connection using TLS_AES_256_GCM_SHA384 Apr 10 00:20:01 Unraid-Server sSMTP[16636]: Authorization failed (535 5.7.8 https://support.google.com/mail/?p=BadCredentials o9-20020a0568080f8900b00389533b1cc8sm3982888oiw.18 - gsmtp) Apr 10 01:03:01 Unraid-Server crond[1142]: failed parsing crontab for user root: Invalid frequency setting of /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 Apr 10 01:50:01 Unraid-Server crond[1142]: failed parsing crontab for user root: Invalid frequency setting of /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 Apr 10 02:03:16 Unraid-Server kernel: Linux version 5.19.17-Unraid (root@Develop) (gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #2 SMP PREEMPT_DYNAMIC Wed Nov 2 11:54:15 PDT 2022 Apr 10 02:03:16 Unraid-Server kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Apr 10 02:03:16 Unraid-Server kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Apr 10 02:03:16 Unraid-Server kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Apr 10 02:03:16 Unraid-Server kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Apr 10 02:03:16 Unraid-Server kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Apr 10 02:03:16 Unraid-Server kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. Apr 10 02:03:16 Unraid-Server kernel: signal: max sigframe size: 1776 Apr 10 02:03:16 Unraid-Server kernel: BIOS-provided physical RAM map: Apr 10 02:03:16 Unraid-Server kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable Apr 10 02:03:16 Unraid-Server kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved ---------------------------------------------------- But one thing I did notice while poking around is that for some reason my Plex appdata is spanning across the array when I have that share set to 'cache prefer'. So I changed it to 'cache only' and made a copy of my plex folder (plexmediaserver_old) and pointed the container at that copy which is sitting on only the cache now. I wonder if something has gotten corrupted with that appdata folder and the mover can't get it off the array. Then potentially when the Plex scheduled tasks run at 2am it hits some pocket of corrupted data. Why on earth it is causing the server to reboot I have no idea though. Going to see if moving the data helps. I should know by tomorrow morning

Just realized that Plex scheduled tasks run at 2am by default. ---------------------------------------------------------------------------------------------

I am now having this same exact issue. But I have boiled it down to Plex running overnight. Was originally running linuxservers version, tried reinstalling it, still rebooted overnight. Tried removing that version and installing the official version, still reboots. It always happens around 2am. All other dockers can run overnight with no issue. But as soon as I let Plex run overnight I wake up to a fresh reboot and a parity check running. I've checked syslog messages but they are not helpful. It appears to be a hardware issue (due to lack of information in syslog) but is also very much tied to the Plex docker. If I do not run Plex then my server can run for weeks with no reboot. AMD Ryzen 5 3400G ASRock X570M Pro4

Renaming the folder did the trick for me. Thanks! Unfortunately it would appear there is no way for me to manually enable CSM boot on my motherboard. Oh well, at least the EFI change did it!

I had an older AMD APU and motherboard setup and the motherboard just died out of the blue. So I am unable to get a list of previous hard drive placement and do a fresh install. But that almost doesn't matter because in my testing with a new CPU (Ryzen 5 3400G) and motherboard (ASROCK X570M PRO4) I am unable to boot into Unraid. * I can't boot using older original unraid USB * I have installed unraid fresh onto 2 different USB's to see if issue with original, can't boot those either * I am able to boot into a Windows live USB, that tells me the motherboard and all hardware are fine from that perspective * I updated motherboard BIOS, no change * I've ran the "make bootable" bat a buncha times * The BIOS sees all original hard drives from initial unraid install, everything seems in order The BIOS sees the USB sticks with unraid installed and that it is bootable. Although when I try and reboot it just tosses me back into the BIOS after a reboot. I never see anything trying to post from unraid. Windows USB boots right up with no issues. I'm at a loss. Are there any known issues with this setup and Unraid specifically? I can't seem to find anything.

Confirming that I am seeing the same thing. This whole thing is kinda silly and making me think it is time to move on from PIA. I was giving them the benefit of the doubt with the Kape Technologies sale. But take that combined with awful service like this and it may be time to find greener pastures.

This was following the instructions found here. https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md Modify repository on the edit page from binhex/arch-deluge to binhex/arch-deluge:X.X.X Get previous build number from here https://hub.docker.com/r/binhex/arch-deluge/builds I'm not seeing any previous version numbers there so typed in what I had previously. Manually typing the previous version doesn't help. Thoughts? We screwed trying to rollback? I use the GTK app on my Windows machine to manage multiple Deluge instances. Not really a fan of having to do everything via the web gui. EDIT: Had to dig around on google. try "binhex/arch-deluge:1.3.15_18_ge050905b2-1-01" to rollback from 2.0 Although the rollback did wipe out all my torrents. Meh.