itimpi

Probably not relevant but it is always recommended that you do not have both the included disks and excluded disks set for a share - only use one of them and select the one that is most convenient.

If you are using an Unraid 6.12.x release have you enabled the Exclusive Share option for that share to by-pass the overheads of the Fuse layer?

It normally takes effect from the point at which you set that option. You can get the syslog off the flash after you have rebooted the server if that is more convenient. Ideally take new diagnostics zip file at that point to post and also post the syslog file from the logs folder on the flash drive.

The diagnostics you post show docker set to enabled and being started so not showing your problem. By default the syslog in the diagnostics only shows what happened since the last boot. To get a syslog that survives a reboot so we can see what lead up to your problem. you should enable the syslog server with one of the last two options set. Easiest is normally the mirror to flash option.

As mentioned in the link, have you set one of the last two options in the settings? If not then the server is just listening - not actually writing any messages. It is normally easiest to use the Mirror to flash option.

You should set up the syslog server so that we can get a log that survives a reboot to see if we can spot something leading up to your syste’ problem. The one in the diagnostics only shows what happened since you last rebooted.

If you also have parity in the array then the speed of can still severely limit writing speed to the SSD in the array thus affecting performance of docket containers and/or VMs. There is also the fact that drives in the main array cannot be trimmed and this may lead to performance of the SSD deteriorating over time if you have it there.

You should not as the shares will then look like different mount points at the Linux level but it should be easy enough to do a quick test. it is probably more efficient to use the Dynamix File Manager plugin as this avoids going over the network.

You cannot have a multi-drive pool in XFS format. It needs to be either btrfs or ZFS to have that capability.

It is often easier to set the “mirror to flash” option to get the output written to the ‘logs’ folder on the flash drive.

You get MUCH better write performance to drives in a parity protected array (often 5-10 times faster) than those that are in a pool which is the normal reason for using a pool. Nothing says you HAVE to have or use a pool.

No - this is not a supported Unraid function. Having said that I think ZFS ARC might provide something like that for ZFS pools but not sure. For the items that you are most likely to keep permanently on a pool/cache there are the appdata backup and VM backup plugins that do not provide a write-thru cache but do automate regular backups to the array.

This is meant to be happening as part of the Unraid 6.13 release. I am not a ZFS expert but I think it is unlikely as when using ZFS in the main array each drive is formatted as a single drive ZFS file system. I would love to be proved wrong

Not sure how you inferred this There have been no indications that btrfs support would be removed. The only one (that has been announced for some time) is that reiserfs support will be removed from Unraid when support for it is removed from the Linux kernel.

Yes. You would ideally only set array->cache for shares that are small enough to be held completely on the cache and that you want on the cache for performance reasons.

Not quite sure what you mean by this? Mover uses a copy/delete strategy. Also it will not overwrite files that already exist on the target as this should never happen in normal operation.

There is also the Connect plugin for automated backup of the flash drive to the cloud.

This is not normally enough to stop Unraid booting As was suggested a backup of the flash drive and a rewrite is often a good strategy. A utility such as Rufus can be good in getting the flash drive formatted correctly.

This is because you used Krusader and used a 'move' option rather than copy/delete. It means you ended by-passing the User Share system and hit the issue described in this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. You would not have gotten this behaviour if you had used Dynamix File Manager to perform the operation as it always uses a copy/delete strategy just to avoid issues like this (amongst others) that can happen even when you request a move. It would also have worked as expected if you had used a copy/delete strategy from within Krusader.

A drive will not be included in the space for a drive until there is at least one folder/file for that share on the drive. BTW: You can leave the included disks field empty if you want all disks to be allowed.

Using the share while a rebuild is going on should only affect the performance while you are actively using it - it should revert to the steady state as soon as you stop.

That log snippet suggest that the reboot happened with nothing being logged. This points towards it being some sort of hardware issue. The obvious one that springs to mind would be a power/PSU related issue or perhaps a problem with cooling. BTW: I can see that you have the Parity Check Tuning plugin installed. It would be less verbose if you set the logging level in the plugin to be the basic level (although the debug level can be useful if you want more detail on the status of a running parity check).

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.

Unraid never automatically moves files between array disks - this is always a manual operation if you want it done.

The easiest way is to make the pool redundant by adding another drive to it and running it in RAID1 configuration. However that is still not foolproof as things other than drive failure can cause data loss so you should still have a backup strategy for the data such as using something like the appdata backup plugin to make regular backups to the main array.