JorgeB

You did, but there were read errors on disk1 during the sync, so parity isn't 100% valid, you can still rebuild but there will likely be some data corruption, except if you are very lucky and the read errors coincided with empty disk space, or use ddrescue, this way you can at least now with files are corrupt, another alternative is to copy the data form disk1 to another disk, any files that you can't copy need to be restored from backups.

It's not easy to diagnose hardware without starting to swap some things around, like PSU, board, RAM, etc, one more thing you can try before that is to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it basically points to a hardware problem, if it doesn't start turning on the other services one by one.

Possibly this: https://forums.unraid.net/bug-reports/prereleases/69x-610x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-r1674/?do=getNewComment&d=2&id=1674

No, that's how it should be, something you did/ran changed that.

/mnt/user permission are wrong, type: chmod 777 /mnt/user then post output of ls -ail /mnt

System share has some files on disk1, and it's completely full, if the docker image is there it won't have enough space for writes.

Like mentioned you have errors on multiple disks, disk1 isn't the problem, at least not for now Jan 25 16:21:48 Apollo kernel: md: disk1 write error, sector=273781944 .. Jan 25 16:22:35 Apollo kernel: md: disk3 read error, sector=3558475008 .. Jan 25 16:23:02 Apollo kernel: md: disk6 read error, sector=273783216 .. Jan 25 16:23:26 Apollo kernel: md: disk2 read error, sector=273782224 .. Jan 25 16:23:41 Apollo kernel: md: disk4 read error, sector=273786064 .. Jan 25 16:24:27 Apollo kernel: md: disk5 read error, sector=273785856

Check filesystem on disk1, make sure you run xfs_repair without -n or nothing will be done.

This is what I would do.

I forgot that reiser is limited to 16TiB max size, so you'll need to go back to the old disk, convert to xfs, then you can upgrade again.

That seek error rate failing now SMART is kind of common with those drives, and it usually goes way on its own, main issue is that the extended SMART test is failing, might or not be related to that, you can run a non correcting check, if there aren't any errors and the SMART failing now attribute goes away after a power cycle or a few days and the SMART extended test no longer fails I would probably keep them for now.

Reiserfs can take a long time to mount, hours even for large filesystems, when there are issues or it's replaying the journal.

That suggests a plugin issue, safe mode by itself shouldn't make any different for this.

It will affect any Linux based system, not just Unraid.

The 840 EVO can turn slow reading old data, especially if not using the latest firmware, run the diskspeed docker to test read performance in all devices.

Yes, but two ports on the board are from an Asmedia controller, other ones use the Intel PCH controller. Both emulated disks are mounting so you can rebuild on top, though it should be fairly safe if you have spares you can use those instead and keep the old disks in case something goes wrong. https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

This is the wrong forum for this, it's for running Unraid as a VM, also already replied in your other thread:

Both disks dropped offline, and they are on different controllers, this suggests a power/connection problem, power down, check/replace cables, power back up and post new diags after array start.

Not much to go on with the call trace posted, one thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

That CPU, as most Xeon CPUs, doesn't appear in the board compatibility list, make sure you have the latest BIOS, still it might not work correctly, and it probably won't.

Once the rebuild finishes check filesystem on that disk. P.S. reiser is not recommended for a long time, you should convert all disks to xfs.

Please post the complete diagnostics.

Thinking about it, I believe there were some changes to UD and it might not allow mounting a former array device like that, if it doesn't leave them assigned and try to mount them manually read-only with the array stopped, like so: mkdir /x mount -v -o ro /dev/sdX1 /x Replace X with correct disk letter, if the disk mounts browse /x to check contents, if it doesn't post the output of the mount command. In the end to unmount use: umount /x

Do what I mentioned, with the array stopped unassign one or both disks that give you the invalid partition error and see if they mount with UD, best to activate read-only mount option in UD to keep parity in sync, if it still is.

Jan 25 16:22:03 Apollo kernel: ata5: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata5: hard resetting link Jan 25 16:22:03 Apollo kernel: ata9: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata9: hard resetting link Jan 25 16:22:03 Apollo kernel: ata1: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata1: hard resetting link Jan 25 16:22:03 Apollo kernel: ata10: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata10: hard resetting link Jan 25 16:22:03 Apollo kernel: ata2: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata2: hard resetting link Jan 25 16:22:09 Apollo kernel: ata10: hard resetting link Jan 25 16:22:09 Apollo kernel: ata1: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:14 Apollo kernel: ata1: hard resetting link Jan 25 16:22:14 Apollo kernel: ata2: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:19 Apollo kernel: ata2: hard resetting link Jan 25 16:22:19 Apollo kernel: ata9: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:24 Apollo kernel: ata9: hard resetting link Jan 25 16:22:24 Apollo kernel: ata5: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:29 Apollo kernel: ata5: hard resetting link Jan 25 16:22:30 Apollo kernel: ata5: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:35 Apollo kernel: ata5: hard resetting link Jan 25 16:22:35 Apollo kernel: ata9: softreset failed (1st FIS failed) Jan 25 16:22:35 Apollo kernel: ata9: hard resetting link Multiple disk issues, could be a controller, power or connection problem.