JorgeB

Split from the FAQ thread, @sunshine59as mentioned there please don't use that thread for questions.

Please use the existing plugin support thread:

When a device is passed trough like that any issue with it should be related to the VM using it, Unraid isn't loading any driver or doing anything to it, hence passed trough, even if the device wasn't supported by Unraid it can still be passed through and used by a VM (that supports it).

Should be fine, though 1600MT/s RAM would be better.

That error means there's a partition problem, not a filesystem one, so xfs_repair won't help, if parity is valid you can rebuild the disk and let Unraid will recreate the correct partition, to test you can stop the array, unassign that disk, start the array, if the emulated disk mounts and contents look correct you can rebuild on top, if the emulated disk doesn't mount post new diags.

NIC is supported, currently is being passed through to vfio-pci, so it can only be used by a VM.

At boot there were only 4 devices found from the pool, devid 2 was already missing: Mar 26 15:25:41 BigServer kernel: BTRFS: device fsid 6256fb88-756b-4111-8cb1-eb5ebd47f76b devid 3 transid 2574301 /dev/sdj1 scanned by udevd (758) Mar 26 15:25:41 BigServer kernel: BTRFS: device fsid 6256fb88-756b-4111-8cb1-eb5ebd47f76b devid 5 transid 2574301 /dev/sdd1 scanned by udevd (758) Mar 26 15:25:41 BigServer kernel: BTRFS: device fsid 6256fb88-756b-4111-8cb1-eb5ebd47f76b devid 4 transid 2574301 /dev/sdh1 scanned by udevd (745) Mar 26 15:25:41 BigServer kernel: BTRFS: device fsid 6256fb88-756b-4111-8cb1-eb5ebd47f76b devid 1 transid 2574301 /dev/sdl1 scanned by udevd (769) This was devid 2, it was assigned but there isn't a valid btyrfs filesystem there, can't see why since it was already like that at boot Apr 5 20:52:39 BigServer emhttpd: import 31 cache device: (sdk) MTFDDAK256MAM-1K12_14170C18C9B8 After that you unassigned a different device and started the array, this resulted in Unraid wiping another device: Apr 7 19:15:14 BigServer root: /dev/sdd1: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 52 66 53 5f 4d So now there are two missing pool devices, you can try this: btrfs-select-super -s 1 /dev/sdX1 Do this for sdk and sdd, if you rebooted since check that the device identifiers are still the same, if the command is successful for both, unassign all the pool devices, start the array so that Unraid can "forget" the pol config, stop array, re-assign all 5 pool devices, start array and post new diags.

like mentioned: I use snapshots but never tried Windows previous versions, you'll need to google what's needed, for example: https://michlstechblog.info/blog/samba-setup-for-windows-previous-versions-support/

LSISAS2008: FWVersion(10.00.08.00) One thing you should do is to update the LSI firmware, this is very old, also check/replace/swap cables/slot for parity disk in case the firmware update doesn't help.

Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0 fault info from func: _base_make_ioc_ready Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0: fault_state(0x6003)! Apr 6 19:00:28 SkyNet kernel: mpt2sas_cm0: sending diag reset !! Diags show multiple issues with the HBA like above, make sure it's well seated and sufficiently cooled, you can also try a different PCIe slot if available

You forgot to post those.

Please post the diagnostics.

Syslog isn't complete, but disks are dropping offline and reconnecting, this is usually a power/connection problem, see if the disks share something in common like a minSAS cable or a power splitter, if not the PSU would be the main suspect.

Yep, as long as you access the snapshot as user share, unless something with previous versions Samba settings prevents that, it's something I never tried myself.

It happens sometimes, diskspeed docker will clearly show if that's the issue.

NIC is losing the link, not much you can do on the Unraid side: Link detected: no

Nope.

It will eventually finish, with or without finding a suitable backup.

OK, primary superblock is damaged on both disks: Apr 6 01:12:10 LilNas kernel: XFS (md1): Invalid superblock magic number ... Apr 6 01:12:11 LilNas kernel: XFS (md3): Invalid superblock magic number There are backup superblocks in the filesystem, so let it scan the complete disks, but if xfs_repair can't find a valid backup it won't fix the filesystem, in that case only a file recovery util like UFS explorer can might be able to recover the data.

Just to make sure, you ran xfs_repair on the md device, not sdX, right?

You can take snapshots manually with the CLI (or a script) or use for example the snapshots plugin, just keep in mind that with Unraid each array device is an independent filesystem, so if a share spans more than one device they will be in multiple filesystems/snapshots, as for previous volumes with Windows they should work as long as the correct Samba options are set, it's something I never tried but I think I've seen in the forums before.

Please post the diagnostics after starting the array in normal mode, not maintenance mode.

It was this issue:

Not especially, just need to be working correctly.

There are still issues, possibly less then before but they are still there, and they fallowed the disk, so it's not the port, still looks like a cable problem to me, power or SATA, but if you really swapped them it could be the disk.