JorgeB

That's not possible. Actual disk might still be OK, you can try mounting it with UD, note that the array needs to be stopped or you need to change the XFS UUID first, or it won't mount.

That's not the issue, the problem could have been a result of the read errors on disk5 when another disk was being emulated, that disk could be corrupted.

Nothing other than upgrading to v6.9.x.

Mar 10 03:40:09 Tower move: move_object: /mnt/cache/Movies/Prisoners/Prisoners.bluray.mkv File exists File already exists on dest.

Cache is failing to balance because it's completely full, you could try stopping the array, mounting cache manually with skip_balance, delete some data to free up some space then mount normally. If you want to try that do this: Stop array then type on the console mkdir /x mount -o skip_balance /dev/sdX1 /x X=one of the cache devices, either one is fine Then still on the console or using for example midnight commander browse to /x and delete some data, when done umount /x Start array and see if it can finish balancing.

Yes. If you're using Windows 10 you can use windows explorer to move/copy from the UD device to the array, and the transfer will still be done locally, it won't use the network. Diags posted don't show anything out of the ordinary, but before the time covered there you mentioned another disk with read errors while that one was disable, this could very easily have caused issues with the emulated disk, since you only have one parity all the other disks need to be 100% for the emulated disk to be OK.

It is; xfs_repair -v /dev/sdd1

It's still showing a duplicate UUID, try changing it manually: xfs_admin -U generate /dev/sdX1 Replace X with the correct letter, if still the same it's /dev/sdd1, note the 1 in the end.

That was one of the things I was thinking, diags would confirm, glad you found it.

That looks like a flash drive problem, you can try redoing it, sometimes booting UEFI instead also helps, if the server supports it.

My guess is it was a coincidence, the issues logged are hardware problems, not software.

That means it's and unclean shutdown, when this happens Unraid saves the diags in the flash drive (logs folder), please post latest ones.

If they also don't mount with UD then there's no partition or it's damaged, please post output of: fdisk -l /dev/sdX Replace X with one (or all) of the invalid partition disks.

That's over my head. Trial flash would just be to confirm if the issue is related to your config, no need for key transfer, if it worked you could redo your current flash.

It's running on both main main servers, both on v6.9.1, without any issues.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=545988

You just need to delete nut.plg and its folder, and if you want you can try re-installing, very much doubt your troubles were caused by the plugin.

Not sure, not seeing any issues in the log, try booting with a new trial key, just to see if main works.

Try booting in safe mode, if it doesn't help please post diags.

Start with the clean flash and reconfigure you server, don't use a backup, also check all the other devices in your lan, and make sure router has the DMZ disable and it's not forwarding any posts to the Unraid server.

App won't cause hardware issues like that, but if you doubt that just delete the plugin from /config/plugins and reboot.

Do you mean data on the array drives was deleted? Unraid doesn't delete any data, you were/are being hacked or have some other serious issue.

Yes, a bad one or a bad model, JMB chip works fine.

Yes, flash drive dropped, it either a flash or USB controller problem. Mar 19 10:16:23 Novanas2 kernel: usb 1-12: reset high-speed USB device number 3 using xhci_hcd Mar 19 10:16:23 Novanas2 kernel: usb 1-12: device firmware changed Mar 19 10:16:23 Novanas2 kernel: usb 1-12: USB disconnect, device number 3 Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 1686 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 1623, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 9373 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 9310, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 207701 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 207638, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 207701 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 1686 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): unable to read inode block for updating (i_pos 3322223) Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): FAT read failed (blocknr 1623) Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 64 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 1, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 207647 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 207584, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 207695 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: Buffer I/O error on dev sda1, logical block 207632, lost async page write Mar 19 10:16:23 Novanas2 kernel: blk_update_request: I/O error, dev sda, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): bread failed in fat_clusters_flush Mar 19 10:16:23 Novanas2 kernel: usb 1-12: new high-speed USB device number 4 using xhci_hcd Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): Directory bread(block 207632) failed Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): Directory bread(block 207633) failed Mar 19 10:16:23 Novanas2 kernel: FAT-fs (sda1): Directory bread(block 207634) failed

GUI reboot might work but depends on how your VMs are configured and the set timeout, if possible always best to stop them first, dockers should not be a problem.