JonathanM

root is the only option

First order of business is to get that static IP available on a wired connection, you may need a physical bridge connected to a normal router, or possibly you could configure a router to use the WAP as the WAN connection. Then you can set up your own network with NAT and port forwards as needed. In no case should the public IP be configured directly in Unraid, the public WAN address should be on a separate router.

Containers only have access to paths that are mapped. Take a look at your Krusader container template screen, specifically the path mappings. The host side references the Unraid location, the container side shows where that content will appear inside the Krusader app.

The biggest issue is with the connections being pulled at an angle. The SATA connector is very touchy, and if you force the cable off to one side, chances are eventually it will start making an intermittently bad connection, heat changes and vibration accelerating the movement instigated by the constant pulling force. Ideally if could physically removed the hard drive without touching the cable, the cable would naturally stay in the same spot it was connected to in empty space, indicating no forces are acting on the end of the cable. Letting the cables relax and fall where they want is usually the easiest way to ensure nothing is pulling the cable out of alignment.

Unraid isn't intended to be your daily driver, it's supposed to be an appliance that hosts stuff. You should be setting up a VM to be your daily driver, and keep the Unraid space light, since it runs completely in RAM. I get that everyone uses Unraid a little differently, and there are needs for customizable extras, but throwing the modern unix book at it is the wrong approach IMHO. You should be focusing on REMOVING as much as possible, and only leaving stuff that needs to be there to allow the box to run itself to the greatest extent possible. You shouldn't need to be working at the Unraid console, it's insecure since everything is root. Automate everything you can and lock it down.

Select the vdisk image of the VM you wish to operate on as the hard drive of the temporary VM you are using to run the rescue boot media.

Do some google searches about KVM memory ballooning and see if you get an idea for why you are seeing what you are. For the scenario you are describing, I'd leave RAM at 2048 and call it a day. The host can make much better use of the the RAM than the guest to make the guest run smoothly. Keep in mind any RAM allocated to the guest is locked away from the host, which could have used it to cache I/O and make the rest of the guest emulation better. Only give the guest the minimum necessary CPU and RAM, so the emulated motherboard and other resources are as fast as possible.

Which nextcloud implementation are you using? The official one has been referenced as being much faster than some of the other containers.

Attach diagnostics to your next post in this thread. Do you have a list of which serial numbers were assigned to which slot before this happened?

I've been out of town, but yes, if the drive serial numbers are detected identically between both systems, you can just move all the drives and the USB license stick to the new box and it will detect them exactly as they were.

https://serverfault.com/questions/1030260/migrate-windows-guests-from-virtualbox-to-kvm-without-re-activation

By design files only exist in one location, either the array or one of the pools. If your pool is configured with multiple drives in a healthy fault tolerant configuration like RAID1, then a device failure should be covered. In any case, pool or parity array, important files must be backed up elsewhere. RAID or Unraid is not a substitute for backups, it can't help with file corruption or deletion, only disk failure. In my opinion for VM's you should be using the same strategy you would use for a regular desktop, where you have a backup client on the OS itself, be it windows backup, acronis, or whatever.

Have you tested the actual throughput?

Probably because after the main Unraid update, the nvidia plugin needed an update as well, and it was not completed and running when plex was started, so the container errored out as it was missing the nvidia bits. After you make sure the nvidia plugin is up to date and working, selecting plex in the previous apps section of CA should put you right.

Please see Q4 on https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Specifically the very last bit.

Where is the mapping for 9080?

Script whatever changes you need and set the script to run every boot?

Have you tried unpacking to a non-encrypted drive just to test? Perhaps the encryption is too much overhead.

It's quite easy to understand. From the front door you go up half a flight of stairs to get to one side of the house, and down half a flight to the other. Easy peasy.

If the drive in question is formatted BTRFS, it should just work regardless. If it's XFS, make sure the pool you assign it to only has one slot, if there are more than one drive slot defined, XFS isn't an option, and it will ask to format it to BTRFS.

I can't remember if there is a guide, but here it is in a nutshell. 1. Shut down the Windows 10 VM fully, hold down the shift key while clicking the Shut Down item. 2. On the VM page, click on the name text of the VM, it will drop down a list of the attached disks. 3. Click on the 70GB text in the capacity column, and change it to 90. 4. Boot the VM back up, go to disk management, and expand the partition to fit the new vdisk.

Make sure that the words "DOCKER" and "VMS" are NOT visible at the top of the GUI, then run the mover. You must disable the services, not just stop the containers and VM's.

That is the same as /mnt/user/downloads When you create a folder on the root of any of the array drives or pools, it is a user share. That's how user shares work. If you don't want a downloads share, you will need to set up a pool only share with some other name, and put downloads inside that share, like /mnt/ssd/othersharename/downloads

Does docker run say it completed successfully?

"direct access" can have different meanings to different companies. It may be equivalent to IT on some, but not others. The issue is without testing your specific card and settings it's tough to make recommendations, so the safe thing is to specify HBA IT only. It's entirely possible to think everything is fine until you replace the controller and find your partitions no longer align, and come up invalid. We see that scenario fairly regularly. Slight serial number modifications are common as well, so Unraid loses track of which disk is assigned to which slot, causing needless stress as a new config is needed to put them in their slots and tell Unraid everything is fine, go about your business with these new serial numbers.