JorgeB

You can, and check that the emulated disk mounts, you should then replace the missing disk ASAP.

You can acknowledge both, then keep monitoring, disk4 are CRC errors, this is usually a SATA cable problem so if you get a new warning in the future change that, disk6 has some reallocated sectors, not great but not fatal, again monitor for more in the future, if it keeps increasing you might consider replacing it.

See here:
 
https://wiki.unraid.net/Manual/Security#Securing_webGui_connections_.28SSL.29
 
If it does not help edit config/ident.cfg on the flash drive and change USE_SSL from "auto/yes" to "no", then reboot.

No, but the fact that it is not working suggests a device problem, SMART is independent of Unraid.
 
 
Why? The shelf works with SATA, interposers are preventing you from monitoring SMART for all connected SATA devices.
 

Yes, the pool is making Unraid crash, cannot see why though, unassign both pool devices, start the array and then see if you can mount them using the recovery options here, if the first options doesn't work best bet is to use btrfs restore.

-boot using GUI mode and set the onboard NIC to eth0 (Settings -> Network Settings -> Interface rules), assign the static IP you want and the other settings and reboot, of course link will need to up for it to work.

Nope.

Reboot.
 
Device disconnected, one of the reasons we don't recommend USB devices in the array/pools.
 
Aug 12 21:57:28 Tower kernel: usb 3-5: USB disconnect, device number 2 Aug 12 21:57:39 Tower kernel: usb 3-5: new high-speed USB device number 5 using xhci_hcd  

Aug 11 11:09:48 WMLUnraid kernel: ata1: COMRESET failed (errno=-16) Aug 11 11:09:48 WMLUnraid kernel: ata1: reset failed, giving up Aug 11 11:09:48 WMLUnraid kernel: ata1.00: disabled  
SSD cache dropped offline, but that's not a reason for the server crashing, still you need to fix that, check/replace cables, then enable the syslog server, start the parity sync and post that if it crashes again.

Yep.

Why? Just needed to format the disk.
 
No, a few sync errors after an unclean shutdown are normal, even expected, last check detected 0 errors so all is good now.
 

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

Jun 14 10:00:47 172.18.0.1 kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jun 14 10:00:47 172.18.0.1 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/

Edit /config/disk.cfg in the flash drive and change this line:
 
diskFsType.2="&xfs"  
to
 
diskFsType.2="xfs"  
Then start array.

It's happening  because you had a single btrfs array drive, it's a known issue since it make parity appear to have an invalid btrfs filesystem, to fix:
 
-unassign both pool devices
-start array
-format disk3 using xfs
-stop array
-re-assign both cache devices
-start array, all should be good, if it isn't post new diags.

It's only linking at x4, than means at theoretical max speed of 2GB/s, about 75% of that is usable, so 1.5GB/s seems about right.

It's a btrfs issue with an odd number of drives in raid1, it still works and free space will get closer to correct as the pool is filled.

Yes, assuming parity was valid before and the new disk is really precleared.

Aug 2 07:49:22 ur01 kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Aug 2 07:49:22 ur01 kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan]  
Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right))

Parity swap is known to sometimes, unclear yet why this happens only in some cases, no correctly zero out the extra parity capacity, so the first check will correct that.

Yep.

Looks more like a power problem, it's affecting multiple disks in different controllers, could also be SATA cables.

Check filesystem on disk5.

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

Aug 3 02:15:23 black shfs: shfs: ../lib/fuse.c:1451: unlink_node: Assertion `node->nlookup > 1' failed.  
It's the issue below:
 
 
Some workarounds discussed there, mostly disable NFS if not needed or you can change everything to SMB, can also be caused by Tdarr if you use that.