itimpi

The relevant UD device is not online, has not been mounted or has failed as /mnt/disks is where local UD devices get mounted. I assume that the vdisk image on disk1 is just your backup?

In what way? As long as the disk had been previously formatted then a file system check/repair would be expected to recover any content.

You probably want to start with this section of the online documentation accesible via the 'Manual' link at the bottom of the Unraid GUI.

A good reason to be using the Parity Check Tuning plugin so the check runs in increments outside prime time. The length of checks with modern large drives was one of the main reasons the plugin was developed in the first place.

The 45% refers to the amount of the Docker image file space that is used - not the RAM use (which is at 7%),

It is recommended to put appdata on the cache both for increased performance of Docker containers and also because it can mean that array drives can then typically be spun down a lot of the time,. Many people then use the CA Backup plugin to do periodic backups of this share to the Main array, Mover is really designed for idle hours so running it overnight is more typical.

It looks like you have exposed the Unraid GUI to the internet (on ports 80 and 443)? This is not a good idea as Unraid is not hardened enough against access. It is recommended that if you want secure remote access from the internet you use a VPN (such as the WireGuard VPN that is built into Unraid) or alternatively the Remote Access features of the My Servers plugin. Your syslog shows lots of attempts to connect from address 192.168.87.104 which is on your local LAN which is probably what triggered the warning. Is that your PC?

Cache is just a special case of using a pool so use the option to add a new pool. You can call it anything you like. You then configure whether shares should any particular pool for caching purposes at the individual share level. Some of the confusion may have arisen from the fact that prior to the 6.9.0 releases there was only one pool allowed and its name was always 'cache'.

This suggests something went wrong during the preclear so that Unraid does not recognise the drive has been cleared.

There i think there is s some ambiguity with your description When you have pre-cleared a disk then as long as you add it to Unraid at that point then it should be accepted immediately and show as umountable because it has has not yet been formatted and Unraid should be offering the format option. You also mention then formatting it in UD - this should not be possible if the drive is currently part of the array as it should no longer show up under UD.

This is exactly what Parity Swap is designed to handle - installing a larger disk as parity and using the old parity drive to replace a failing drive,

Well the last Diagnostics you posted had it set to pool? maybe you should delete all the superfluous .cfg files on the flash drive in the config/shares folder that refer to Shares you do not/no longer have and then post new Diagnostics so we can check this out.

Did you remember to change the 'appdata' share settings to no longer refer to 'Pool'? Note that t is quite valid with the 'Prefer' setting to refer to a non-existent pool that you might later add to the system.

You need to simulate disk6 failing to be able to replace it with the 12TB, so you can do the following: - stop array - unassigned disk6 - start array to ‘forget’ disk6 and act as if it failed. Unraid will say disk6 is now being emulated, and the emulated disk should show the contents of what was disk6. - stop array - assign 12TB as disk6 and Unraid should now be offering to rebuild disk6 onto the 12TB drive. - start array to begin rebuild Your procedure omitted the ‘forget’ steps to simulate a failure and trigger the rebuild process.

The default locations are set in what I would think are the obvious places They are under Settings->Docker and Settings->VM manager. if you had any docket containers referring to the UD location they would need changing.