Optimus Prime

Before rebooting into Safe Mode, I completed a command-line non-correcting parity check successfully using: mdcmd check NOCORRECT That check completed with: sbSyncErrs=0 sbSyncExit=0 mdResyncCorr=0 all rdevNumErrors=0 I have attached the diagnostics file from after the successful CLI parity check, which shows the server in a good state after that run. Diagnostics zip attached for the good state: fileserver-diagnostics-20260616-1900.zip The issue previously reproduced when starting what I believed was a non-correcting parity check from the GUI. In those cases, the syslog showed mdcmd: check correct, and the check would hang at mdResyncPos=0. When the system was in that hung state, I was also unable to complete a GUI-initiated diagnostics collection. I then booted into Safe Mode and started a non-correcting parity check from the GUI. This time, the GUI did appear to start it as non-correcting: mdcmd (36): check nocorrect mdResyncCorr=0 However, it immediately hung at: mdResyncPos=0 mdResyncDb=0 The diagnostics show a kernel oops right after starting the Safe Mode GUI parity check: Oops: general protection fault RIP: raid6_avx21_gen_syndrome+0x80/0x110 Call trace includes: check_parity+0x204/0x360 [md_mod] unraidd+0xedf/0x1280 [md_mod] md_thread+0xf6/0x130 [md_mod] I also attempted diagnostics while the system was in this state. The GUI-initiated diagnostics did not complete. Running diagnostics from the terminal eventually produced: /boot/logs/fileserver-diagnostics-20260616-2042.zip However, while diagnostics was running, ps showed it blocking at: /sbin/btrfs filesystem show /dev/nvme0n1p1 with btrfs processes in D state, including get_active_stripe / folio_wait_bit_common, and mdrecoveryd also in D state at get_active_stripe. fileserver-diagnostics-20260616-2042.zip fileserver-diagnostics-20260616-1900 (ran via terminal).zip

I have a new data point: When I try to start a non-correcting parity check through the GUI, nothing appears to happen. When I look at the logs, it shows a correcting parity check started, but it just hangs; the date/time stamp shown in the GUI updates, re-reports the same time and speed as the previous check, and I have to do a hard restart. Last night, I started a non-correcting parity check using the terminal. It is progressing as expected. And the GUI is reflecting that progress. That does not seem like a microcode issue to me. I'm still going to try and replace the CPU under warranty, but I think the issue is lying elsewhere. It would be helpful to have more dieas and consideations while I build the backup server. ' I'd like y'alls thoughts on this.

Actually, I'm thinking about temporarily moving the array from the new machine to an older machine while I deal with replacing the CPU. Updated migration summary Back up the flash drive. Disable Docker and VMs. For every cache-only share, change storage so it can move to the array. Set mover direction to Cache → Array. Run Mover. Verify the cache pool is empty or only has irrelevant leftovers. Confirm the shares now live on the array. Power down cleanly. Move the array data disks and parity disks to the new server. On the new server, assign only the moved data disks as data disks. Do not format anything. Leave the parity disks unassigned initially. Start the array and verify the shares/files. After verification, assign the old parity disks as parity disks. Build parity or run a parity check After machine is fixed, move back into the new machine, then the older machine becomes my backup server Thoughts?

That's a bummer. To start a warranty claim, you have to have the batch number from the CPU, which is only printed on the CPU. Before I pull this out of the rack and disassemble it, I figured I'll just use an older machine and temporarily replicate it to an older machine. I don't care about anything in particular on this machine except my Immich Docker, the Immich_PostgreSQL docker and my Valtwarden Docker. Plus some specific folders on my shares Is there a way to just "replicate" a system to a new machine? Although in this instance, it'll just be to a single 10TB or 12 TB hardrive without a parity array? I

@itimpi and @JorgeB , thank you for your feedback. Quick update: • I rebooted and captured fresh diagnostics with the array currently not started/offline. I’ve attached the new diagnostics ZIP. • I also ran two full cycles of Memtest86+ v6.2 with no errors, and confirmed the motherboard BIOS is on the latest version available for my board that addresses the Intel 13th/14th gen microcode issue. For context, after applying that BIOS/microcode update in June of 2025, I have since completed two parity checks over the last year without issue. This current failure seems new. The prior diagnostics appeared to show the crash immediately after starting parity check, with the general protection fault in: raid6_avx21_gen_syndrome -> check_parity -> unraidd Given the clean memtest, current BIOS, and the fact that the last two parity checks completed successfully, is there a way to better confirm whether this is actually the 14600K / Intel CPU issue versus another hardware or Unraid/kernel issue? For now, I’m sitting rebooted with the array offline and have not started another parity check. fileserver-diagnostics-20260614-1533.zip

