Lignumaqua

That is an excellent question. I’ve used these cards before without issues but this is a new case so airflow will be different. There is a case ventilation extractor fan above it, and the case runs very cool overall, but I’m not specifically cooling the card. I’ll measure its temperature.

Thanks. I suspect it was a problem with the LSI card but rather more serious than the similar spin-down related messages which have been posted a number of times on this forum because it actually caused a major shutdown. I have recently rebuilt this server and this is a new (to me!) LSI card so it could be the cause. I think I'll disable spin-down for now and see what happens.

System went down this evening with, eventually, a disabled parity disk. I don't have full log, but I would appreciate any advice on how to interpret the section below which i was able to capture. Was this actually an HDD failure or could it have been a failure of something else? (Shut down system and now rebuilding parity back to the same disk. No SMART errors reported.) Feb 14 21:53:17 Tower kernel: sd 5:0:3:0: attempting task abort!scmd(0x000000004a167f29), outstanding for 15259 ms & timeout 15000 ms Feb 14 21:53:17 Tower kernel: sd 5:0:3:0: [sde] tag#245 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Feb 14 21:53:17 Tower kernel: scsi target5:0:3: handle(0x000c), sas_address(0x4433221102000000), phy(2) Feb 14 21:53:17 Tower kernel: scsi target5:0:3: enclosure logical id(0x500605b001048b70), slot(1) Feb 14 21:53:48 Tower kernel: mpt2sas_cm0: In func: mpt3sas_scsih_issue_tm Feb 14 21:53:48 Tower kernel: mpt2sas_cm0: Command Timeout Feb 14 21:53:48 Tower kernel: mf: Feb 14 21:53:48 Tower kernel: #011 Feb 14 21:53:48 Tower kernel: 0100000c Feb 14 21:53:48 Tower kernel: 00000100 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: Feb 14 21:53:48 Tower kernel: #011 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 00000000 Feb 14 21:53:48 Tower kernel: 000000f6 Feb 14 21:53:48 Tower kernel: Feb 14 21:53:58 Tower kernel: mpt2sas_cm0: sending diag reset !! Feb 14 21:53:59 Tower kernel: mpt2sas_cm0: diag reset: SUCCESS Feb 14 21:53:59 Tower kernel: mpt2sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 4k Feb 14 21:54:14 Tower kernel: mpt2sas_cm0: config_request: manufacturing(0), action(0), form(0x00000000), smid(3428) Feb 14 21:54:14 Tower kernel: mpt2sas_cm0: _config_request: command timeout Feb 14 21:54:14 Tower kernel: mpt2sas_cm0: Command Timeout Feb 14 21:54:14 Tower kernel: mf: Feb 14 21:54:14 Tower kernel: #011 Feb 14 21:54:14 Tower kernel: 04000000 Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: 09000000 Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: d3000000 Feb 14 21:54:14 Tower kernel: Feb 14 21:54:14 Tower kernel: #011 Feb 14 21:54:14 Tower kernel: ffffffff Feb 14 21:54:14 Tower kernel: ffffffff Feb 14 21:54:14 Tower kernel: 00000000 Feb 14 21:54:14 Tower kernel: Feb 14 21:54:14 Tower kernel: mpt2sas_cm0: mpt3sas_base_hard_reset_handler: FAILED Feb 14 21:54:14 Tower kernel: sd 5:0:3:0: task abort: FAILED scmd(0x000000004a167f29) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: attempting task abort!scmd(0x00000000bf95fe9f), outstanding for 72192 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: [sdb] tag#160 CDB: opcode=0x88 88 00 00 00 00 03 48 e6 4f a8 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:0: handle(0x000b), sas_address(0x4433221103000000), phy(3) Feb 14 21:54:14 Tower kernel: scsi target5:0:0: enclosure logical id(0x500605b001048b70), slot(0) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: No reference found at driver, assuming scmd(0x00000000bf95fe9f) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: task abort: SUCCESS scmd(0x00000000bf95fe9f) Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: attempting task abort!scmd(0x00000000b17000f0), outstanding for 72192 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: [sdc] tag#161 CDB: opcode=0x88 88 00 00 00 00 03 48 e6 4f a8 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0) Feb 14 21:54:14 Tower kernel: scsi target5:0:1: enclosure logical id(0x500605b001048b70), slot(3) Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: No reference found at driver, assuming scmd(0x00000000b17000f0) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: task abort: SUCCESS scmd(0x00000000b17000f0) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: attempting task abort!scmd(0x00000000f8eb2847), outstanding for 70142 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: [sdd] tag#247 CDB: opcode=0x88 88 00 00 00 00 02 ef c6 e7 18 00 00 01 00 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:2: handle(0x000a), sas_address(0x4433221101000000), phy(1) Feb 14 21:54:14 Tower kernel: scsi target5:0:2: enclosure logical id(0x500605b001048b70), slot(2) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: No reference found at driver, assuming scmd(0x00000000f8eb2847) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: task abort: SUCCESS scmd(0x00000000f8eb2847) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: attempting task abort!scmd(0x00000000bc8dfafc), outstanding for 70142 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: [sdd] tag#246 CDB: opcode=0x88 88 00 00 00 00 02 ef c6 e6 18 00 00 01 00 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:2: handle(0x000a), sas_address(0x4433221101000000), phy(1) Feb 14 21:54:14 Tower kernel: scsi target5:0:2: enclosure logical id(0x500605b001048b70), slot(2) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: No reference found at driver, assuming scmd(0x00000000bc8dfafc) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: task abort: SUCCESS scmd(0x00000000bc8dfafc) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: attempting task abort!scmd(0x0000000010fc6b1f), outstanding for 70142 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: [sdd] tag#162 CDB: opcode=0x88 88 00 00 00 00 02 ef c6 e5 18 00 00 01 00 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:2: handle(0x000a), sas_address(0x4433221101000000), phy(1) Feb 14 21:54:14 Tower kernel: scsi target5:0:2: enclosure logical id(0x500605b001048b70), slot(2) Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: No reference found at driver, assuming scmd(0x0000000010fc6b1f) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:2:0: task abort: SUCCESS scmd(0x0000000010fc6b1f) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: attempting task abort!scmd(0x000000009d34caf0), outstanding for 61718 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: [sdb] tag#163 CDB: opcode=0x88 88 00 00 00 00 00 00 01 c1 98 00 00 00 08 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:0: handle(0x000b), sas_address(0x4433221103000000), phy(3) Feb 14 21:54:14 Tower kernel: scsi target5:0:0: enclosure logical id(0x500605b001048b70), slot(0) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: No reference found at driver, assuming scmd(0x000000009d34caf0) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: task abort: SUCCESS scmd(0x000000009d34caf0) Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: attempting task abort!scmd(0x00000000491b1367), outstanding for 61718 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: [sdc] tag#164 CDB: opcode=0x88 88 00 00 00 00 00 00 01 c1 98 00 00 00 08 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0) Feb 14 21:54:14 Tower kernel: scsi target5:0:1: enclosure logical id(0x500605b001048b70), slot(3) Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: No reference found at driver, assuming scmd(0x00000000491b1367) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:1:0: task abort: SUCCESS scmd(0x00000000491b1367) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: attempting task abort!scmd(0x00000000868fe54a), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: [sdg] tag#170 CDB: opcode=0x88 88 00 00 00 00 03 2f 11 4d 68 00 00 00 08 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:5: handle(0x000e), sas_address(0x4433221107000000), phy(7) Feb 14 21:54:14 Tower kernel: scsi target5:0:5: enclosure logical id(0x500605b001048b70), slot(4) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: No reference found at driver, assuming scmd(0x00000000868fe54a) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: task abort: SUCCESS scmd(0x00000000868fe54a) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: attempting task abort!scmd(0x000000002aa71d1e), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: [sdg] tag#169 CDB: opcode=0x88 88 00 00 00 00 01 d1 fb c5 c0 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:5: handle(0x000e), sas_address(0x4433221107000000), phy(7) Feb 14 21:54:14 Tower kernel: scsi target5:0:5: enclosure logical id(0x500605b001048b70), slot(4) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: No reference found at driver, assuming scmd(0x000000002aa71d1e) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: task abort: SUCCESS scmd(0x000000002aa71d1e) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: attempting task abort!scmd(0x000000008cf2aa2f), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: [sdg] tag#168 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 c0 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:5: handle(0x000e), sas_address(0x4433221107000000), phy(7) Feb 14 21:54:14 Tower kernel: scsi target5:0:5: enclosure logical id(0x500605b001048b70), slot(4) Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: No reference found at driver, assuming scmd(0x000000008cf2aa2f) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:5:0: task abort: SUCCESS scmd(0x000000008cf2aa2f) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: attempting task abort!scmd(0x0000000049c7fb2c), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: [sdb] tag#167 CDB: opcode=0x88 88 00 00 00 00 03 2f 11 4d 68 00 00 00 08 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:0: handle(0x000b), sas_address(0x4433221103000000), phy(3) Feb 14 21:54:14 Tower kernel: scsi target5:0:0: enclosure logical id(0x500605b001048b70), slot(0) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000049c7fb2c) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000049c7fb2c) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: attempting task abort!scmd(0x000000008ffdff4a), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: [sdb] tag#166 CDB: opcode=0x88 88 00 00 00 00 01 d1 fb c5 c0 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:0: handle(0x000b), sas_address(0x4433221103000000), phy(3) Feb 14 21:54:14 Tower kernel: scsi target5:0:0: enclosure logical id(0x500605b001048b70), slot(0) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: No reference found at driver, assuming scmd(0x000000008ffdff4a) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: task abort: SUCCESS scmd(0x000000008ffdff4a) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: attempting task abort!scmd(0x00000000025932ab), outstanding for 50176 ms & timeout 30000 ms Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: [sdb] tag#165 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 c0 00 00 00 20 00 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:0: handle(0x000b), sas_address(0x4433221103000000), phy(3) Feb 14 21:54:14 Tower kernel: scsi target5:0:0: enclosure logical id(0x500605b001048b70), slot(0) Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: No reference found at driver, assuming scmd(0x00000000025932ab) might have completed Feb 14 21:54:14 Tower kernel: sd 5:0:0:0: task abort: SUCCESS scmd(0x00000000025932ab) Feb 14 21:54:14 Tower kernel: sd 5:0:3:0: attempting device reset! scmd(0x000000004a167f29) Feb 14 21:54:14 Tower kernel: sd 5:0:3:0: [sde] tag#245 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Feb 14 21:54:14 Tower kernel: scsi target5:0:3: handle(0x000c), sas_address(0x4433221102000000), phy(2) Feb 14 21:54:14 Tower kernel: scsi target5:0:3: enclosure logical id(0x500605b001048b70), slot(1) Feb 14 21:54:44 Tower kernel: mpt2sas_cm0: In func: mpt3sas_scsih_issue_tm Feb 14 21:54:44 Tower kernel: mpt2sas_cm0: Command Timeout

