JonathanM

Try deleting the /mnt/cache folder, disable the docker service, not just stop the containers, and restart.

The folder referenced in the title of your post, /mnt/cache

What is the content of the folder?

If you disable the docker service and restart does it come back?

Keep in mind that running Unraid as a VM is not supported, if you have issues it's on you to solve them. It's not forbidden, plenty of people do it, but if you have a problem you will be asked to recreate the problem running Unraid bare metal before it will be considered an actual issue that the developers need to look at. There is a section of this forum dedicated to users helping each other with virtualizing Unraid.

Are you using bridge mode?

As much as you can give it. The host RAM is used to cache disk access, so the more RAM it has, the better it will perform. https://www.linuxatemyram.com/

Do you have any ports exposed to the internet? Is there a proper firewall in place between your public IP and Unraid?

For best performance start at the lowest amount of RAM that will allow the VM to boot successfully, and add RAM in small chunks until the performance doesn't increase any more, then back it down to the last amount before it topped out. The host needs the RAM to emulate all the I/O and motherboard functions, so the more you can give to the host without slowing down the guest will give the best overall performance. RAM allocated to the guest is totally gone from the hosts viewpoint, so the more you can give to the host the faster virtual hardware you will be running on. You wouldn't intentionally cripple a bare metal PC by giving it the slowest motherboard you could find and maxing out the RAM to compensate.

It is an issue, usage doesn't matter, any RAM allocated is denied to the host completely. Try setting the windows to 8GB and the linux to 4GB and see how they perform.

You can do it simultaneously but it will be excruciatingly slow. Why not just remove the disks all at once and rebuild parity one time with the final complement of disks?

Maybe when you finalize your directions to yourself, use Slot instead of Disk when referring to the logical positions, and fill out the last 4 of the drive serial numbers so you keep it straight in your head and can cross check things. For example, select slot 1 and assign disk A54E or something like that. Also, I suggest actually committing a document to print after verifying all your steps, then physically cross things off the list as you do them.

Why? If you are retiring the disk, why not just leave slot 9 blank, and NOT check "parity is already valid" so it calculates parity from the disks you wish to use? The only other gotcha I see is if files are added or modified while the copy process is running you may not have the full up to date copy. You can either stop all the things that could write to the disk, or use rsync to verify the copy and list differences until the verify is perfect. It's not a bad idea to verify the copy anyway, but not the end of the world since you are keeping the old disk(s) intact as you go.

Download the latest and overwrite everything EXCEPT the config folder.

Attach diagnostics to your next post. syslog is included in diagnostics.

Yes, you can't use parity to rebuild to a smaller disk. You will have to set a new config in tools, then recalculate parity after switching the disks.

So you have the license *.key file that was issued for the broken stick? All you need to do is copy that file into the config folder of the new stick and delete the trial.key, then the registration wizard will step you through blacklisting the old key and getting a new one to match the current stick.

It's not measuring RAM, it's showing how much of the docker image file is in use. All three of the non-RAM items are percentage of allocated storage in use.

Familiarity, greater control, etc. Mostly just personal preference and fear of learning new stuff.

Why? There are good reasons to let all the new writes go to the new disk. Usually newly added data is going to be accessed most frequently, and disks are much faster on the first bit compared to when they are almost full. User shares have no issues combining all the data seamlessly.

Short answer, no, there is currently no way to add limited access GUI users. Since docker start stop and restarts are easy on the command line, you can do scripting that looks at a user accessible share location for input. Updates are probably possible, but I have no experience doing updates from the CLI. The script would watch for and act on the existence of a specifically formatted file to show up or change in a user share location. The user would connect to the SMB share that has permissions for that user to create or modify files, and manipulate the file(s) the script is watching for. As a quick example, you could look for the existence of a file named restart.txt, when found the script would restart the container and delete the restart.txt file.

Set up a new VM, get it running to your satisfaction, then add the corrupt vdisk as a second disk to that new VM.

Blue link "manual" in the bottom right of the Unraid GUI

diagnostics will contain that info

https://forums.unraid.net/topic/38582-plug-in-community-applications/?do=findComment&comment=1397593