JorgeB

Like mentioned I already split your post, no need for a new thread, continue here:

The error is not helpful, old bug, but like itimpi mentioned you can't add parity and a data drive at the same time.

There was recently another user with an MX500 that kept dropping out on an LSI, user solved the issue by connecting it to one of the onboard SATA ports.

Split to a new topic since it has nothing to do with the one where you posted on. Make sure mover logging is enable (Settings -> Scheduler), run the mover and post the diagnostics: Tools -> Diagnostics

Delete/rename network.cfg and network-rules.cfg both on flash/config, then reboot and post new diags to see if you get an IP leased from the router.

Syslog is flooded with errors from an NTFS unassigned disk, can't see anything else, you need to run chkdsk on that disk.

Please post the diagnostics: Tools -> Diagnostics

Marvell controllers have various known issues, and are not recommended, but this can sometimes help: https://forums.unraid.net/bug-reports/stable-releases/disks-missing-after-upgrading-to-670-r536/?do=findComment&comment=4583

If the RAM wasn't overclocked it would be a good idea to run memtest, server crashing can corrupt the filesystem, but not corrupt the data, that suggests there's some hardware problem, like bad RAM.

This usually means there's a hardware problem, like bad RAM, you can try xfs, it's more robust, but if there are RAM errors it will still corrupt data.

SSD is dropping offline, then it was reconnected with a different identifier, hence the duplicate UUID error: Apr 2 18:44:31 R720XD kernel: sd 1:0:9:0: TARGET RESET not supported Apr 2 18:44:31 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 Controller reset is requested due to IO timeout Apr 2 18:44:31 R720XD kernel: SCSI command pointer: (00000000b785f23b) SCSI host state: 5 SCSI Apr 2 18:44:31 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 megasas: RESET cmd=28 retries=0 Apr 2 18:44:31 R720XD kernel: megaraid_sas 0000:03:00.0: megasas_wait_for_outstanding:2723 no more pending commands remain after reset handling. Apr 2 18:44:31 R720XD kernel: megaraid_sas 0000:03:00.0: reset successful Apr 2 18:44:31 R720XD root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token ### [PREVIOUS LINE REPEATED 1 TIMES] ### Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: Device offlined - not ready after error recovery Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 Sense Key : 0x2 [current] Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 ASC=0x4 ASCQ=0x2 Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: [sdk] tag#13 CDB: opcode=0x28 28 00 00 00 01 00 00 00 20 00 Apr 2 18:44:41 R720XD kernel: print_req_error: I/O error, dev sdk, sector 256 Apr 2 18:44:41 R720XD kernel: sd 1:0:9:0: rejecting I/O to offline device Apr 2 18:44:41 R720XD kernel: print_req_error: I/O error, dev sdk, sector 256 Apr 2 18:44:42 R720XD kernel: sd 1:0:9:0: rejecting I/O to offline device Check/replace cables or better yet connect it to the onboard SATA ports, as a bonus you'll be able to trim it.

This is what made /mnt/user go way: Apr 2 20:01:48 Tower shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed. But no idea what caused it or what it means exaclty, you could try running for a day or so without any dockers/VMs, if no issues start enabling them one by one.

Seems like a good idea to me, and you still have the old 3TB disk if needed.

Yep, more than once.

Btrfs checksum errors are a sign of data corruption, #1 reason for data corruption are RAM errors, and since you're using Ryzen start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

That's normal for new xfs formatted drives, the larger the drive the more space is used for filesystem housekeeping/functions.

Disk was never detected, check the LSI BIOS it will also be missing there, and until it appear there it also won't in Unraid.

No, you can use the parity swap procedure.

The 3TB drive won't be there during the rebuild, so it can't fail, only other option would be to disabled the disk now, array will be faster (if the other disks aren't used for other things), but you'll be unprotected.

Unlikely to get better, I would replace it now, especially considering it's the infamous ST3000DM001

It's not, usual workaround is to set higher temps on the general settings, then set individual temps on all arrays devices, obviously if you have non NVMe unassigned devices you'll stop getting warnings on those.

Click on the device and you can set a custom temperature.

That an NTFS unassigned disk, run chkdsk on it.

Macvlan call traces are usually related to dockers with custom IP addresses.