itimpi

Normally all of it to save asking for different parts when trying to check things out - It is not that large a file

I think you are fine, but that was why I suggested you make sure you first backup the flash as that means you can revert and try an alternative update process.

the easiest way for this to happen is to use the ‘mv’ command from the CLI (or an equivalent from Krusader) and the fact that the Linux underlying Unraid does not understand User Shares. Linux tries to optimise the move operation if it thinks both source and target are under the same mount point by first trying a rename and only if that fails doing a copy/delete operation. This means you can get the rename working and leaving the files on the same drive but under a different folder. Using an explicit copy/delete avoids this. it might be easier to simply have the ‘media’ share set to use the cache and have the Minimum `free Space setting on the cache high enough that you never completely fill it.

The “Prefer’ setting is fine for the ‘Use Cache’ setting as that will use the array if you do not have a cache drive, and if you later add a cache drive move the files onto the cache. what could cause your symptoms is if you have something mapped to ‘/mnt/cache/appdata’ If you do not have a cache drive that location is in RAM which would explain why you lose it on reboot.

You might want to work out why the files ended up there to stop it happening again? It can happen if something is run that can by-passes the UnRaid User Share system. you mentioned you deleted the files which removes them from the ‘media’ share as even with a ‘Use Cache’ setting of ‘No’ UnRaid would treat them as part of the User Share for read purposes. If you wanted instead to keep the files you could have instead changed the “Use Cache” setting to “Yes” and then run mover which would have transfered them onto the array.

The problem arises when a different drive fails. Unraid reads all data drives plus parity to successfully rebuild a drive. If the the drive is really dead then you may just get away with the rebuild if you have dual parity. If it is not dead but just unreliable then it may return bad data during a rebuild which would result in the contents of the rebuilt disk having some level of corruption (and where may not be obvious).

You can always upgrade manually by downloading the zip file for the release from the Unraid site and extract all the bz* type files overwriting those on the flash drive. Before doing so I recommend backing up the current contents of the flash drive just in case any problems occur.

It is quite common for upgrading via the GUI to fail if you only have 2GB of RAM. You normally need 4GB or more for this to work. You can upgrade manually by downloading the zip file for the release from the UnRaid web site and then extracting all the bz* type files overwriting those on flash drive.

The process is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

I assumed that the speed shown in the memtest display is what the RAM is set to run at? Are you suggesting that display may not be accurate?

CRC errors are connection issues that will cause read/writes to be retried which will often recover the transfer but will definitely slow things down. Occasional ones are not much of an issue but large numbers definitely are.

The zip file you get from using Tools->Diagnostics from the GUI

I thought the maximum officially supported RAM speed on that CpU without over-clocking was 3200MHz? Could be wrong about that though but it might be worth checking out if you have any stability issues.

There is no requirement in a dual parity system that the parity drives are the same size - just that they cannot be smaller than the largest data drive.

No, it is perfectly acceptable for different containers to have the same mount point. I think it means you are trying to map it twice for the same container. Make sure you can see all mappings for each container.

In theory you should not need to if you do not want to use GUI mode on a locally attached monitor.

If you provide your system’s diagnostics zip file (obtained via Tools->Diagnostics) we can probably give a definitive answer.

I think that means you have attempted to map something to /data twice for the same container

have you tried installing the ‘Intel GPU TOP’ plugin to activate Intel drivers for the iGPU?

There was a write error that the normal retry mechanism was unable to correct. In such a case you need to rebuild whatever disk reported that error.

Have you enabled "Destructive Mode" in the UD settings? This is required before UD will allow you to format disks.

You can stop Unraid from using the nVidia card by isolating it at the VFIO level. If the Intel part is an iGPU then installing the 'Intel GPU TOP' plugin should enable the driver for that card when booting in GUI mode if you want it to use that on a locally attached monitor (although it sounds as if this is not the case?). There is a corresponding plugin for nVidia cards but since you want the VM to use that card the VFIO approach is the way to go.

It cannot be quite that simple as the default assumption would always be that a 'failed' drive will be replaced.

Assuming the drive is OK I am a bit concerned about your reference to a "New Disk" In such a case you should be following this procedure from the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

Yes. Instead of formatting the disk you should have followed the procedure documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI for handling drives showing as unmountable.