greyday

You are an absolute legend. Your guide worked flawlessly to set up current build using postgresql18. Thank you SO much!

This solved it, thank you!

So after years of working just fine it stopped working a week or so ago. Logs copied below. No idea what the issue could be. 2025-09-19 05:43:22.768851 [info] Host is running unRAID 2025-09-19 05:43:22.785044 [info] System information: Linux 7fec531bc0f2 6.12.24-Unraid #1 SMP PREEMPT_DYNAMIC Sat May 3 00:12:52 PDT 2025 x86_64 GNU/Linux 2025-09-19 05:43:22.801919 [info] Application name: 'delugevpn' 2025-09-19 05:43:22.817708 [info] Base image release tag: '2025072801' 2025-09-19 05:43:22.834349 [info] Output image release tag: '2.2.0-1-04' 2025-09-19 05:43:22.854666 [info] PUID defined as '99' 2025-09-19 05:43:22.877814 [info] PGID defined as '100' 2025-09-19 05:43:22.912750 [info] UMASK defined as '000' 2025-09-19 05:43:22.930289 [info] Permissions already set for '/config' 2025-09-19 05:43:22.955131 [info] Deleting files in /tmp (non recursive)... 2025-09-19 05:43:22.982733 [info] VPN_ENABLED defined as 'yes' 2025-09-19 05:43:23.001274 [info] VPN_CLIENT defined as 'openvpn' 2025-09-19 05:43:23.018941 [info] VPN_PROV defined as 'custom' 2025-09-19 05:43:23.047575 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/Windscribe-Amsterdam-RedLight-GCM.ovpn 2025-09-19 05:43:23.088719 [info] VPN remote server(s) defined as 'ams-289.whiskergalaxy.com,' 2025-09-19 05:43:23.104303 [info] VPN remote port(s) defined as '443,' 2025-09-19 05:43:23.120517 [info] VPN remote protcol(s) defined as 'udp,' 2025-09-19 05:43:23.137997 [info] VPN_DEVICE_TYPE defined as 'tun0' 2025-09-19 05:43:23.155870 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS) 2025-09-19 05:43:23.173696 [info] NAME_SERVERS defined as '1.1.1.1, 8.8.8.8'

My server went down on Thursday just as I was leaving for a couple days; it rebooted but my password wasn't with me so I couldn't start the array until today. Started it up, it ran for a bit and then rebooted again. It's back up now so far, but twice isn't a coincidence IMO so I checked FCP. Fix common problems mentioned an mcelog error, so I checked the diagnostics (attached) and saw this: mcelog: ERROR: AMD Processor family 25: mcelog does not support this processor. Please use the edac_mce_amd module instead. I'm a bit confused as I've been using this processor for about 4 years now with no issues (or notable ones) but if this IS the problem how do I go about swapping this module out? And if not, anyone see anything obvious that I missed (I really just did a search of the main syslog as I'm not entirely sure what I'm looking for)... Thanks!

Hi--thanks for responding! I wanted to report back, I ended up double checking my local network settings thanks to another response on here and found that the update changed my local network from 192.168.0.0/24 to 192.168.1.0/24. On a new reinstall I changed it back and everything seems to be working like normal. EDIT: you know what? That wasn't the problem, because I just checked my initial setting screenshots and it didn't change it, it was just the new install defaulting to x.x.1.0/24. But it's all working fine now so I have no idea what the problem was. Sorry I couldn't be more help!

I just updated the docker and it is no longer working, it seems to freeze at the "NAME_SERVERS defined as" stage; it connects with my VPN and pulls IPs, but then nothing further. It sat for a couple hours after the update before I noticed it, so it's definitely not a "wait a little longer" issue. Restarted it and same deal...

Thank you both! That was driving me crazy.

I can't seem to clear my cache pools. There is close to a full TB in between the main cache and my secondary pool. I am trying to upgrade my main cache but the only way I seem to be able to move files off it would be to go from disk to share, which I was told is a bad thing. Mover will not move these files; even though all shares have been set to array and are no longer pointed at the pools, even secondarily; appdata, system files, and my isos are all still on my cache and will not move. Is it ok to go from disk to share? Am I remembering that incorrectly, and the real problem is going from share to disk? I know mover was having issues with the mover scheduler app; I deleted that and invoked mover, which then moved SOME files but the rest are still there. No idea what to do, spent a couple days googling and trying solutions and aside from the dumping of the mover scheduler nothing even slightly changed. Diagnostics attached, any help would be greatly appreciated. Thanks!

Did you ever find an answer for this? Trying to backup before moving to v7 and having the same problem...

I'm marking that as "solution" since the drive passed preclear without a hitch. I'll update the original post if it fails when being entered back into parity but I think it was probably just a glitch...

