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.

Thank you. If you have the time at some point the directions would be great (especially for someone else who might stumble on this thread with a similar problem). Since I already tried to add the drive back into the pool I’ll likely not bother trying anything other than solving the hardware problem and rebuilding the plots, but it would definitely be helpful for future reference. I don’t quite get why btrfs non-redundant pools aren’t like JBODs, so they’re basically raid0 without the added speed? EDIT: leaving a note for myself to avoid bumping the thread: if unRAID assigns a new ID to one of the drives, remove all drives from pool, reboot, then check to make sure the ID is back to normal and reassign, then start array. It will take a couple minutes but the pool will restore.

You can access array drives outside the array, that's kind of the point of the whole unRAID setup. Connect directly to each drive from any linux box until you find the drive that has the most recent backup.

I have three pools that I use for shares for Machinaris/Chia mining that are made up of 5 old laptop drives each. Two of them work fine, however one of them has a drive that for whatever reason will drop out of the pool after a day or two of use. The drive is fine, this is most likely an issue with the hardware I am using to connect it and I am working on that, however I have a bigger problem: Unraid can add the drive back into the pool without a problem, but when I start the array up again that pool reads as "Unmountable: No file system". I tried the cli suggestions in the FAQ and none of them worked; the first time I figured it may have just been some kind of fluke so I just reformatted. Everything worked fine until the drive dropped out again, and same thing again. Before erasing all the work on it I wanted to see if anyone has had this problem before? The drives are set up as JBOD (or whatever BTRFS calls it, can't remember offhand) so theoretically even if that drive failed the data on the other four SHOULD be fine, right? Is there a way I can access it?

Sorry, I missed this reply. Planning to overhaul my server this next weekend so will try it out then and get back to you!

Will this include LTO support?! If so that would be amazing, it's the only thing I keep a Windows VM for...

I came across his videos before, they're good and informative but not very...concise. Excellent for a start to finish initial setup, but a lot of scanning for someone familiar with Unraid. The biggest difference seems to be, as you suggested, ram, but setting up a ramdisk (instrux for which I came across on page 10 of this thread). That is a complete game changer, it knocked phase one down to 25% of previous plots...

Brave is my goto. Honestly, while Apple's hardware and OS keep getting better and better, their apps have gone to total crap the past couple years. I don't think there are any that I still use on most on my machines (my laptop still uses Safari for basic tasks), they are all increasingly buggy and unreliable; Server, Mail, iTunes/Music, Safari, Numbers...all get worse with every update. It's a shame, really, 5 or so years ago they were so close to having a completely on brand work environment and now they're just an OS again.

Is there a guide to optimizing plotting? New to chia and been running it for a few days now and have only plotted 18 plots (averaging around 4 hrs per plot). I mean, it's just running in the background and not using much in the way of resources so no big deal, but I'd like to get it as efficient as possible... So far I've played with thread counts and haven't noticed much of a difference (tested out 12, 15, 16, 24, and 32 so far). Only real difference I noticed was my first plot only took two hours, second 3, and then the rest have been just under 4; I assume this is an ssd trim thing? Running on a 3950x w/128gb ram, temp is a 2tb SATA ssd cache, plots are saved on a btrfs jbod cache of 5x5tb drives, using Mad Max.

THANK YOU. This was driving me crazy. I set that so long ago I totally forgot...

I took my server down for some basic maintenance (hdd stuff) and ever since bringing it back online everything is working fine, but there is some weirdness. My local network no longer recognizes the localhost name, though the ip address works just fine. Also, while the mover used to be scheduled daily, I reset it for once a week, yet still at 2am EVERY night, all my docker apps stop. And when I brought it back online most recently one of the cache drives stopped working, with an error saying it was encrypted (which is weird since literally every other cache drive is also encrypted and works fine). I removed it from the pool, copied files over to the array, replaced and blanked it, and then copied them back and that seemed to work, but yeah, just a bunch of weird things happening all at once...