itimpi

This is normal if you boot in UEFI mode as the version bundled with Unraid only works with legacy boot. If you want a version that works with UEFI boot (or if you have EEC RAM) then you can download it from memtest86.com.

It’s not the appdata folder that is the issue - but the docker.img file that is full. Normally this indicates that you have a docker container writing to a location internal to the image file rather than to a location mapped to be external to the container. in the short term you should delete your docker.img file and then restore the apps using Apps->Previous Apps. You then need to investigate why the docker.img file ran out of space in the first place. While if you have a LOT of containers this could simply mean you need a larger docker.img file that is unlikely the cause of the issue so you want to track it down to stop it reoccurring

I would also recommend that you consider uninstalling the old version of Preclear that I think you are using and switch to the plugin version that is an add on option to the Unassigned Devices plugin.

The problem is that the logs in the diagnostics only show what has happened since you rebooted as by default they are only held in RAM and are thus lost on reboot. To get a log that survives a reboot you should enable the syslog server so that if it happens again we have more to work with.

I tested with Autostart of the array set to No, and the VM still autostarted when I manually started the array. It appears that it only works once until you next reboot.

Strange - the Shutdown button just invokes the shutdown command as far as I know. It might be worth enabling the syslog server to see if you can get some logs that survive a reboot. it might be worth looking through this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI to see if any of it applies to your system.

The overall SMART assessment can never be relied on Any time you get. Non-trivial number of reallocated sectors or pending sectors I would not be happy with the drive. I would suggest trying the extended SMART test - if that cannot complete there is rarely any point in continuing with the drive.

I have just slightly reworded the linked post to make it clearer that you do not need the plugin with 6.10+.

Note I said FIRST start of the array after booting. You did not mention rebooting in the above sequence.

No - just checked and if this is the first start of the array after booting then the VM IS auto started.

In my experience this works if the array is auto started on boot.

All the files in the zip are text files so you can examine them yourself to see if you are happy with Unraid’s anonymisation of the contents.

It might also be a good idea to activate the syslog server so that even if you cannot get to the GUI you should have a log of what lead up to the crash.

Run without the -n option (and if it asks for it add the -L option). After that you should be able to restart the array in normal mode and I would expect all the data to be intact.

Have you set the Minimum Free Space setting for the shares in question. This can help with telling Unraid when it should instead use a different disk for a file.

Have you set a Minimum Free Space value for the cache drive to stop it getting too full? BTRFS file systems to be prone to corruption if they run out of free space.

I do not see much point in adding x3270 which requires X support which Unraid does not have, but maybe c3270 might work.

I would say that drive could well be on its last legs To use with Unraid you want the pending sectors to be 0, and a stable (small) number of reallocated sectors.

Could not spot anything in the logs that indicates your server is not running as expected. Can you access the GUI and User shares OK over the network?

Have you checked whether the folder (even if it is empty) exists as that is enough to get those symptoms. one way that should clear it is temporarily set the Use Cache option to Yes and then run mover. After that you can reset to what you want long term.

The big difference is that pools can participate in User Shares (including the ability to act as a cache) whereas UD devices cannot. UD devices are therefore more geared towards removable devices.

The problem I see is that with combinations of Linux kernel and Samba updates in new releases there may well be changes affecting this that are outside Limtech’s control and difficult to identify and correct and thus re-occurring stability problems in the capability. The advantage of using a docker container is that it can provide a stable environment independently of changes happening at the host level.

There have been good reports of the Time Machine docker container functioning well so this might be a good alternative. Cannot very it myself as I do not use a Mac.

You can do what you want using this procedure from the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Yes.