Had a new thing happen to me yesterday; I bought 2x20TB Seagate Exos drives on cyber monday and swapped them in for my 14TB parity drives (2 years old). Here's the order I did everything: Stopped server added new drives into vacant slots in my DAS Removed parity drive 1, added first 20TB Started server, rebuilt parity Repeated process for parity 2 Removed a 4TB drive, added 14TB, did data rebuild All of the above went off without a hitch, zero errors (note that I did not do a preclear on the new drives as I figured they would get the same workout from the rebuilds). Everything was working fine, so I swapped in the final drive. Rebuild ran fine for 90%, then it and the second parity drive started throwing errors. Like 500+. The rebuild was frozen and, assuming it was the old parity/replacement drive (14TB) that was rebuilding that failed, I tried to replace the old data drive and rebuild the errored 20TB parity drive, but it wasn't showing up in the interface at all, as an option for the parity slot or in unassigned devices I stopped the server, physically pulled the parity drive and put it back in and it showed up again. I am currently almost finished with rebuilding the 14TB data drive again (with single parity this time) and am using the preclear plugin to thoroughly test the 20TB. I also tried to find any errors with smart tests and smrtctl and neither produced any logged errors on either drive. It is entirely possible this was a mechanical fault on the DAS side, since just removing the sled and replacing it got the system to identify it and, aside from the drives themselves (at this point), my entire server is built from second hand and used parts. So my question is this: if it preclears without a problem (and the data drive throws zero errors during the rebuild), should I try adding it back in as second parity or should I bite the bullet and just return it? I've never used preclear before so I don't know how reliable it is, but it seems like both drives are otherwise fine based on every test and piece of info I can find...

Since I hate it when these things go unanswered (especially when I had the same problem and searching led me to a thread with no solution), here's what worked for me: I deleted the preferences file from appdata and then restarted the docker image. I had to "set up" the docker again, but this took like ten seconds, and all my library data was still there, no need to rescan. Steps: stop docker open terminal in-browser (or ssh in if you prefer) navigate to mnt/user/appdata/Plex-Media-Server/Library/Application\ Support/Plex\ Media\ Server rm Preferences.xml start docker open webui That was it. I ended up just deleting the file as trying to copy it gave me the same not found error, and trying to view or edit it in nano resulted in an empty document. I have not found any issues thus far with this method, but note that I only use Plex for local access, other settings MAY be effected by this. ALSO--if like me the reason for your hard shutdown was the UPS shutting off without sending a kill signal (thanks to the standard UPS settings not recognizing my model and the previous build of NUT being deprecated) I HIGHLY recommend Rysz's current rebuild of NUT; it's in the app tab if you search for NUT, then choose "Network UPS Tools (NUT) for UNRAID". It's working flawlessly so far...

I had a docker that wouldn't close that was using a single thread at 100%, so I tried to stop the array, which didn't work. I was able to kill the main stuck process using the tip below, allowing the docker to close (according to the dashboard); however, now the array won't fully stop. The docker page and dashboard says it is stopped, and the docker and vms are gone from the dashboard (like I assumed they would be), but the main page lists all the drives as up (though the bottom just hangs with "Stopping" and the only other options being reboot or shutdown). Both top and htop say nothing is using the thread, but the dashboard still reports it as 100%. There are two processes associated with the docker (machinaris) that can't be killed, no matter what I try (tried through htop, manually, manually -9, pkill, etc.), though neither of them are using any cpu according to htop. Unraid v6.9.2.

I'll take a look, but somehow when I restarted the docker for a fifth time (after four consecutive crashes) it just...started working right again. I changed absolutely nothing, but it's been humming along for a few days now, so I'm just going to let it do its thing until the disks are full and then I'll look into it more. Thanks for responding!

So I'm having a weird plotting issue running on unRAID. I had, using previous versions, plotted about 35tb or so without issue, but as I upgraded a couple drives in my array I decided to use the old ones to add to my chia farm. I am running the plotter the exact same way (settings below) using Madmax, a 110gb ram disk, an ssd R0, and the same drive pool I was using before (I moved the old plots to the new disks and am repopulating the originals now), and the plotter just randomly stops. Sometimes on the second plot, sometimes on the tenth, it just stops plotting. The docker keeps running and farming, the plotter just sits idle with nothing new in the queue, and abandoning temp files in multiple locations (including a full ram disk that I usually have to empty via cli). Did something change in the latest update? My settings are: unRIAD v6.9.2 Machinaris v0.7.1 Plotter: Madmax k: 32 threads: 16 buckets: 512 buckets3: 128 rmulti2: 1 running on a 3950x (hence the threads) with 128gb ram. The plotter runs at night so the only other active docker or service is pihole. Edit to add: the main screen lists plotting as idle, the plotting screen says it is active but nothing is being plotted, the queue is empty and there is no disc activity. Emptying the ramdisk and pausing then resuming plotting starts it up again.