Dear Community,

my unraid server keeps on hanging for every 8 hrs since I migrated to version 7.x.

Version 6.x had no issues at all.

I already changed USB ports, swapped Flash Drive and moved to ipvlan.

Server memory test was OK.

I would appreciate it if you have any ideas about how to get back to a reliable system.

syslog syslog-previous

Does downgrade OS get you back to working? Possibly consider a lesser upgrade, 7.0.1 seems to have less complaints than other 7.x versions.

1 hour ago, hstone said:

moved to ipvlan

That no longer an issue since 6.12.11

Assuming the syslog-previous covers a crash, there's nothing relevant logged, post the full diags mostly to see the hardware, you can also downgrade to the previous known good release and confirm if it's still stable there.

Currently, my Unraid System has no internet access. Seems to be stable now.

I have no idea, if this is a coincidence or a hint as to where to search for the problem.

The syslog appears to note corruption on disks 10, 12, and 13 if what this log says is true:

Jun 27 10:09:48 store emhttpd: mounting: disk10 devices: 1 slots: 1 missing: 0
Jun 27 10:09:48 store emhttpd: shcmd (113): mount -t btrfs -o noatime,nodiscard,space_cache=v2 -U 287c07fc-9c47-4ba9-a1d5-f887f5c4877d /mnt/disk10
Jun 27 10:09:48 store kernel: BTRFS: device fsid 287c07fc-9c47-4ba9-a1d5-f887f5c4877d devid 1 transid 19391 /dev/md10p1 (9:10) scanned by mount (7833)
Jun 27 10:09:48 store kernel: BTRFS info (device md10p1): first mount of filesystem 287c07fc-9c47-4ba9-a1d5-f887f5c4877d
Jun 27 10:09:48 store kernel: BTRFS info (device md10p1): using crc32c (crc32c-intel) checksum algorithm
Jun 27 10:09:48 store kernel: BTRFS info (device md10p1): using free-space-tree
Jun 27 10:09:48 store kernel: BTRFS info (device md10p1): bdev /dev/md10p1 errs: wr 0, rd 0, flush 0, corrupt 13, gen 0
...
Jun 27 10:10:15 store emhttpd: mounting: disk12 devices: 1 slots: 1 missing: 0
Jun 27 10:10:15 store emhttpd: shcmd (119): mount -t btrfs -o noatime,nodiscard,space_cache=v2 -U 72b7c53d-d1c3-48e9-acf7-b36462bfbad8 /mnt/disk12
Jun 27 10:10:15 store kernel: BTRFS: device fsid 72b7c53d-d1c3-48e9-acf7-b36462bfbad8 devid 1 transid 18928 /dev/md12p1 (9:12) scanned by mount (7957)
Jun 27 10:10:15 store kernel: BTRFS info (device md12p1): first mount of filesystem 72b7c53d-d1c3-48e9-acf7-b36462bfbad8
Jun 27 10:10:15 store kernel: BTRFS info (device md12p1): using crc32c (crc32c-intel) checksum algorithm
Jun 27 10:10:15 store kernel: BTRFS info (device md12p1): using free-space-tree
Jun 27 10:10:16 store kernel: BTRFS info (device md12p1): bdev /dev/md12p1 errs: wr 0, rd 0, flush 0, corrupt 5, gen 0
...
Jun 27 10:10:21 store emhttpd: mounting: disk13 devices: 1 slots: 1 missing: 0
Jun 27 10:10:21 store emhttpd: shcmd (122): mount -t btrfs -o noatime,nodiscard,space_cache=v2 -U 3f9fdf50-4ac2-4730-98e6-7a7d1fb69c81 /mnt/disk13
Jun 27 10:10:21 store kernel: BTRFS: device fsid 3f9fdf50-4ac2-4730-98e6-7a7d1fb69c81 devid 1 transid 42382 /dev/md13p1 (9:13) scanned by mount (7988)
Jun 27 10:10:21 store kernel: BTRFS info (device md13p1): first mount of filesystem 3f9fdf50-4ac2-4730-98e6-7a7d1fb69c81
Jun 27 10:10:21 store kernel: BTRFS info (device md13p1): using crc32c (crc32c-intel) checksum algorithm
Jun 27 10:10:21 store kernel: BTRFS info (device md13p1): using free-space-tree
Jun 27 10:10:21 store kernel: BTRFS info (device md13p1): bdev /dev/md13p1 errs: wr 0, rd 0, flush 0, corrupt 5, gen 0

You should scrub those disks to see if any files are corrupt, if there are, they should be listed on the syslog, this is most often the result of bad RAM.

After changing the BIOS setting "Enable Windows 8 Compatibility" to "false" and revertin to MCVLAN the system is now running about 14 hrs without crash.

Awaiting scrub results of disks 10, 12, and 13.

On 7/2/2025 at 8:38 AM, JorgeB said:

You should scrub those disks to see if any files are corrupt, if there are, they should be listed on the syslog, this is most often the result of bad RAM.

I recently made a Mainboard RAM test. All OK.
Monthly scrub shows no errors. I started a manual scrub today.

I strongly believe that the power supply is causing the issue. I need to purchase a stronger one. I'll will keep you posted as soon as I have changed and tested it.