JorgeB

Controller is bound to be used for a VM, you need to edit your bindings, they usually change when you add or remove any card: Processing 0000:02:00.0 8086:10c9 Vendor:Device 8086:10c9 found at 0000:02:00.0 IOMMU group members (sans bridges): /sys/bus/pci/devices/0000:02:00.0/iommu_group/devices/0000:01:00.0 /sys/bus/pci/devices/0000:02:00.0/iommu_group/devices/0000:02:00.0 /sys/bus/pci/devices/0000:02:00.0/iommu_group/devices/0000:02:00.1 Problem is this one, 02:00.0 and 02:00.1 are two NICs, but since they are in the same IOMMU group as the LSI it's bound together.

Please use the existing docker support thread:

During the parity check there are constant errors form the Unraid md driver, either you have some hardware issue or it doesn't like your hardware, unfortunately no idea if it's one or the other, do you have a different board/PC you could test with?

Sorry, no idea.

Best to post in the nvidia plugin support thread:

You can, just can't between user shares and disks shares or vice versa, user share to user share or disk share to disk share is fine.

Looks like a flash drive problem, it's not booting correctly, try re-creating it or using a different one.

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

One cable is enough to use all the disks, you can connect two for dual link doubling total available bandwidth.

I saw that, but assumed that that's what you used before, not now, anyway to transfer to a share you can use: rsync --options /media/linux/largestorage/media/ [email protected]:/mnt/user/media/

See if this applies to you: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Just replacing the flash drive wouldn't do anything to the partitions, something else happened, there are a couple of things you can try, unassign one of the disks and see if the emulated disk mounts since Unraid will recreate the partition (if it works you then rebuild the disk on top and repeat for the other disks) and/or try to mount them with UD plugin since it doesn't require a specific partition layout.

Type "diagnostics" in the console or use the local GUI to get them and post them here.

It's logged as a disk problem, and SMART shows some issues, run an extended SMART test.

You're overclocking the RAM, Ryzen with overclocked RAM is known to corrupt data resulting in sync errors, see here.

Put the flash drive in you desktop and unzip all the bz* files (and only those) from the latest Unraid zip overwriting existing ones.

No NIC driver is being loaded, update to v6.9.x to support that NIC.

One thing I forgot to mention, if if didn't do a pre-read test first then it's not so strange, i.e., a disk is failing, you do a full write and it starts working, sometimes just for a little while, others it can work for years without issues, not normal would be a read test not failing after a SMART test fail.

Depends on the Unraid version, do it without -f, v6.9.x requires -f

Fix filesystem on disk1: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Correct, it can detect some if there are errors during read, i.e. calculating the checksum for the stored block failed to match the written one due to RAM errors, I believe it's possible that either the block or checksum are corrupted before storing and those can also be detected since they won't match, but if the corruption happens before the data is written and the checksum is calculated for the corrupt block then those would go undetected, unless there were more errors during reads.

You can run a scrub on that pool to look for any corrupt files, if there are any they will be listed on the syslog, files corrupted on btrfs would be detected and you'd get an i/o error when trying to move/copy them, like the ones you got above, but some files might get corrupt after leaving btrfs at the time they got written to the xfs array disks, and no way to find those.

That syslog is spammed with loop2 errors, this is usually the docker image, possible running out of space, but we'd need the full diags to confirm.

When you mount one it mounts the other. Yep.

Yes, they are failing checksums, I also noticed data corruption was detected in you other pool, you likely have bad RAM or other hardware problem. You can use btrfs restore since it won't check for that, but files will still be corrupt, but depending on the severity they might still work.