itimpi

Rebuilding parity writes every sector so at this point it should be correct (it is not a correcting check - but a rebuild). You can (optionally) now run a non-correcting check to ensure the rebuild was correct and I would expect 0 errors (a non-zero value would mean you have some issue that is probably hardware related).

At this point the system should be "emulating" the disabled data drive using the remaining data drives and the parity1 drive. Does the content of the emulated drive look correct? If so this would suggest that parity1 is probably good. If you do the following: Stop array Unassign parity2 Unassign disabled data drive (to ensure it is left alone) Start array to 'forget' parity2 assignment Stop array Assign parity2 Start array to rebuild parity2 based on the data drives (including the emulated one). If at all possible you want to keep the physical drive underlying the disabled data drive intact as long as possible as its contents are probably fine and therefore this is the last resort in getting its contents back. You could try mounting in read-only mode in UD to see if it mounts OK. If the above rebuild of parity2 goes well you have the option of rebuilding to the spare disk you mentioned having which still keeps the 'old' data disk intact for any recovery purposes that might be required.

It might be worth pointing out that the VM Backup plugin backs up the XML as well as the vdisk files and only shuts down individual VMs as it backs up the vdisk files. Does not mean, though, that backing up the XML as part of configuring a VM is not a good idea and probably very little effort to add. Whether the rest will be considered too much effort I have no idea although it certainly falls into the "nice to have" category.

The remote access feature of the plugin may not be quite as secure as using a VPN but it is much easier (and thus less error prone) for the naïve user to set up. The plugin does, however, have other features that you can use even if you do not intend to use the remote access feature.

Yes, The Minimum Free Space for a pool/cache is documented here in the online documentation accessible via the Manual link at the bottom of the UnRaid GUI

Most people seem to have been able to solve this issue when they encounter it by clearing the cache in the browser they are using.

What makes you think that mover is starting in these circumstances? Mover should never run unless it is a scheduled time for it or the user starts it manually. also mover has nothing to do with parity checks!

the USB stick appears to be dropping offline for some reason.

Simply copy the 'config' folder across. All user settings are contained in that folder.

Encryption in Unaid is at the whole disk level - not at any finer grain such as a folder (share) or file.

You step 1’s are not needed as the preclear process erases any partitions anyway.

What version of Unraid are you running? For UnRaid 6.8.3 there is a Minimum Free Space setting for the cache under Settings -> Global Share Settings. For the current UnRaid release (where you can have multiple pools) you set Minimum Free Space for a particular pool by clicking on it on the Main tab.

The Krusader docker container is nowhere near that large Not sure what could make it use up that much space.

There are also timeouts for VMs and docker containers if you use those?

Should show up instantly.

It is not the CRC errors that are the main concern but the very large number of reallocated sectors on the parity drive. Personally I would retire that drive ASAP.

Sounds like you are getting unclean shutdowns. Have you tried stopping the array before shutdown? There have been reports that there might be problems with the timeouts for shutting down Docker containers and VMs not being honoured leading to unclean shutdowns, and stopping the array first before doing a shutdown would avoid this happening.

What you are describing is not what I would expect. Normally a VM runs from a vdisk which is simply a file and removing that file will release irs space. However you may not get back as much as you expect vdisk files are actually created as ‘sparse’ files and so you only get back the space the file actually used which can be a lot less that’s the logical size. have you actually checked that the vdisk file really HAS been removed?

I do not think that there is a way to read FATX format on Unraid I would like to be proved wrong

The behaviour you describe is expected. The procedure for removing a dish permanently is described here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

Yes. Starting with Unraid 6.9.0 you can now have multiple 'pools', any of which can (optionally) act as a cache for nominated shares and whose names are user defined. Depending on context 'cache' and 'pool' can frequently be considered as interchangeable terms. Online documentation is steadily being updated to use 'pool' instead of 'cache' where appropriate.

No need unless your OCD bothers you running with parity2 present and no parity1.

You can continue with psrity2 and no parity1. Parity1 and parity2 use different calculations so the only way to get parity2 into parity1 would involve rebuilding its contents from scratch.

According to the syslog UnRaid is only seeing a 10 Mbps link which seems a bit suspicious? I would carefully check cabling and if possible try a different port on the router. A 169.x.x.x address is what you end up with if UnRaid is unable to contact a DHCP server for some reason.

Rebuilding a disk does nor clear an unmountable state as all it does is put onto the physical didk what shows in the emulated disk.