JorgeB

SAS expander don't have drivers, and if rolling back didn't fix it it's not a HBA driver/Unraid issue, besides you have two identical HBAs and both are being detected and initialized correctly, just one of them is not detecting any connected devices, this is a hardware issue, check connections from the HBA to the second expander, also check power on that expander.

No, but if errors were/are found you'll need to run a correcting check, in that case you can cancel that one and start a correcting one before or after fixing the filesystem.

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

Also, like mentioned above, it's not always true with this NIC, first google result: https://community.intel.com/t5/Ethernet-Products/Intel-PRO1000-PT-network-card-not-showing-up-on-PCIe-bus-one/td-p/277091

Never tried but should be OK.

I guess the mover goes in alphabetical order, and appdata comes first.

It's not, it's trying to move some data from disk2 to cache.

Samba is more chatty with -beta30, and don't know exactly what that error means but it appears to be related to the enhanced macOS interoperability, do you have that enable? If yes and it's not needed try disabling it.

@trurlmight know better why both appear on the diags, don't remember the exact circumstances that cause that. For the mover issue, please enable mover logging, run the mover and post new diags.

Disks can fail at any time, you can write zeros to the entire disk, it might fix it, but possibly only temporarily, use for example pre-clear, then run a read test or and extended SMART test.

What share is using cache that you want moved? You also appear to have shares downloads and Downloads, a setting for both exists on flash and it will only work for one, delete the one that shouldn't be there, also make sure only one of those exists on all the disks, Linux is case sensitive.

That disk is failing: 197 Current_Pending_Sector -O--CK 200 200 000 - 1

Can't download diags.

Please post the diagnostics after a format attempt: Tools -> Diagnostics

It really looks like a connection problem, but if you already replaced cables disk3 might be failing, and in that case there's no option to recover either disk, but I would still try another cable, swap with another disk.

Disk3 dropped offline, and since there's already a disable disk contents can't be emulated, power down, check/replace cables on disk3, power back up and post new diags.

Driver is almost certainly included, but without the NIC being detected nothing that can be done on Unraid side, this is a hardware problem. You can try setting PCIe to 1.0/1.1 on the board BIOS so see if it makes any difference.

Any partial/lost files will be moved to the lost+found folder, you can then analyze them, again parity can't help with filesystem corruption.

You can mount each disk with the UD plugin (use the read-only mode), if there's just one parity there should be only one disk without a filesystem, that would be parity, do a new config and re-assign all disks (data disk order is not important with single parity) and check parity is already valid before array start, if you have dual parity post back since there are a few differences.

I’ve been ruminating on this SAMBA aio issue because the very large read performance difference first reported by @trypowercyclereminded me of an issue I’ve seen before, but I was having trouble finding that post, now I know why, because those forums are gone? I did finally find it in my content: And this is the comparison I posted at the time: So I believe I noticed this issue at around the same time aio was introduced in Samba, and at the time disabling smb3 fixed it, now I wonder if it was already the same issue and disabling smb3 was also disabling aio, symptoms are very similar, and the problem wasn’t controller related but device related, some brands/models perform worse than others, so I now did some more tests with –beta30 and different disks. Ignore the normal max speed difference from brand to brand, I used whatever disks I had at hand, so some disks are older and slower than others, the important part is the aio on/off difference, tested with disk shares so no shfs interference, all connected to the same Intel SATA controller, each test was repeated 3 times to make sure results are consistent, read speed reported by robocopy after transferring the same large file. I think the results are very clear, and by luck (or bad luck) the tests this past weekend were done with the only disk that now doesn’t show a significant difference, note that I don’t think this is a disk brand issue, but a disk model issue, likely firmware related, possibly worse in older disks? I know you already plan to leave aio disable, but still one more data point that I believe really confirms it should be left disable.

Macvlan call traces are usually caused by having dockers with a custom IP address, more info here:

Changed Status to Closed Changed Priority to Other

This doesn't look like a stock Unraid issue, possibly the docker folder plugin? Try removing it or booting in safe mode.

You should use the existing plugin support thread:

Just installed one recently with -beta30 without issues, Ubuntu 20.04.1 IIRC, default settings.