JorgeB

It should mount now if you start the array.

No.

Good you found the issue, if you don't mind I'm going to tag it solve. Edit: I see you already did it.

It can also be the rsync command, e.g. if it's using compression, but that's unlikely assuming you're using the same as before.

So the enclosure is likely the problem.

Not necessarily since there were also writes to other data disks that made old parity out of sync, still a filesystem check might be enough to recover the old or a rebuilt disk, in any case you need to do a new config first: -Tools -> New Config -> Retain current configuration: All -> Apply -Assign correct parity drive in place of current disk3 -Leave the array like that for now, don't start it. Now before re-assigning old disk3 you want to make sure it's still mounting, see if it mounts with UD (use read-only option) then post results so we can decide best course of action.

Gigabit network transfer should give you around 110MB/s, if you get that it points to an enclosure issue, if you get the same 30MB/s it's likely an array issue, it gives us an idea where to start looking for the problem.

NEVER formatting, unassign the disk, start the array, emulated disk is likely still going to be unmountable, if yes run xfs_repair on the emulated disk. though there's a small possibility the emulated disk could mount from start if the actual disk really has a problem.

Testing the speed using the network would rule out an enclosure issue, or confirm an array problem, either way it would be an easy thing to do.

Why would it be slower? Are using 100Mbit or Wifi?

It does look like a disk problem, thought the ATA errors are not logged as media errors, but adding the weird noises and reallocated sectors it points to that, you could unassign that disk, then attempt to fix the filesystem on the emulated disk, if successful rebuild to a new disk.

Please post current diags just to see if there's any disk read error, either that or it's a xfs_repair issue.

Run without -n or nothing will be done.

Best bet would probably be to email Asrock support to get a list all the SEL codes, or at least tell you what those are about.

If there's no parity the problem is likely with the USB enclosure, it might not be linked at USB 3.0, test transferring from your desktop to the array.

That's odd, many users with that board, you could try booting UEFI instead.

It will work, depending on how you copy it you might need to be re-created, but that's easy to do, in fact probably best to just do that instead of copying it, only copy the other folders.

This requires all data devices to me members of the same pool, it prevents the full utilization of different size devices and if more disks fails than current redundancy you lose the whole pool, for that you already have FreeNAS, one of the main advantages of Unraid is every data disk being an independent filesystem, even if LT supports ZFS in the future, and I hope they will, array devices will still be an independent filesystem, i.e. without zfs redundancy, redundancy would still be done by parity, zfs would be nice mostly for use with cache pool(s), and shfs is still needed to make them part of the user shares.

Flash drive problems: Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32768) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32769) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32770) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32771) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32772) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32773) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32774) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32775) failed Apr 23 04:40:12 Tower kernel: FAT-fs (sda1): Directory bread(block 32776) failed Run chkdsk on it and make sure it's using a USB 2.0 port, if if keeps happening try recreating or replacing it.

You can just rename the current plugins so they don't install on boot, you can then rename them back, they are on flash/config/plugins, change the extension from .plg to anything else.

If it doesn't do it in safe mode remove all plugins, check it still doesn't do it then start adding them one by one.

Then that looks more like a problem with your desktop, and I'm not seeing any smb/shares related issues on the syslog.

Did you find out and stopped what's doing the multiple writes to the array? Until you fix that there's not much point in looking at other things.

You can't add data and parity disks at the same time, do it one a a time.

Try running xfs_repair again, and if the reallocated sectors keep increasing you should consider replacing that disk.