JonathanM

Easiest way is like I originally said, on your windows PC connect to the media share on Unraid and drop the files there.

Not nearly enough information to even start figuring out what you did. Krusader is a docker container, it has mappings that can be configured in multiple ways, the mapping you specifically have configured will determine where the data shows up. With that in mind, the statement "using krusader, i transferred the data", doesn't even begin to explain what the source and destination of that transfer were. Since I don't know where you put the data, I don't know how to tell you to move it to the "correct" place, on the array directly that would be /mnt/user/media since you said you set up a user share "media". Depending on your krusader mapping, that may show up somewhere totally different inside the krusader container. To begin to untangle this, I suggest telling us your krusader path mappings, the connection method for the source drive, the source path inside krusader, and the destination path inside krusader for the transfer so far.

You were warned.

Sounds like you may have rclone installed, and it's downloading a fresh copy from the internet.

No, but the VM sure appreciates being run on a faster system. Think of the KVM host as the motherboard. If you have a slow board, the fastest CPU and huge amounts of RAM don't help. VM's rely on their basic services to be programmatically emulated (created on the fly) by the host. Choke the host, the VM suffers. All these folks trying to absolutely maximize the amount of resources they allocate to their VM guests are shooting themselves in the foot. For tuning purposes, give the VM the absolute bare minimum it needs on the box spec, and slowly add more until performance no longer improves. The basic I/O for the VM is all being handled by the host, and as is obvious to anyone who has swapped out an old spinner hard drive for a SSD in a bare metal box, I/O is pretty much the limiting factor in how fast a machine feels. Adding CPU horsepower and extra RAM doesn't help at all once the basic need for them has been met. All the RAM and CPU you allocate to the VM are locked away from helping the host perform, pretty much being wasted. Linux does a really good job with "extra" CPU and RAM, it's a whole lot better to let the host have them.

My best guess is that the BIOS is broken for multiple GPU's. Check to see if your motherboard has an update available.

Assuming a gigabit network, the speed isn't going to be much different. Personally I'd do it over the network, less risk.

To access your BIOS now you will need to plug a monitor into whichever output your motherboard chose to use as primary. Some motherboards will allow you to choose which card it uses, others are arbitrary. It's not under Unraid's control.

Normally this means that you have multiple video outputs, and the BIOS is sending video to a different port. You haven't given us any clues to go on, so that's just a guess.

I use them to have a purpose built desktop I can access from anywhere. It's like having the ultimate multi boot machine, you can have a MS VM for the few things where it's the only way to get something done, you can have a super lightweight linux with VPN and no social media or email accounts that you can drop into when you need to research something you would rather not have show up on your everyday footprint. Pick a desktop task that doesn't involve super heavy graphics, and I'll build a VM that I can nomachine or otherwise remote into from anywhere in the world securely and be at MY computer.

Yeah, I wish. Unfortunately the reality of things is that once Unifi moves on, so must I. Otherwise eventually I'm not going to be able to support the newer radios as they are released. It's wishful thinking to believe I can stay on this release forever, but I can always dream. I'm just hoping that when LTS moves, it's to a tried and true version rather than opening a can of worms. At least that's the idea behind LTS, something you can rely on to stay working for the Long Term.

@Jessie already addressed this, but it's important enough I need to add my emphasis. Unraid uses ALL the drives for parity protection, not just the parity drive. If 1 drive fails, all the other drives in the array must perform flawlessly from end to end to rebuild the failed drive, not just the parity drive. You will be relying on your hand me down drives to protect the data. They must all be perfect. Even more so than a typical system, where the only spots on the drive that matter are the ones that actually contain data, unraid requires the entire capacity to be perfect across all remaining disks. You must weed out any weak or failing drives before using them in the parity protected array, and vigilantly replace any that start to fail, so you don't get in a situation where a failing drive causes a weak drive to fail in the middle of a rebuild of the failed drive. https://wiki.unraid.net/Parity

Research "nat loopback hairpinning reflection" and see if your router can support it. If you can't get your router to cooperate, the best answer I can think of is a manual hosts entry in each effected device.

