JorgeB

Thanks for the detailed captures. They make this much easier to look at. I agree with your reading. The scanner thread is stuck inside the kernel's memory-management code during munmap(), and the rest follows from that. Anything that reads that process's /proc/<pid>/environ or cmdline (ps, pgrep, and the WebGUI's own process checks) blocks behind it, so the PHP workers pile up and the WebGUI stops responding. The process can't exit, so the array can't unmount cleanly. That is why the first powerdown -r doesn't finish and a parity check runs after the reboot. Plex only triggers it. Userspace should not be able to leave a task in that state. From the diagnostics, I don't see a hardware angle. Microcode is 0x133 (current for Raptor Lake), and the syslog has no MCE/EDAC or other kernel warnings. Other users also report the same stack on WSL 6.18.x kernels on different hardware. 1. I don't have a confirmed upstream fix for this specific signature yet. 7.3.3-rc.2 uses Linux 6.18.52. If you're OK with running a release candidate, it would be a useful comparison, since it includes many mm fixes after 6.18.38. Please keep in mind that it may not fix this. If you test it, it would be best to turn credit detection back on at some point, because otherwise we can't tell whether the kernel or the workaround made the difference. 2. I'll pass on the hung-task detector request. It would only make the kernel log the stall automatically. It would not prevent it. For now, keeping credit-marker generation off is a reasonable workaround. If it happens again, before rebooting please run echo w > /proc/sysrq-trigger, which writes the stacks of all blocked tasks to the syslog even without the hung-task detector, and then grab diagnostics. Also note the kernel version and whether credits were enabled.

Thanks for posting both sets of diagnostics. They tell us much more this time. The hardware error came back. It's the same error we saw on September 28, from the same CPU core, with exactly the same values. This happened even after the BIOS update, which also updated the CPU microcode. I also see you removed the SAS card, and passed a 22-hour memory test. So the most likely cause is now the CPU itself, specifically one of its cores. I can't prove that from the logs alone. A different CPU is the test that would confirm it. What I recommend: 1. If your 5950X is still under warranty, contact AMD support about a replacement. Tell them the system has repeated "machine check" errors on the same core at stock settings. If it's not under warranty, try a different AM4 CPU if you can borrow one, or replace it. 2. Until then, keep the server off, or use it as little as possible. Every crash restarts the parity build and risks damaging the boot USB again. 3. Don't add the new drives yet. I know that's frustrating, but it's the safest thing for your data right now. Why your settings changed: Because of all the forced restarts, the files on your boot USB were damaged. Unraid repaired the USB when it started, but some settings files were lost in the repair. That's why the server name, theme and disk assignments went back to the defaults. Your reassignment matches the original slots exactly, so you did that correctly. Your data disks look healthy. When the server is on, please fix these: - Settings → Identification: set the server name back to what it was. - Settings → Date and Time: set the time zone to Tokyo again, and enable NTP so the clock stays correct. - Settings → Display Settings: set the theme you prefer. - On the Main page, click your boot USB and use Flash Backup. Keep the backup file safe on your PC, and make a new one after any settings change. - You can delete the files named FSCK0000.REC to FSCK0006.REC from the boot USB. They are only leftovers from the repair. When you have a replacement or test CPU installed, let the parity build finish and post new diagnostics. We can go from there.

The diagnostics show that disk1 is the only problem. The disk looks healthy, but its filesystem superblock is damaged: XFS (dm-0): Metadata CRC error detected at xfs_sb_read_verify ... SB validate failed with error -74 SMART is OK, there are no disk errors in the log, and the disk is not disabled. This is most likely damage from the crash or power problem, and it can usually be fixed with xfs_repair. The files you are missing are most likely on disk1. They are not visible in the shares because the disk does not mount. The missing Docker containers are a different problem: they are from the flash corruption. Since your appdata is still there, you can reinstall them with the same settings using Apps > Previous Apps. First, replace that splitter. Do not use the GUI's Format option on disk1, because formatting would erase it. Then check the filesystem on that disk.

It may be easier/faster to just use another one, but you can file a report below, mentioning the support link for that container isn't valid: https://product.unraid.net/b/community-apps-submission-support

Please post the diagnostics.

The problem is that both onboard NICs on this board report the same MAC address. You can see it in the syslog: the Intel I225-V and the Intel I219-V show an identical MAC when they're detected. Unraid names its network interfaces by MAC address, so both NICs try to take the same name. One of them fails to rename (rename_eth121 ... File exists) and there's no eth0 at all. The Network Settings page applies to eth0, so Apply does nothing and the page goes back to the old values. That's also why the MAC address field is blank. This probably explains the network trouble you had with this board before too. To fix it: 1. In the BIOS, disable the onboard NIC you don't use. Your cable is in the 2.5G Intel I225-V port, so disable the 1G Intel I219-V. 2. Shut down, put the flash drive in another computer, and delete (or rename) these two files: config/network-rules.cfg and config/network.cfg. 3. Boot again. Unraid will create new network settings with one NIC as eth0, using DHCP. Check your router for the IP it gets, or look at the local console. 4. Then set your static IP, gateway, and DNS under Settings > Network Settings, and check that they save. For DNS, use your router or a public DNS server. Don't use a DNS server that ran on one of the old servers. If you need both onboard ports, the duplicate MAC has to be fixed on the board itself. A BIOS update might do it (you're on P1.40), or ask ASRock. Unraid can't reliably manage two NICs that share one MAC. If you still have no internet after this, please post new diagnostics.

