raqisasim

Thanks again -- for anyone else running into this situation, I did an Extended SMART which came up clean as well, pushed some cables, and am currently doing a data rebuild based on official guidance: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Hi all -- wanted to confirm with my logs/situation what I gathered from this post, that a high Correction algorithm invocations count is not necessarily indicative of a bad drive, per the below: Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 9823616 368586.466 0 write: 0 0 0 0 6846490 95087.111 0 verify: 0 0 0 0 247462 0.000 0 That said, I do see this in my syslog from yesterday, when UnRAID kicked the drive offline: Apr 20 11:11:43 Morningstar kernel: mpt3sas_cm0: log_info(0x31120436): originator(PL), code(0x12), sub_code(0x0436) Apr 20 11:11:43 Morningstar kernel: mpt3sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) ### [PREVIOUS LINE REPEATED 48 TIMES] ### Apr 20 11:14:17 Morningstar kernel: sd 10:0:6:0: [sdm] tag#1529 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s Apr 20 11:14:17 Morningstar kernel: sd 10:0:6:0: [sdm] tag#1529 CDB: opcode=0x2a 2a 00 60 2e c2 bb 00 00 80 00 Apr 20 11:14:17 Morningstar kernel: I/O error, dev sdm, sector 12909417944 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0 Apr 20 11:14:17 Morningstar kernel: md: disk11 write error, sector=12909417880 The disk11 write error repeats about 30 times before the drive goes offline. So the question is, is this a weird one-off, or a sign of trouble to come? I did try to run a Long Self-Test, and it Aborted, but I also see there can be many reasons for that, as well. Diags attached, and thanks for any help and advice! morningstar-diagnostics-20260421-2241.zip morningstar-smart-20260421-2240.zip

Follow-ups: I forgot to mention that post-Docker.img re-creation, that I did lose all the Docker networks for the VPNs I had. I did my final tests before posting yesterday against a re-created VPN. What has also happened, is that now even containers I created after that with VNC connections, such as FirefoxESR, won't connect to VNC if I'm on the VPN. This is not the prior behavior, nor the behavior I recall from my tests yesterday. It works fine when connected to the bridge network. My gut -- for what little that's worth -- says there's something deeply broken about my docker networking stack. For reference, post-docker.img re-creation: docker network ls NETWORK ID NAME DRIVER SCOPE e0d4cdd9fc47 bridge bridge local 6ab26766bcf9 host host local 19bb0f77fd87 none null local 5832de116521 wg6 bridge localwg0 thru 5 are tunnels created prior to the docker.img deletion, two of which I created yesterday in my earlier testing. Ideas welcome, as I'm pretty stumped.

