itimpi

Have you checked that SSH to Unraid is working locally to Unraid? Is SSH configured to be available under Settings => Management Access? There is nothing in Unraid that should block SSH if it is enabled in the first place.

Removing disks from the array is covered here in the online documentation accessible via the 'Manual' link at the bottom of the Unraid GUI.

Can you read anything of the old flash drive? Everything that is specific to your system is stored in the 'config' folder on the flash drive. If not, then do you have a copy of your licence file? This will be needed to transfer the licence to a new flash drive. If not then need to contact Limetech by email to resolve this. The chances are that all you data is intact although one cannot be sure after RAM errors. Do you know which driver were parity drives and/or cache drives? If not then we can walk you through the steps that should help work this out. However if you cannot get the contents of the 'config' folder then at the very least you are going to have to reconfigure any docker containers or VMs. A bit late now, but it is worth pointing out that you can always make a downloadable backup of the flash drive by clicking on it on the Main tab and selecting the backup option. Always a good idea any time you make a significant change just to cater for scenarios like you currently have. The CA Backup plugin can also be used to automate taking backups of the flash drive and docker container files.

In Unraid no data drive can be larger than the smallest parity drive. The procedure you want to use in your scenario (upsizing parity drive and then using old parity as a replacement data drive) is what is known in Unraid as "Parity Swap". The steps to achieve it are described here in the online documentation accessible via the 'Manual' link at the bottom of the Unraid GUI.

The only way to do this would be to not have it in the array. Parity always covers all array drives. If you are going to use it then you are probably best using it as a drive managed by the Unassigned Devices plugin.

I believe this is an btrfs artifact of the space being reported incorrectly when you have a pool with drives of different sizes in a raid1 configuration.

Unrar is not installed by default. if you have Nerd pack installed have you actually activated the option to install unrar from its settings.

At the moment I am not prepared to implement an option that would auto-pause the parity check that happens after an unclean shutdown. the implementation I am currently testing will auto-pause a restarted array operation that was paused at the time of a shutdown, but that will only happen after a clean shutdown. As soon as an unclean shutdown is detected then the decision is to err on the side of safety. if I get convinced that an auto-pause of the automated check after an unclean shutdown is a feature would be desirable then it could be added but it is not going to be in the next release I make.

Not an answer to your query but it might be worth using WireGuard rather than OpenVPN-as as the way to allow secure access to your server from outside your LAN. The WireGuard server is a standard part of Unraid (from 6.8.3 onwards) and has the advantage that it can be used even when the array is not started and when Docker is not running.

Probably worth posting a message in the relevant container's support thread or on their area on github. Quite likely the maintainer will then get around to updating the packages within the container.

Have you followed any of the steps documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI? the diagnostics seem to be after a reboot so we cannot give any feedback on what might have caused this. The SMART information for the drive looks OK so that tends to suggest that something external to the drive happened.

My experience with using ffmpeg is that software re-encoding to x265 produces files that are significantly smaller than when using hardware re-encoding. That is worth bearing in mind when trying to maximise space savings. It becomes a size v speed trad-off as hardware re-encoding is MUCH faster. in turns of docker based tools on Unraid to make this easy, my experience is that Unmanic is least effort, but tdarr provides finer grain control for those who want to invest the extra effort.

Yes - restarting in normal mode and the disk should mount fine with its data intact.

You need to run without the -n option and with the -L option. The warning always pops up but virtually never leads to any data loss, and at worst only affects the last file being written.

Replacing a parity drive is no different to replacing a data drive. the steps that are sure to work are: stop array unassign parity drive start array to forget old assignments stop array assign new parity drive start array to build new parity on the new drive i think steps 3 and 4 are probably not needed but they will do not harm.

There have been some research papers that show that BTRFS has a much higher write amplification than any of the other common file systems. Why I have no idea, but that is what the data shows.

As I said I think it works if you map to a User Share rather than a physical drive.

Hard links cannot normally be moved between mount points which implies that they cannot be moved between drives when set up at the physical drive level. If appdata is mapped to /mnt/user/appdata rather than /mnt/cache/appdata it just might work because at that level drives should be transparent. I have not tried it so that is just a guess.

Have you checked that there are files on the cache - if so which ones? The used space will never go to zero as there is a basic overhead because it has been formatted with a file system.

How are you setting the IP address? The normal recommendation is to have Unraid set to use DHCP and then reserve the address for Unraid at the router level.

Are you rebooting your router so that it releases the IP mapping for the old card?

Cache is treated as 'lower' than any array disk. I guess the question is why has this happened? It suggests at some point the cache disk was not online when the array was started so a new docker.img file got created on the array. Looking at the dates on the files might give a clue.

Have you tried spinning the drives up first? It is expected to get * in that column if the drives are currently spun down.

Just for interest what do you think of a suggestion that I made elsewhere that instead of referring to ‘cache’ we (and the GUI) should start referring to Pools? The introduction of multiple pools in 6.9.0 would be a good time to consider this if it is thought to be a good idea.

Glad to get agreement on this The basic assumption I am working to is that automated actions involving the whole array should only be attempted when it appears to be completely safe. If in doubt avoid the automated action and get the user to take any needed action. After all running automated array operations when in doubt and causing any sort of data loss as a consequence would be deemed completely unacceptable in my view