Thanks, this narrows it down. Your UniFi LAN gateway sends a large discovery query at 13:09:06 and again at 13:10:06. Both request SSH, SFTP, SMB, and device-info, the services listed in the Avahi warnings. Similar queries also appear from the VLAN gateway addresses, which suggests mDNS forwarding. These packets do not need to originate from containers on Unraid. The gateway queries are the strongest lead. However, we need syslog from the same capture period to confirm the connection. Could you temporarily turn off UniFi’s mDNS Proxy, then watch the syslog and repeat the capture for about three minutes? Record the original setting first. Restore it afterward and check whether the warnings return. Leave Roon and Avahi running during this comparison. This can temporarily interrupt device discovery across VLANs, including AirPlay, Chromecast, and printers. Please also provide your UniFi Network version, gateway software version, and current mDNS Proxy mode. If the large queries continue with proxying disabled, we can investigate gateway discovery separately.

That suggests disk8 was formatted outside Unraid with some experimental feature; post the output from: xfs_info /mnt/disk8

The root cause has been found, see my last reply here: https://product.unraid.net/p/7-3-0-removed-zoneinfo-entries-break-existing-timezone-selection

Most definitely, or another hardware issue. If it were an unload issue not giving the correct key, both pools would fail to unlock.

Do not format the drive again. Your diagnostics show these errors before the filesystem mount attempt: No key available with this passphrase. hdd: Wrong encryption key The HDD remains locked, so ZFS cannot read the filesystem inside it. This explains the later “wrong or no file system” message. The same supplied key successfully unlocks your NVMe pool. Was the HDD formatted with the same passphrase or key file? Do you enter it manually after startup, or does a script or plugin supply it automatically? Unraid expects one shared key for all encrypted drives. Please describe how you supply the key, but do not post the passphrase or key file. If you are certain the original credential is unchanged, we can investigate why the HDD rejects it. The diagnostics do not yet establish that power loss damaged the filesystem. If you use the exact same passphrase or key file and it sometimes works but sometimes fails, an intermittent hardware problem, such as faulty RAM, is another possibility. I have seen that cause this behavior before. In that situation, a memory test would be a useful next step.

Thanks for the diagnostics. These messages mean that Avahi cannot fit all the service-discovery records into a legacy unicast reply. This also happens over IPv4, so disabling IPv6 does not prevent it. Your logs show bursts about once per minute, which suggests a device or application is repeatedly querying the server. The log filesystem is currently only 6% used. To help identify the sender, run this in the Unraid terminal while the warnings occur: tcpdump -pni br0 -nn -vv 'udp dst port 5353 and not udp src port 5353' Let it run for about two minutes, then press Ctrl+C. Which device owns the source IP that repeats around the warning times? If you need help interpreting the output, post a few matching lines with addresses and hostnames replaced by consistent labels. I recommend identifying that sender before disabling Avahi, since Avahi provides network service discovery.

Your diagnostics show repeated errors for a missing Docker icon (question.png), which are filling the log filesystem. This matches a known issue fixed in Unraid 7.3.3-rc.2. Please update to 7.3.3-rc.2 and reboot to apply it. If log usage continues to rise afterward, please attach fresh diagnostics before rebooting again.

Please post the diagnostics.

Parity also failed a SMART test, and has a lot of bad sectors, so it needs to be replaced as well.