That looks completely wrong to me.

Just for completeness, the LTS is currently 5.6.42, which has been extremely stable for me. I'm dreading being forced to change eventually, I have too many sites that I support with it. Right now I have 7 different physical locations with 15 access points of various flavors and configurations.

I have my jitsi stack on one unraid server and my letsencrypt is running on my main server. It's not that difficult to divorce.

The concept of path mapping in containers is hard to explain, and even harder to understand, until it clicks. Then it's easy. It's one of those light bulb moments, we've all been through it. Check all your containers, make sure they all have the exact same container side mappings for shared array resources. Most of the time the problem is the download location where one of the *arr apps sends a request to a downloader, and the *arr expects the file to end up in a subfolder of /downloads and the downloader sees the same array location but it's mapped to /data instead of /downloads, so the *arr can't find it. Now you can help explain it to others who are struggling.

Your entire issue this whole time has been not understanding path mapping. Each container has a section in the configuration where it has host and container paths. Whatever path you put in the host side shows up inside the container at the container path. Think of each container as it's own little operating system, with it's own directory tree that doesn't correspond in any way to unraid. When you add a mapping, it shows whatever file path is on the host side at the container side. Krusader has a host path mapped to /media, SabNZBD doesn't. https://forums.unraid.net/topic/57181-docker-faq/?tab=comments#comment-566086

mc (Midnight Commander) is available in the Unraid console http://trembath.co.za/mctutorial.html A disk successfully mounted with Unassigned Devices plugin will appear in the /mnt/disks/* path, your array shares that you define will appear in the /mnt/user/* path. You can directly access individual array disks at the /mnt/disk1 /mnt/disk2 /mnt/cache etc paths. Since the individual disks all participate in the user shares, it will appear that data is duplicated between the /mnt/diskX and /mnt/user paths. DO NOT copy or move between the two, they are the same file presented in two different views. Files in the /mnt/disks/ paths can be copied to either /mnt/diskX/share or /mnt/user/share.

Reading back over this, I caught a couple things I missed the first read through. It sounds like you only have a single computer, not a windows machine and a second computer you are setting up for unraid. If this is the case, then I'm very uneasy about your plan to migrate data, I'm not at all positive that a degraded NTFS RAID member can be mounted in linux or read outside of a windows installation. I googled for answers, but didn't find a good solid positive response about an intact NTFS RAID set, let alone a degraded set. Single NTFS disks, sure, but nothing about RAID sets. Second, you clearly state So, at the very least, before you even attempt this, I second @Abzstrak's recommendation of backing things up in total to a USB external drive. At least that way you can recover without massive downloads from spideroak.

https://wiki.unraid.net/The_parity_swap_procedure

What you have outlined may work, but has a high risk of failure due to any number of things going wrong. Windows RAID or Unraid do not mean you have a backup, it's high availability where a drive failure can be tolerated without losing data. You are proposing operations that can cause data loss quite easily just by typing or clicking something incorrectly. I STRONGLY recommend not breaking the Windows RAID until all your data is copied (not moved) safely to Unraid. That means purchasing more storage drives, but most people running Unraid need more storage fairly regularly anyway. If you purchase 2 8TB drives, assign 1 as parity, 1 as data, you can copy all your files and continue to use your current drives as a real backup, one that can survive various oopsies that don't involve drive failure.

As a test, back that down to 2 of 8 and see how the VM performs.

Try both, one at a time, see which one works better for you. It's not like it's a huge space or time investment to have both installed, just stop one before you start the other. You could even run them simultaneously if you deconflict their ports. Go to their support threads and see what issues people are having, and how they have been resolved.

Yep. I currently use the built in windows backup on my token microsoft VM, and urBackup on my linux VM's and the windows VM as well. All pointed to shares on an Unraid box. Flash backup is done as I described earlier, cache is much more complicated. Open files are difficult to back up reliably, and most people use their cache drive as a spot for things that keep files open. That's why I use the appdata backup plugin and internally back up my VM's.