I started a fresh parity check again, and it has stalled again. Disgnotstics attached. fileserver-diagnostics-20260613-2119.zip

Thank you for that suggestion. I’ll give it a try and report back.

Thank you. I'll run a parity check again, and then, assuming it does not crash this time, I'll reinstall the tuning plugin and try again.

Thank you. I'll interpret this as answering the question "Should I be safe to begin parity checks again?". Thank you for the response. I'll work on this again after work and report back

Aggregating this back to the top. Has anyone found a way to connect the forums to ChatGPT or other web-based LLM so we can query against the forums before posting new threads?

Hi all — I’m looking for help diagnosing a parity check crash/stall on an existing Unraid 7.1.4 install. Diagnostic file attached. My issues started after I configured the parity tuning plugin to perform a check on 6/3. I was under the impression it would pause when mover ran several hours later, then would pick up again later. I ended up with what appeared to be a mover constantly crashing/stalling, immich was stuck, and the nightly email notice I get was giving weird numbers saying it completed the parity check in only a few minutes. I could not stop the array and had to do a hard reset. I seem to be stable now. My questions are: Should I be safe to begin a parity check again? How do I set the tuning so I can schedule a parity check to run automatically once a month and not worry about the mover getting in the way? Thanks for your help. Full disclosure, below is a summary from my ChatGPT once it finally got stable again. Quick recap: this is an existing Unraid 7.1.4 install with dual parity. The array is currently started, mounted, and usable, with sbSyncErrs=0 and no active parity check progress. The problem began after I configured scheduled/partial parity checks using the Parity Check Tuning plugin. A correcting dual-parity check started and repeatedly crashed/stalled immediately at mdResyncPos=0, with the syslog showing Oops: general protection fault in raid6_avx21_gen_syndrome, followed by check_parity and unraidd0 exited. I removed the Parity Check Tuning plugin, disabled scheduled parity checks, confirmed that no active cron parity checks remain, and the array is now stable. However, I have not attempted another parity check because I do not want to re-trigger the crash. I’m looking for guidance on whether these points point to an Unraid/kernel RAID6 issue, hardware/CPU/RAM issue, or leftover parity state, and what the safest next step is. System / context Unraid version: 7.1.4 Kernel shown in logs: 6.12.24-Unraid Dual parity array: parity + parity 2 Largest disk / parity size: 12 TB Array currently starts and is usable Current status shows no active parity check and no sync errors: sbSyncErrs=0 mdState=STARTED mdResyncAction=check P Q mdResyncSize=11718885324 mdResyncCorr=0 mdResync=0 mdResyncPos=0 mdResyncDt=0 mdResyncDb=0 The mdResyncAction=check P Q label appears stale because mdResync=0, mdResyncPos=0, mdResyncDt=0, and mdResyncDb=0. What happened This started after I configured scheduled/partial parity checks using the Parity Check Tuning plugin. During/after that process, a correcting dual-parity check started and immediately crashed/stalled. The first failure showed the parity check starting and then crashing in the RAID6 parity code: mdcmd: check correct md: recovery thread: check P Q ... Oops: general protection fault RIP: raid6_avx21_gen_syndrome check_parity+0x204/0x360 [md_mod] unraidd+0xedf/0x1280 [md_mod] note: unraidd0 exited After that, Unraid showed the check stuck at zero progress: mdResyncAction=check P Q mdResyncCorr=1 mdResyncPos=0 mdResyncDt=... mdResyncDb=0 The array could not be stopped cleanly from the GUI; Stop was greyed out or the array stayed stuck stopping. A normal reboot did not complete, and I had to reboot using SysRq/physical reboot. Troubleshooting performed Captured diagnostics and syslogs before rebooting. Removed the Parity Check Tuning plugin. Booted into Safe Mode with GUI. Even in Safe Mode, the parity check state came back as correcting/stuck: mdResyncCorr=1 mdResyncPos=0 Rebooted again. Now in normal mode, the array starts and is stable. Current status is: sbSyncErrs=0 mdState=STARTED mdResyncAction=check P Q mdResyncSize=11718885324 mdResyncCorr=0 mdResync=0 mdResyncPos=0 mdResyncDt=0 mdResyncDb=0 Parity Check Tuning appears removed: ls -lah /boot/config/plugins | grep -i parity returned nothing. Built-in scheduled parity check cron was removed after disabling scheduled parity checks: cat /boot/config/plugins/dynamix/parity-check.cron cat: /boot/config/plugins/dynamix/parity-check.cron: No such file or directory Active crontab does not show any parity/mdcmd check job: crontab -l | grep -iE "mdcmd|parity|NOCORRECT|check" returned nothing. dynamix.cfg currently shows: [parity] write="NOCORRECT" Current state The array is currently usable and mounted: /mnt/user mounted /mnt/disk1 mounted /mnt/cache mounted I am avoiding any manual parity check for now because the prior attempts repeatedly crashed at: raid6_avx21_gen_syndrome check_parity unraidd0 exited Question What is the recommended next step? Specifically: Is this likely an Unraid/kernel RAID6 parity calculation issue, a plugin-triggered issue, or a hardware/CPU/RAM issue? Is there a safe way to clear the stale mdResyncAction=check P Q label/state while mdResync=0? Should I try a non-correcting parity check again, or avoid parity checks until further guidance? Are there specific BIOS settings, CPU features, RAM tests, or Unraid settings I should check given the crash is in raid6_avx21_gen_syndrome? Since this was the original install, I do not have a prior Unraid version available to roll back to. Is there a recommended version to install/upgrade/downgrade to for this issue? Diagnostics zip attached. fileserver-diagnostics-20260610-2036.zip