UnRaid 7.2.3. I noticed today that Dockers setup to run thru VPNs setup via VPN Manager are no longer reaching the Internet. this includes both full restart, and deletion of docker.img file and recreation of key containers to test against. Below is a segment of my syslog when I start and stop one such Docker that is aligned to a VPN that has worked before (as of yesterday, to be exact): Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled state Dec 28 18:42:54 Morningstar kernel: vethaa67c28: renamed from eth0 Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled state Dec 28 18:42:54 Morningstar kernel: vethb1fca43 (unregistering): left allmulticast mode Dec 28 18:42:54 Morningstar kernel: vethb1fca43 (unregistering): left promiscuous mode Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled state Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled state Dec 28 18:42:54 Morningstar kernel: vethaa67c28: renamed from eth0 Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled state Dec 28 18:42:54 Morningstar kernel: vethb1fca43 (unregistering): left allmulticast mode Dec 28 18:42:54 Morningstar kernel: vethb1fca43 (unregistering): left promiscuous mode Dec 28 18:42:54 Morningstar kernel: br-f1c71bf35e99: port 1(vethb1fca43) entered disabled stateA sample of a few Dockers, both on VPNs and on Bridge, shows I get similar messages as above when I start and stop them; only the "vethb1fca43" changes. I will also note that, when I switch Dockers to Bridge, they can reach the Internet (tested by switching my Firefox ESR Docker from VPN to Bridge. I can find few references to this issue, elsewhere. A couple other notes: Saw reference to needing ipv6 enabled; not sure why I'd need that now as I've had it disabled in both UnRaid and OPNSense for some time. Was up to 87% full with Docker Image file; I did re-create it with more space, and you can see in logs I got, for a time post-resizing, a error saying Docker image file couldn't mount. Eventually, it did. I did update OPNSense to 25.7.10 yesterday; however, everything worked fine after that, up until today. Thanks for the help! morningstar-diagnostics-20251228-2003.zip

For future reference for others, everything has now run overnight successfully. I did get new disks, but I also looked at my mess of a cabling solution and brought in new SATA data and power connectors, and rewired/documented everything, double-checking connectors and the like. I did have distressingly loose SATA data cable connectors, despite the locking mechanism, so it's possible that was the proximate culprit. The 2 new drives have synced without errors reported, and the system is working as per normal. Thanks again!

The UPS it's attached to did just shutdown, out of the blue, a couple weeks ago. Maybe I should try swapping in other UPS + using my Power Supply tester, plus double-checking connectors? I should have a spare power supply around here as well.

On Unraid 7.2.2 with 2 Parity Drives -- and 2 drives offline due to errors, over the course of 2 days. Because I lost a drive yesterday, and now today, I looked again in the logs, and raise this ask for help. I see this error in the logs among the more standard "kernel: md: diskxx read error" errors: Nov 30 18:29:01 Morningstar kernel: pcieport 0000:00:01.1: AER: Correctable error message received from 0000:00:01.1 Nov 30 18:29:01 Morningstar kernel: pcieport 0000:00:01.1: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) Nov 30 18:29:01 Morningstar kernel: pcieport 0000:00:01.1: device [8086:462d] error status/mask=00000001/00002000 As well as this: kernel: ata6.00: exception Emask 0x10 SAct 0x400 SErr 0x4090000 action 0xe frozen Thus my concern of a broader issue, as [8086:462d] is a PCI Bridge: 00:01.1 PCI bridge: Intel Corporation Device 462d (rev 05) I wonder, for example, if my LSI 9305-16I is failing and taking drives down with it, but I lack experience in interpreting this information. Any advice on how to troubleshoot, or what my root cause is, is welcome. FYI, I moved to 7.2.2 just under 10 days ago. Thank you! morningstar-diagnostics-20251204-1214.zip

Hi. So I just ran into this issue, as well, and this command resolved it: ln -s /var/local/emhttp /usr/local/emhttp/stateThe commonality appears to be not just UnBalance, but bulk file movements in general. I was copying about 100G/4K files thru an SMB mount from my desktop to my UnRAID when this occurred. A similar copy didn't trigger it earlier, I think; for reference this was copying to a Share that has a 2TB cache --> Array setup. I'm attaching my diags, but also the contents of /var/log/phplog, given it's actually showing some kind of errors, as others have reported: [14-Nov-2025 20:27:52 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 [14-Nov-2025 20:27:55 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 [14-Nov-2025 20:30:30 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 [14-Nov-2025 20:31:22 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 [14-Nov-2025 20:31:29 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 [14-Nov-2025 20:32:42 America/New_York] PHP Fatal error: Uncaught TypeError: extract(): Argument #1 ($array) must be of type array, false given in /usr/local/emhttp/plugins/dynamix/template. php:50 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/template.php(50): extract(false) #1 {main} thrown in /usr/local/emhttp/plugins/dynamix/template.php on line 50 So yeah, I'd assume this has something to do with one of the Dynamix plugins that deal with file changes. I'm going to remove almost all of them I have installed, for now: Dynamix File Integrity Dynamix S3 Sleep Dynamix System Buttons Dynamix System Information Dynamix Cache Directories I also have Dynamix SCSI Devices but given it's rename functions I don't want to risk deleting it quite yet. My goal is to do some more file movements and then see what the results are, then respond to this thread (if I remember!) Thanks to everyone who's reported and helped, so far. ETA: One more data point -- when this 1st occurred, I tried a different browser that I'd never logged into UnRAID onto before. I was able to load the login page, but hit the 500 error after login. Don't know if that helps anyone, but wanted to point that out. morningstar-diagnostics-20251114-2049.zip

