JonathanM

Try a different USB stick. It's possible the GUID for the stick you tried isn't usable.

This video is rather old, but covers the basic principles. "Cache yes" terminology is not used anymore because it was confusing, it's been replaced by primary and secondary along with the direction mover should act.

https://forums.unraid.net/topic/82198-support-binhex-urbackup/?do=findComment&comment=918119 pinned post in the support thread

I strongly recommend not doing this. There are many reasons, but the most important in my mind is the need to evaluate the entire situation before allowing the server to come back up. If you are not on site to make that evaluation, there very well may be circumstances that you are not aware.

Try creating a new VM, but point the primary vdisk to the existing file.

ZFS is the reason, IIRC. different share = different dataset

Probably. You should test each DIMM by itself.

UrBackup is what I use.

try changing raw to qcow2

You are checking the emulated drive. Instead of polluting the plugin support thread, please start a new thread in the general area, include your diagnostics and a link back to your post here so anyone wishing to help can see what's happened so far.

Do not post copyrighted material in this forum.

Do a filesystem check using the GUI, on the main tab click on the Disk #.

How do you know it's dead? The majority of the time Unraid fails a drive is because of a cabling or power issue, dead drives are relatively rare. When a write fails, for whatever reason, Unraid disables access and emulates the data using all the rest of the drives. See if you can get a SMART report on the "dead" drive, and see if it will mount in the Unassigned Devices plugin.

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.