Not exactly the answer you asked for @dlandon, but see my post above. I have run this particular server for 7 years with a good number of Dockers including Tdarr, and have never experienced this issue of losing all shares. However, it then occurred immediately and repeatably when trying to run Unbalance on a large folder of files (with the Docker, Seafile, that created those files stopped). Now that's finished and I've moved the data the server has gone back to being stable. So, yes, it might be a Docker but, if it is, it doesn't show the issue until Unbalance is run as well. Very strange...

Had my first experience of this yesterday and it's completely repeatable. I'm in the middle of consolidating my data disks from 4TB to 8TB drives. As part of this process I've been using Unbalance to move files from old disks to new. This has all been working fine until it came to trying to move my Seafile folder structure. Seafile, if you don't know, stores all files as small chunks and there are millions of these small files in the folder structure - something over 6 million in my case. Very soon after Unbalance enters the planning stage on all these tiny files, the system loses all shares. Only way back is to reboot. I'm not blaming Unbalance at all here, instead I suspect it is something to do with the sheer volume of files that are being opened, the space needed to store that data, or the rate of doing so. I have no hard evidence for which it is, other than this happened every time I tried to use Unbalance on this folder set, and Unbalance handles every other folder on my system with no problems. FWIW - I am now moving the files using rsync from the command line but without the planning step and that seems to be working.