Thank you! Worked like a charm.

Upgraded Unraid to latest, not anything else. No drives have been moved in any way, yet.

Hi. I have to apologize on multiple counts. I upgraded, shut down the server, and left home to spend time with family, so won't be able to add the diag file until I get back Monday. If you want to ignore the rest of this reply until I can add the file, I understand. I say this because I clearly am causing frustrations I do not mean to, by not explaining fully and using incorrect terms instead of fully documenting my idea. Again, my apologies for that, and I will ensure I upload the requested diagnostics ASAP upon my return to my home. That said, I ask for your patience as I attempt to clarify my situation and goals: 1) I have an Array with 1 8TB parity drive, currently, and a mix of 4 and 8 TB drives, a mix of SAS and SATA, for the data drives. 2) I have 3 8TB SAS drives, not installed in anything currently, that I would like to use in this Array, in the following ways: 2a) Use 2 of the 8TB drives to replace 2 of my existing 4TB drives, and 2b) Use the last 8TB drive to become a 2nd parity drive; it will not replace any existing drive 3) I have one more SAS connector for a drive, so cannot connect two more SAS drives to the server/Array. It will, obviously, need to become the connector for the 2nd Parity. To hopefully clarify why I referred to shrinking the array for the above process -- as I said in my original post and above, I used that "shrink array" process, from that wiki page of "shrinking the array," to do this a few years ago, successfully. That time, I "shrank" the Array by three 2TB SAS data drives, physically removing said drives, then adding three 4TB SAS drives into the same Array. I did it in this fashion because that wiki page says explicitly that "This method is best if you are removing more than one drive" which is my plan, per above, and also given connection limitations. That is why I linked to that page, and talked about shrinking the array. The idea I have this time is to do 2a) above by "shrinking" out the two 4TB SAS drives currently attached and in the Array, physically removing the drives, and then adding the 2 new 8TB drives in. Along with, of course, adding a 3rd 8TB drive for a 2nd Parity, as I mention above. And I'm trying to ask if there's a better approach that using that wiki page, esp. given the age of that wiki page and the goal to add the 2nd Parity. Given that your guidance leverages using "New Config" once the new drives are added, which aligns with Step 4 in the wiki documentation, I suspect, at the end of the day, it is still the right procedure, and this confusion was due to my clumsy words more than anything technical. I hope this clarifies my goals w/o adding more frustration to the discussion. Thank you, all, for your time and attention, and again I shall add the diagnostics as soon as possible.

New parity drive is same size as current, so it sounds like I'm just going to add everything and then rebuild, and that's fair enough. Thanks for the information!

Same as my current parity, 8TB.

Yep -- sorry, I should have mentioned I clocked that in my research and it's part of why I will upgrade before going further.

Hi all! I've had 3 8TB drives sitting around for a while, and I would like to finally integrate them into my UnRaid Array as safely as possible, while not taking more steps than needed. Since I'm about out of SAS ports (I have onboard+card) I'd rather pull 2 of my 4TB drives and replace with the 8TB, and add the 3rd 8TB as a 2nd parity. I've done the process at https://wiki.unraid.net/Shrink_array#For_unRAID_v6.2_and_later before, years ago. I've already used unBalance to move data off my designated drives for the swap. So, my questions are: Is that "shrink array" process above still the best for swapping out data drives? Is there a good process for doing the above and adding 2nd parity drive at same time? Or do I need to do them one at a time? If I do need to add 2nd parity separate from swapping data drives, should I do the 2nd Parity first? I am OK with taking my time to do it "right," and just wanted to know if there's a better way that I'm just not aware of. Thanks for the time! NOTE: Yes, a few revisions behind; unBalance has, of course, taken time to move the files and before that I got busy with work. I plan to upgrade to latest before doing anything further.

