JorgeB

Filesystem went read-only to avoid writing corrupt data, rebooting should fix it but this usually indicates a hardware problem or some other kernel memory corruption.

Yes, but you'll need to start over.
 
Check filesystem on cache.

Do the recover password procedure, should fix that:
 
https://wiki.unraid.net/Manual/Troubleshooting#Lost_root_Password

That's not possible, Unraid requires a specific partition layout and signature, you can mount the disk with UD plugin and copy the data to another disk(s) on the array.

Parity drives have to be same or larger size than the largest data drive, so yes it can be 14TB.

Yep.

Yes.

Jul 12 11:36:40 Tower emhttpd: error: share_luks_status, 6151: Operation not supported (95): getxattr: /mnt/user/lxc This appears to be the problem, you should not create any mountpoint in /mnt/user, those should be reserved for Unraid array/pools only.
 
Also I believe ich777 recommendeds not using a FUSER path for LXC for performance reasons, use /mnt/cache/lxc or /mnt/disk#/lxc

Delete and recreate the docker image.

This can happen when there's a single btrfs array device, like disk2, parity will have an invalid btrfs filesystem that conflicts with the pools, this will be supported in the future but for now best solution is to format it xfs like the remaining disks, if for some reason you really want just that disk with btrfs use btrfs encrypted.

Rename network.cfg on the flash drive and reboot to see if it can get an IP from the DCHP server.

https://forums.unraid.net/topic/95309-empty-disk-using-56gb/
 
Parity still needs to be synced, disks might be empty but unless they are new or have been cleared they won't be all zeros.
 
CPU is not supported by mcelog, not by Unraid, it's fine.

If it boots with a new config means something in the old one is causing the problem, you copy parts of it until you find the problem or just reconfigure the server.

Jul 10 19:41:27 HedonistMedia kernel: BTRFS: device fsid 735f5a28-a992-4be9-b621-47603518b082 devid 1 transid 202666812 /dev/sdc1 scanned by udevd (1059) Jul 10 19:41:27 HedonistMedia kernel: BTRFS: device fsid 735f5a28-a992-4be9-b621-47603518b082 devid 2 transid 202683889 /dev/sdf1 scanned by udevd (1179) Jul 10 19:41:27 HedonistMedia kernel: BTRFS: device fsid 735f5a28-a992-4be9-b621-47603518b082 devid 3 transid 202683889 /dev/sdj1 scanned by udevd (1200) I assume the old deceive is sdc? Did you replace or add new device and the remove the other one? Either way something went wrong since the old device is still part of the filesystem, fiscally disconnect the old device (I'd like to avoid wiping it for now) and if the pool mounts, if it doesn't post new diags

Disk look OK and problem happened right after spin up, rebuild the disk and if it happens again I would either connect that disk to a different controller, like the Intel SATA ports or disable spin down.

If nomodeset helps just add that to syslinux.cfg, click on the flash drive and scroll down to "syslinux configuration":
 

 
Save and reboot.
 

NIC is being passed-through to the VM:
 
-device vfio-pci,host=0000:05:00.0,id=hostdev0,bus=pci.0,addr=0x8 \  
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)  
 
 
 
 

Unraid tracks devices by serial number, not by filesystem UUID, once you assign the new disk Unraid only cares about that one.

Update to 6.10.3 and they will work.

Jul 5 09:39:17 Tower kernel: ahci 0000:03:00.0: AHCI controller unavailable!  
Problems with the Marvell controller, and all devices connected there dropped, Marvell controllers are not recommended for Unraid, first thing I would recommend is replacing it with a recommended controller, once that's done (or if you don't want to do that for now just power cycle the server) run a scrub on the pool and post new diags.

Click the minus to hide the partition, you can also set to show or hide partitions by default for each device by clicking on its settings, and next time or if you have more questions please use the existing plugin support thread.
 
 

Yes, it does look like a power/connection problem, disk 1 also showing similar issues, replace cables and rebuild.

Jul 6 21:38:14 kunraid kernel: BTRFS: device fsid 0ecc5969-4afc-4b9a-a299-3fab30cf63d9 devid 1 transid 153079 /dev/sdb1 scanned by udevd (1244) Jul 6 21:38:14 kunraid kernel: BTRFS: device fsid 0ecc5969-4afc-4b9a-a299-3fab30cf63d9 devid 2 transid 147224 /dev/sdc1 scanned by udevd (1234)  
devid 2 is on an older generation than devid 1, this can sometimes fix it:
 
btrfs-select-super -s 1 /dev/sdc1  
If you rebooted since the diags check that ssdcache2 is still sdc, then reboot and if it still doesn't mount post new diags.

https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

Yes, it won't affect the rebuild, check filesystem on disk2 when it's done.