Yes, that included finding and reading the instructions, as well as taking a backup of the flash drive. Oh, and drinking a cup of tea while I plucked up the courage! (The downloading was quick. It’s the unzipping of large layers that takes the time.)

Thought I'd make a positive post for once. Today I had a failure of the Docker BTRFS image. I followed the instructions, shut down Docker, created a new image (actually switched to using a directory rather than an image), and re-installed all Dockers using the Community Applications Previous Apps. It all worked perfectly! 🙂 Back up and running with 27 dockers in about an hour. (I have another system where I manage Dockers using Portainer and it's nowhere near this easy to recover from a problem.) Thanks y'all - have a great New Year!

So far so good. No more call traces! Thank you again for the help.

Thank you for the advice. One of the disks took a long time to get through check filesystem - particularly Phase 3 - so perhaps it had an issue. Now rebooted and seeing what happens.

Hi, Running 6.12.4 and Fix Common Problems is reporting call traces, they look like this: Sep 24 07:15:23 Tower kernel: CPU: 15 PID: 30122 Comm: cp Tainted: P O 6.1.49-Unraid #1 Seems odd that they mention 6.1.49-Unraid when I'm running 6.12.4. Diagnostics attached. I would appreciate help in resolving these. Thanks! tower-diagnostics-20230925-1422.zip

