JorgeB

Problem with the onboard SATA controller: Nov 17 19:26:06 HaberLand kernel: ahci 0000:02:00.1: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0x9195e000 flags=0x0000] Quite common with Ryzem boards, though it usually works mostly OK with the latest Unraid betas, look for a BIOS update for your board, or disable IOMMU of not needed.

You just need to re-assign it (make sure cache slots are still set to 1 and filesystem is set to auto (or xfs if that is what is was using).

This is known to do that: Nov 5 12:29:41 Eeyore nerdpack: Installing atop-2.2 package...

There are multiple macvlan call traces, these are usually the result of having dockers with a custom IP address, more info here:

Formatting is the best bet to fix it.

Replace it, if you need to recover data and since parity isn't valid best bet is to use ddrescue.

You'll need to remove one of the devices from the pool, there are many ways to do it, easiest is probably to assign both to the same pool and then remove one of them, note that you need to reset pool config first or it be wiped, this should be straight forward but make sure anything important is backed up before starting. Stop the array, if Docker/VM services are using the cache pool disable them, unassign the cache devices from both pools, start array to make Unraid "forget" current cache config, stop array, reassign both cache devices to the same pool (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), re-enable Docker/VMs if needed, start array, now do a standard pool device removal and when done assign that device to the new pool.

Also make sure you're using the correct "Power Supply Idle Control" setting.

Try another add-on card on the same slot, if it doesn't work it's likely a damaged CPU.

You have an old browser window/device open on the GUI causing wrong csrf_token errors with UD, probably unrelated but those errors are mostly during opening encrypted devices, so you should try again after closing that.

VMs only autostart if the array is also set to autostart, and that's done on purpose.

Unlikely to be that, SATA2 is enough for spinners, only SSDs (and very few of the current fastest disks) need more bandwidth than that.

Mover won't touch a share set to "no" or "only", all the appdata should be on the same place, so you should finish moving it to cache, after it's done you can leave it as cache "only" or "prefer".

It's not a cable problem, the HBA itself is not being detected, you can try it in another PC if available, but maybe it just died.

This.

It's the first thing to try.

Possibly unrelated but should be fixed anyway, you have an unassigned disk (WD40EFRX-68WT0N0 s/n WCC4E4JNHYEC) generating a lot of ATA errors, if it's not being used disconnect it, if it is replace cables, also the LSI is on a very old firmware, you should update it.

Latest Unraid v.6-beta

Yep, maybe someone else will chime in, I don't have any Macs, only work with them when I get paid to do so at work. 😛

I would say that only confirms it's a problem with that specific computer/OS.

Disable all dockers them enable one by one.

Problem appear to be caused by something trying to connect to tracker.mp3-es.com, does that ring any bells?

appdata share is being moved to cache, since there's no space the mover aborts and it never gets to the tank share, they are moved alphabetically, change appdata share to cache="only" or "no" so nothing is moved for now, then run the mover to move the tank share and change it back.

This looks more like a macOS problem.