JorgeB

I though you started syncing parity on those drives, or did I misunderstand? Any case see if sdn mounts.

Just upgrade parity then after the new parity finishes syncing add the old parity as a new disk, if you want to play it safer start the array in maintenance mode for the new parity sync and keep old parity intact until it's done, but the array will not be accessible during the sync.

Drive is fine, but no apparently there's no xfs filesystem there, please post the output of: blkid

If you lost the flash drive and don't have a backup you need to re-install de dockers using the same settings.

That's suggests there's no valid filesystem on that disk, are you sure it wasn't a parity drive?

Can't think of what the problem could be.

Please also post the diagnostics.

Like mentioned above there's a plan for Unraid to soon have an option to easily install out of tree drives, this is the best bet for issues like these, where the in tree driver doesn't work with some models, when LT used some out of tree drivers it broke other models support, this way only users who need it install the out of tree driver.

That should not happen, as long as the array plus cache has enough space for all the files you're trying to copy to that share.

You don't start a new topic, you use the existing support thread linked above.

Best bet is to post in the existing plugin support thread:

Jul 21 20:30:06 UNRAID kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jul 21 20:30:06 UNRAID kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. 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/ P.S. you should update to latest stable, v6.10.3

Just assign the new parity drive and start the array to begin the parity sync.

This suggests a hardware problem, PSU or board would be the main suspects, also the UPS if one is being used.

I do: Jul 26 03:30:12 Nastradamus emhttpd: shcmd (36814): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Jul 26 03:30:13 Nastradamus kernel: sd 7:0:7:0: [sdi] tag#520 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 26 03:30:13 Nastradamus kernel: sd 7:0:7:0: [sdi] tag#520 Sense Key : 0x3 [current] Jul 26 03:30:13 Nastradamus kernel: sd 7:0:7:0: [sdi] tag#520 ASC=0x11 ASCQ=0x0 Jul 26 03:30:13 Nastradamus kernel: sd 7:0:7:0: [sdi] tag#520 CDB: opcode=0x28 28 00 00 27 fe a0 00 00 20 00 Jul 26 03:30:13 Nastradamus kernel: print_req_error: critical medium error, dev sdi, sector 2621088 Jul 26 03:30:13 Nastradamus kernel: BTRFS: device fsid c5bc54e2-9593-41d2-b010-1527e11dbd61 devid 1 transid 162 /dev/loop3 Jul 26 03:30:13 Nastradamus kernel: BTRFS info (device loop3): disk space caching is enabled Jul 26 03:30:13 Nastradamus kernel: BTRFS info (device loop3): has skinny extents Jul 26 03:30:13 Nastradamus kernel: BTRFS error (device loop3): bad tree block start, want 30883840 have 0 It suggests a device problem, please post new diags after rebooting and starting the array to confirm it's the same issue.

Parity swap is only needed when you have a disabled data disk and the new replacement disk is larger than current parity, from your description doesn't look like that's the current situation, if you just mean re-sync parity that can be done at any time.

Enable the syslog server and post that after a crash.

If you don't see a shutdown event initiated in the remote syslog it's likely a hardware problem, though the hardware you replaced should have fixed that, if a shutdown event is being logged there could be other reasons.

You can try creating a new VM but pointing to the existing vdisk.

Please post the diagnostics.

Not really, don't know of a way to suppress that error, so you'd need to reboot regularly to keep the log from filling up.

Please post the diagnostics but VMs pausing after start usually means that the storage device where the vdisks are is running out of space.

Yes, use the recover password procedure: https://wiki.unraid.net/Manual/Troubleshooting#Lost_root_Password

See if this helps: https://forums.unraid.net/topic/124890-gtx650ti-code-43-with-windows-10/?do=findComment&comment=1139615

Yes, you can also update using the GUI, if you can get it to boot at least once.