itimpi

The loop2 device relates to the docker.img file. i would suggest you first check the location at which it resides for any file system level corruption, and the after that Recreate the docker image file and then repopulate with previous settings intact via Apps->Previous Apps.

I would expect the VM to regularily be reading/writing to its virtual disk so that is likely the cause of your symptoms.

The disk cannot be used as a cache drive. That was one reason for mentioning a small flash drive that does not actually store anything to satisfy the requirement. You may prefer to use your 1TB drive in a pool, especially as drives in the main array cannot be trimmed.

Do you have the Appdata Backup plugin installed and scheduled to run at that time?

Are you trying to access the data locally on the server or across the network? If the latter you need to set it to be shared.

He must have at least one disk in the main array as this is a requirement with the current Unraid release (although this is expected to be removed in a future release). Perhaps he simply has the main array with XFS format disks (which is the default). In your case it could be something like a small flash drive if you do not want to store anything on it.

Do you mean that your server is directly exposed to the internet without going via a router? This is highly inadvisable as Unraid is not hardened against attack. the normal way to access Unraid from the internet is to use a VPN so the connection is encrypted. Unraid has the WireGuard VPN server built in that can be used for this, although many people find something like the TailScale plugin easier to use and set up.

You have to reboot. Memtest cannot run at the same time as any other OS (including Unraid) as it requires dedicated access to the hardware.

Are you using macvlan for docker networking? That seems to be the commonest cause for instability at the moment. Note also that passing memtest is not definitive (whereas failing is) on RAM issues. Sometimes running with the less sticks of RAM can help. The log from the syslog server might be useful in showing what lead up to the crash even though you suggest it is not showing anything useful.

Sounds to me as if your issue may not be CPU pinning, but disk I/O related. Where do you have the vdisk for the VM located - on the array or on a pool? Also since you mention docker, where are the appdata and system shares located - ideally these should also not be on the main array for best performance. You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs. It sounds as if the system may not have successfully finished starting up for some reason.

That call trace looks like it could be macvlan related. If so you need to either switch docker to using ipvlan, or alternatively disable bridging on eth0 to continue using macvlan.

Reallocated sectors are never a good sign - particularily if they keep increasing. i notice you have been doing the Short SMART test - that does not really test much of the dtive. You really need to run the Extended SMART test to properly test the drive..

That is because the link talks about the server logging to itself.

When you set up the syslog server on unraid2 you specify the location at which the server should store files.

Your parity2 disk is only 6TB so cannot add array drives larger than that until that drive has been upgraded to a larger size. You can never add array drives that are larger than the smallest parity drive..

Your system seems to be experiencing Macvlan related crashes which are known to eventually crash the server. As mentioned in the release notes you should either switch docker to using ipvlan, or if you want to continue using Macvlan make sure that Bridging is disabled for eth0.

Either would fo but mirror to flash is easiest.

The settings you have for the appdata share say it should stay on cache pool and NOT be transferred back to the array. This is normal as it maximises performance of docker containers. There is the Appdata Backup plugin available which can be used to make periodic (probably daily) backups of appdata to a specified location somewhere on the array.

Yes

Make sure you do not even have an empty ‘isos’ folder on any other drive or pool as that would stop the share being Exclusive.

The rootfs is 100% used which suggests you have something writing to RAM instead of persistent storage. running du -shc /* Might give a clue

My experience is that USB2 drives simpler last longer than USB3 ones. Since Unraid runs from RAM after initial load the performance of USB3 is not needed. Certainly getting better but not sure they are as reliable as USB2 ones. USB3 normally uses much higher chip packing so more susceptible to heat related issues. One of the other issues with USB3 is that BIOS's are still not always as reliable as one would hope in handling USB3 during the boot sequence although they are lot better than they used to be.

How much RAM do you have? I think you need at least 4GB to run recent releases of Unraid reliably.

If you can get them then USB 2.0 rated drives although they are now getting harder to source. Failing that plugging a USB 3 drive into a USB 2 socket seems to be the next best option. Many people use USB 3 drives in USB 3 sockets successfully so there is no hard and fast rule about this. If you must use USB 3 drives in a USB 3 socket then ones that have metal cases to improve cooling seem to be a good idea.