JorgeB

See if it can be flashed to IT mode, since it's using the SAS3008 chip there's a good chance it can, RAID is not recommended for Unraid.

If you mean total disk capacity, no, it can't be that.

May 10 18:52:15 Smalls kernel: macvlan_broadcast+0x10e/0x13c [macvlan] May 10 18:52:15 Smalls 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 might 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/

If it works in safe mode it suggests one of the plugins is the problem, uninstall or rename the plg files to see if you can find the culprit.

Sorry don't known what any of that is, if it's a docker best bet is to ask for help in the existing docker support thread, if there is one:

Your cache device appears to be failing, you can run an extended SMART test to confirm, also run one on disks 5 and 6 since there are some read errors logged as disk issues. May 22 21:59:53 Tower kernel: XFS (md6): Unmount and run xfs_repair Then check filesystem on disk6.

This has been happening with at least a couple of different controllers that were using long names for SATA devices, short names is what they should show, this way if in the future you replace the controller with a different one no need for a new config, also please post the diagnostics so we can see what controller you're using.

That rules out the SATA port and SATA cable, leaves the power cable or the drive as the possible issues.

Was the restore done before or after going back to v6.9? That means something is using that, also check no terminal windows open in a mounted folder.

You did the format the cache before, did you restore the appdata from a backup?

Also check filesystem on the cache device just to be sure there are no issues, run it without -n or nothing will be done if corruptions are found.

Not seeing any filesystem issues logged, where are you seeing the read only error?

I would be surprised if it was Unraid causing this, likely something changed in the LSI driver or in one of packages that Unraid uses, in any case it's much better for you like that, as it was if you replaced the controller with a different model the same would happen, now it's using the standard names.

Docker image or a filesystem might still be corrupt, but at least it won't get worse now, please post new diags to see what's the best option.

Not yet clear what activities, usually issues start after a few hours of normal use, docker image or any other btrfs filesystem are usually the first to go since they are very susceptible to memory corruption issues, if the pools are btrfs run a scrub, parity check for the array if xfs, though if errors are detected basically you can only correct them, unless you have pre-existing checksums, also note that while some corruption is possible it's not certain, in at least one case btrfs detected some corruption but after disabling VT-d and running scrub no more corruption was found.

It's full of ATA errors for disks 2 and 4, could be a power/connection problem, could be the controllers, both are connected to Marvell controllers, they are not recommended but if they have been working OK with the same Unraid release unlikely that they would start acting up now, they can if you updated to a new release recently. Also a good idea to first run a couple of memtest passes, some issues suggest possible RAM problem.

First replace parity only, when it's done syncing you can add more array disks.

Already wrote multiple times that you can't do that.

Do that, don't forget that you can only assign parity first, if you also try to add array drives you won't be allowed to start the array.

Low lan speed is not known as a problem, but most users usually see other more serious errors soon so not really time to test, it might also be related, if you need VT-d you should go back to 6.9.2 for now, note that VT-x is still OK, you can run VMs just not pass-trough any hardware without VT-d.

https://forums.unraid.net/topic/123620-unraid-os-version-6100-available/?do=findComment&comment=1129618

Not that but there are some serious known issues with the onboard NICs if you have a Xeon and VT-d is enable, so careful with that.

Again that screenshot only shows that a disk is clearing, nothing more, your description is also not very clear to me, but if what you're trying to do is to replace parity and at the same time add a new array device that's not allowed, you need to do one thing at a time, if it's not that then please post the diagnostics after you get the error you are seing.

Screenshot just shows a disk still preclearing, if you're having issues with preclear you should post in the appropriate thread for the plugin you're using, preclearing a disk is optional.

I agree with Itimpi that the update in principle shouldn't change any permissions, but pretty sure I read other users complaining of something similar, so don't rule that out for now, and if confirmed you should open a bug report.