Hey gang. Just got back into town. Thought I would bubble this up to the top in case anyone could share their experience. Thanks for your feedback.

I have an ISP provided router without a native tailscale plugin or client. I have a personal travel router that does have Tailscale client. I’d like everything that connects to the travel router to not have to worry about the Tailscale or magic DNS addresses. I’m finding conflicting information that says I should I adjust settings in the Tailscale plug-in to do the announcements and other information that says I should do it through a docker container. Could someone help put me in the right direction? I currently have Tailscale routing set up for my personal devices and all my existing docker containers on Unraid. So I’m OK with the general set up to get going. It’s just this next configuration part that I’m a little lost on. Thank you for your feedback

Thank you for putting this Docker together. I've been using the Windows version for years. Would anyone know how to activate the email notifications and p[performance improvements we earn from our donations to the FreeFileSync project?

ach time I enter a forum, I have to separately advance to the last page to see the latest threads. Is there a way for me to set threads always to show me the latest first? Sorry if I'm missing this and it's in plain sight...

Thank you for the feedback. Sent you a beer...headed over to Readarr...but just saw the note it's being retired...let us know if you invest time in another ebook app...

Moving on to DNS leaks Home IP: xx.xxx.xxx.xxx curl ifconfig.io: 62.93.178.175 (VPN IP) dig @resolver1.opendns.com 208.69.35.169 (External DNS resolver IP) Neither of these is my home IP address. Since the binnex-qbitorrentvpn container is reporting back that OpenDNS sees a different address than one provided by PIA, does this indicate a leak to be concerned about?

Thanks for talking it through...

Yes it is...but I just noticed that my Eero has started also handing out 192.168.5.0 range as well...is there a setting on the unraid server or in the container I should use to allow it to accept the .5 addresses as well? Edit: I just added the .5 range to the Variable Lan variable and it seems to be working now

Here's an interesting observation. When I am accessing the WebUI directly via my personal laptop, I seem to have no issue connecting. However, when I switch over to my work laptop and RDP into the personal laptop, the WebUI will not resolve. I have no issue with any of my other services or dockers. It's just the binhex-qbitorrentvpn So I just tested...the issue is when my laptop is connected via the WiFi...or any device in the house trying to resolve the WebUI via Wifi. It just doesn't work. Only hardwired devices, my work laptop included, can resolve the WebUI. If I switch either the personal laptop or work laptop to WiFi, they can no longer load the WebUI.

Thanks for mentioning this...files attached for whoever could have a look. docker_run.txt supervisord.log command execution log.txt

Good morning all. Last night I could resolve the WebUI. Woke up this morning and I can no longer access it. Is anyone else having an intermittent issue with the WebUI?

I am following this...I finally have Sonarr managing moving my files and the removal of the torrent, but I still have Filecopy instead of hardlinks.

Update #2: I sat down at my computer and the Web UI was working...dunno why. Maybe there was an issue with PIA? Would anyone know why if I'm using the default Netherlands endpoint in the conf file, its always an endpoint other than the Netherlands? Currently, I'm in an asian pacific IP address when I use IP Leak test.

Thank you. Neither downgrading nor upgrading resolved my inability to access the web UI. Attached are the log files. Thank you for having a look. Update: I was able to log in after disabling the VPN...but now I'm stuck wondering what happened between last night and when I woke up this morning. Thanks again for having a look supervisord.log command_execution.txt