FYI - I shut down Docker service, made the change, and re-enabled Docker but the Docker service didn't start. I had to use the console to force docker start. As an experiment I then tried to start and drop Docker from the GUI again without making any changes. The same thing happened. Docker seems to start fine from command line, but not from GUI. Don't know if this is a bug or just my system? Now running with ipvlan as recommended. Thank you. I believe it already is. br0 has a metric of 1011 and br1 is 1012 in the 'Routing Table' section of Network settings.

Thank you both!

I tried the brute force approach, and restarted the smb service. That seems to have fixed it! 🙂 No ideas why smb fell over, but fall over it did. Strange. So, I'm back running again, no need for urgent help now unless you can help diagnose why smb crashed in the first place. Thanks!

Updated to Unraid 6.12 yesterday. All seemed to be running correctly, however I can no longer access shares from Windows or Linux machines. Tried 4 different Windows computers (3 virtual on 2 separate servers and one bare metal Windows machine), all running Windows 10 and 11 and none of them can access Unraid shares. Same with Linux. The Unraid machine is visible in the Windows Network list, but attempting to access it results in a 'Windows cannot access \\TOWER, Error code 0x80070035 The network path was not found" message. Linux gives me a 'Failed to receive shares list' message. Also tried creating a new connection from Windows using the direct ip address rather than the name, and that doesn't work either. Oddly, although Windows and Linux don't work, I CAN access shares from a Mac. Is there a change in how shares work in 6.12 that would affect connection from Windows and Linux machines? Diagnostics attached. Thank you. tower-diagnostics-20230616-1349.zip

Thank you. What about the more recent entries? They don’t seem to have any detail, are they just repeats of the same?