Hi! As I mentioned, my ability to support debugging is limited, esp. if you're 100% certain you followed all the steps exactly. The only thing I can recommend is to check your workers GUI and see if there's even workers to spin up, as well as confirm if you asked for said workers to get spun up per the docker parameters.

First -- I'm no expert. I'm just a newbie around this, too! I cannot make any promises I can support deep debugging. But always try looking at logs, first. Each Docker container has a log you can look at for troubleshooting. Second, I noted in Step 7 a point where I did fail to see the GUI, so I'd triple-check that Elasticsearch actually is up and functional, as well as carefully re-check the other steps. If that doesn't work, re-start from ground zero (none of the relevant Dockers installed, appdata for those Dockers completely deleted as per Step 2) to ensure you've got the right config setup from jump. In short, this is all a bit complex, and in fact since I also haven't gotten re-scanning to work per Surgikill's comment above I've set it all aside for now, myself. But hopefully this'll help you!

So, after reviewing this thread, I followed OFark's steps, and finally got it working! (i.e. Diskover GUI loads and workers are running against my disks) For those who are deeply confused, I wanted to expand on that worthy's notes, as there are a couple points where I got stuck, and suspect others have/are in similar situations: Check if you have the Redis, ElasticSearch, and/or Diskover Docker containers already installed If you do, note where your appdata folder is hosted for each, then remove the containers, then remove the appdata (removing the appdata is crucial! An older config file really tripped me up, at one point). You'll likely need to SSH or use the UnRAID Terminal in the GUI to cd to the appdata folder location and rm -rf them. This may not be required, however -- to ensure the OS setting for ElasticSearch was set before I installed, I followed the steps at this comment: that start at "You must follow these steps if using Elasticsearch 5 or above". IMPORTANT NOTE: I did NOT install this ElasticSearch container, just used the script instructions. For which container I did install, see Step 5, below. Install the Redis container via Community Apps. I used the copy of the official Redis Docker in jj9987's Repository (Author and Dockerhub are both "Redis"). It should not need any special config, unless you already have an container running on Port 6379. To install ElasticSearch version 5, go to https://github.com/OFark/docker-templates/ and follow the steps in the README on that page; it'll have you setup an additional Docker Repository first. Note that, so far as I can tell so far, I did not need to do anything in OFark's Step 6, on that page, around adding values in Advanced View. If that turns out to be a mistake, I'll update this. At this point, I recommend checking your Redis and ElasticSearch 5 container logs just to ensure there's no weird errors, or the like. If it all looks good, install the Diskover container via Community Apps. To avoid the issues I ran into, ensure you have all the ports open to use (edit if not), and that you provide the right IP address and ports for both your Redis and ElasticSearch 5 containers. Also make sure you provide RUN_ON_START=true, and set the Elasticsearch user and password -- if you don't give the latter, you'll get no Diskover GUI and be confused, like me Once Diskover starts, give it a minute or so, then go to it's Workers GUI (usually at port 4040). You should see a set of workers starting to run thru your disk and pull info. From there, you should be able to go to the Diskover main GUI and see some data, eventually! As I wrap this, so did my scan; now to pass thru some parameters to get duplication and tagging working (I hope!) I hope this helps -- Good luck, everyone! And thanks to Linuxserver for the Container, and OFark for templates and guidance that helped immensely in setting it up for UnRAID!

Hi folks -- asking for help on an issue with my preclear on 6.7. First off, the issue may be simply that I was doing a preclear on a 8TB external USB drive. If so, I'm happy to shuck/install/retry the preclear. The main issue is that said preclear has apparently locked up the UnRaid UI. The UI was up during the preclear until after the Erase stage of the preclear completed. I can login via SSH, but attempts to go to the Web Interface throw a 502 Bad Gateway error. Prior to that, I wasn't able to get the Unassigned Drives section to load in the UI, once the Erase pre-clear stage started. FYI I'm confident I picked right drive for preclearance; the Array has been down since I restarted prior to preclear, and I can see the USB drive's activity light running as I write this. So it should be only drive doing anything (aside from USB stick, of course). Thoughts?