itimpi

If you want to continue using macvlan then you should make sure bridging is disabled on eth0.

If you need to use power splitters, then I have found that Molex->Sata are more reliable than sata -> sata.

Do you use power splitters to get the power to the drives? I have found these can often cause problems.

This is actually very easy and is much quicker than you might think.. Follow the instructions to recreate the docker.img file and then reinstall your containers with previous settings intact via Apps->Previous Apps.

The loop2 device is the docker.img file and it looks like that is corrupt. I would suggest recreating this file and re-installing your containers with previous settings intact via Apps->Previous Apps. Before doing so run a scrub on the cache pool to check that there is not corruption at that level as that would need fixing first.

It looks like the device reporting issues is an Unassigned Device (/dev/sdi) rather than an array or pool device? There IS a message in the syslog about a failure to read a block from the flash drive but I wonder if that is a side-effect of the drive showing problems (particularly if that drive is connected via USB) rather than a genuine problem with the flash drive. You could try the process described here in the online documentation to rewrite the bz* type files - it will not do any harm and sometimes fixes being able to read marginal blocks from the flash drive.

You might want to also enable the syslog server to get a syslog that survives a reboot so that if you do get another crash we can see what happened leading up to the crash.

The loop2 device is the docker.img file which appears to be corrupt. You should recreate it and then reinstall your containers via Apps->Previous apps. It might also be worth running a memtest as this is a common cause of corruption in btrfs file systems

Have you tried clearing your browser's cache?

If the server reboots itself this suggest a hardware issue. The most likely culprits would be a cooling issue (so CPU overheats) or inadequate power.

The diagnostics suggest that there is severe corruption on the cache which probably explains your issue. There are some "Critical Medium" type messages which may mean it is playing up at the physical level. Chances are that the files that have not moved are lost or damaged beyond repair.

A drive only gets the red ‘x’ when a write to it fails. This can be for all sorts of reasons some of which can be external to the drive.

it looks like you are getting macvlan crashes, and these are known to eventually crash the server on the 6.12.x Unraid releases. The easiest thing is to switch docker to using ipvlan networking. If you need to continue using macvlan then make sure you disable bridging on eth0 as mentioned in the release notes.

Make sure you got an immediate automated acknowledgement when you tried to contact support. For some reason this has not always been happening.

According to your diagnostics all shares that have files on the ‘cache’ pool are set for mover to transfer files to the array. Nothing should be attempting to transfer the other way with current settings. The default settings for the ‘appdata’ and ‘system’ shares (which you must have changed) try and keep all their files on the cache pool as this gives far better performance of docker containers and avoids spinning up array drives unnecessarily. Note, however, that files for these shares can only all be moved successfully if the docker service is disabled as it keeps files open and mover will not move open files.

Since you do not have the NerdPack plugin installed these will not be used (and can be deleted).

How any share uses a pool for caching depends on the share settings. Since you could not get the diagnostics we cannot check what settings you have. in normal operation you would not get duplicate files. If you do end up with duplicates for any reason then it is a manual process to decide which copy to keep and delete the unwanted copy.

The syslog in the diagnostics is the RAM copy that only shows what has happened since the last boot. To get one that survives a reboot and can show what happened leading up to a crash you need to have enabled the syslog server.

Then that is strange as if that was the case they should have included information from before the crash whereas they seemed to only include information since the last boot.

With those settings the syslog file that survives a reboot will be put into the 'logs' folder on the flash drive.

According to the diagnostics you have the docker service disabled.

Not sure I understand your question? You cannot use a random port within a docker container - you need to be using the ports the docker developer has set up the container to use.

Macvlan crashes are known to eventually crash the server on the 6.12.x Unraid releases. Ideally you should switch to using ipvlan, or if you need to continue using macvlan make sure you follow the instructions in the 6.12.5 release notes.

Yes, although strictly speaking the last is optional.

a mistake - I meant the docker service.