Got a few MCE errors this last week and I'd appreciate advice on what they might mean. Diagnostics attached. Many thanks. tower-diagnostics-20221025-1152.zip

I have a question about the 'Watched/Unwatched' status in Plex. The 'Unwatched' flag is being reset in Plex for Movie encodes, but not for TV encodes. I would like to stop it happening for movies too but can't figure out why it is happening. I have the Tdarr plug in that keeps the file date unchanged and I also have the ' Empty trash automatically after every scan' option turned OFF in Plex library scans which I had thought was the solution to this problem. Does anyone know how to fix this?

Yes! Now starts up in a couple of seconds again. Thank you. 🙂

This is almost identical to my log except I have q slightly longer 13 second delay between 'POST RETURN (getFavourite)' and 'POST RETURN (get_content)'. Log attached. Also, yes, I do have a number of Dockers with the '?' icon, but they are my own dockers which have no other defined icon and deliberately use '/plugins/dynamix.docker.manager/images/question.png' CA-Logging-20211020-1450.zip

I am seeing the same. CA used to load in a couple of seconds, now it takes 18 seconds. Nearly as long as the Plugin page which has always been slow. This is in Unraid 6.9.2. Also on a 1Gb connection using SSD.

All worked this time, thank you. BTW I wasn't able to both remove parity2 and replace parity1 in one operation. Unraid complained that was too many changes. Took two steps, but all is fine. Thanks everyone for your help! 🙂

Thank you @itimpi, that’s helpful. Yes, I am currently running a parity check with the old drives. It found a lot of errors not surprisingly. 🙂 I also managed to trace the original problem back to a cable (isn’t it always) which triggered CRC errors causing Unraid to disable the drive. I now don’t believe there was an actual disk failure at all. It was a train of issues caused by the cable failure. That triggered the CRC failures which caused Unraid to mark the drive disabled, which, in turn, caused everything else to fail. Unraid behaved as it should with one exception I believe. It shouldn’t have then locked up the GUI so that I was unable to get in to fix anything. Assuming this parity check finishes in an hour as scheduled, I have two questions please: 1. General question - when a parity check fixes errors I assume it does so by changing the parity drive, not by changing the data drives. Is that correct? 2. When I build up the courage to try this again can you confirm that I am following the right procedure to replace dual parity 4TB drives with a single parity 8TB drive? (So I can in the future replace some of my 4TB data drives with 8TB versions.) a. Stop array and remove 2nd parity drive from configuration b. Restart array c. Stop array and replace 1st parity drive with new 8TB drive d. Restart array and rebuild parity onto new 8TB drive (this is where I had the failure last time) e. Stop array and assign the two old 4TB parity drives as new data drives f. Restart array g. Sleep peacefully.

We're back. I went to Tools/New Config and reassigned everything back as it had ben in the first place, with the two original parity drives and removed the new 8TB drive. I then checked the "Parity is already valid" checkbox, crossed my fingers, and started the array. So far, so good, I think everything is working again. That was pretty scary. The GUI was frozen, and nothing was working. I had to boot into Safe Mode to get anything going again.

Server very dead, would appreciate help. I think it’s recoverable but I don’t know how. Here's what happened. 1. All running fine. Using 2 x 4TB parity disks and 7 x 4Tb data disks. 2. Need to increase size so add new 8TB disk with intention of this becoming new parity disk. 3. Stop array and disable parity disk 2 4. Start array with one 4TB parity disk 5. Stop array and designate 8TB disk as new parity disk (replacing 4Tb drive) 6. Start array. Parity rebuild automatically restarts. Life is good. 7. A few hours in to the parity rebuild, errors show up on disk 6 and parity rebuild fails. I still have the original 2 parity disks in the system as unassigned devices and untouched. Can I reassign them as the parity and rebuild the data on the now failed disk? As it is the whole array is stalled. 😞

And he has! 😃 Thanks Squid, all your hard work is much appreciated.