JorgeB

Try running another filesystem check, that still looks like a filesystem problem to me, if it doesn't help, I would backup and re-format that disk, to make sure the issue is resolved.

This is a new array disk right? New disks added to the array need to be formatted before use, next to array stop button.

Run a correcting scrub on the pool and post the results. P.S. you should change the docker network to ipvlan, since there are macvlan call traces.

Unfortunately there's nothing relevant logged, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

You just needed to check the "I'm sure" box, next to the array start button.

Not surprisingly there's nothing relevant logged, also suggesting a hardware issue.

Server rebooting on its own it's almost always a hardware issue, but enable the syslog server and post that after a crash in case there's something logged.

You didn't need to do a new config, just what I've posted above, but that will also work.

Let the rebuild finish.

Make sure the emulated disk is mounting and contents look correct before rebuilding on top.

You cannot have a new parity a a new disk at the same time, what was the original array state? If there's no data to recover do a new config

Just rebooting should not cause issues, enable mover mover logging, run the mover, post the diagnostics.

Please use the existing plugin support thread:

It will work with a single DIMM, at least it should.

Stop the array unassign parity start array stop array re-assign parity start array