JorgeB

You can't add a device to an xfs cache.

Also that root share video doesn't make much sense since for some time now Samba has server side copy, i.e., data copied between shares doesn't traverse the network.

If you're really transferring to an Unassigned device data can never end up in cache, diags might give more clues.

Diags are just after rebooting so not much to see, you can try this and then post that log.

This suggests a problem with that particular controller, try re-flashing it if not yet done.

That suggests it's not an Unraid or network problem, but I never used krusader, so can't help with that.

Parity can emulate a missing disk, corrupt filesystem is a different problem, though not clear that is the issue here since it looks more like the partition/superblock disappeared, you can try unassigning that disk and see if Unraid can emulat it, the partition would be re-created.

Seems odd that unmountable cache would cause that, but happy that it's solved.

Looks like the filesystem (or partition) completely disappeared, you're sure it was btrfs like the other disks right? Yep. Run a scrub, any corrupt files will be named in the syslog, and if there are any they need to be deleted/restore from backups.

Could point to a hardware problem, another 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.

Possibly, but unlikely.

Problem started after this: Feb 6 16:00:16 RIAAHQ apcupsd[20761]: UPS Self Test switch to battery. Maybe enclosure powered down?

Is it the same if you if transfer directly form Unraid to Unraid with rsync for example? Or even Windows?

Start by running memtest.

No read error, just the write error, which is not so common, I would replace/swap cables on that disk, if it happens again it's likely a disk problem.

It's complaining about an invalid partition: Feb 6 21:30:19 Atlas emhttpd: /mnt/disk5 mount error: Unsupported partition layout This shouldn't happen without reason, and according to the output above it's not just the partition that is damages, it's also missing the btrfs superblock, you can try this as a last resort: btrfs-select-super -s 1 /dev/sdX1 Replace X with correct letter, then see if the recovery options work (it will still be unmountable with Unraid due to the invalid partition) P.S. also note that most of your other disks are showing previous read errors, and disk2 is lso showing data corruption: Feb 6 21:30:02 Atlas kernel: BTRFS info (device md1): bdev /dev/md1 errs: wr 0, rd 1815, flush 0, corrupt 0, gen 0 Feb 6 21:30:06 Atlas kernel: BTRFS info (device md2): bdev /dev/md2 errs: wr 0, rd 8155, flush 0, corrupt 1036, gen 0 Feb 6 21:30:12 Atlas kernel: BTRFS info (device md3): bdev /dev/md3 errs: wr 0, rd 15394, flush 0, corrupt 0, gen 0 Feb 6 21:30:15 Atlas kernel: BTRFS info (device md4): bdev /dev/md4 errs: wr 0, rd 19748, flush 0, corrupt 0, gen 0

Usually you don't need to completely disable C-states, just set "power supply idle control" as explained in the link above.

Make sure you stick to the officially supported RAM speeds.

https://s3.amazonaws.com/dnld.lime-technology.com/next/unRAIDServer-6.9.0-beta30-x86_64.zip

Are you using v6.8 or v6.9? 6.9 should perform better, but cache devices need to be re-formatted to take advantage of new alignment. Also not that the QVO is QLC, if will perform OK for the first few GB but then it can only sustain 80MB/s writes.

You can upgrade at any time, upgrade now if you need multiple pools.

2.5TB is correct for that config in raid1. Well, I did warn you that there's a bug and cache replacement doesn't work.

Diags are just after rebooting so not much to see, you can try this then post that log.

Please re-post in the existing plugin support thread:

Jan 30 22:28:42 Vault kernel: macvlan_broadcast+0x111/0x156 [macvlan] Jan 30 22:28:42 Vault kernel: macvlan_process_broadcast+0xea/0x128 [macvlan] Problem starts with macvlan call traces, these are usually the result of having dockers with a custom IP address, and they may end up locking up Unraid, see below for more info: