JonathanM

Have you watched this?

To be fair, most of the issues are because of hardware incompatibilities, poor documentation, or lack of understanding on the users part. I'm not saying Unraid is trouble free, but with the vast array of differing hardware, it's hard to cover all the different contingencies, and the documentation consistently has lagged behind the product. There are some hardware combinations that just don't work, but it's impossible to figure that out beforehand, so we just have to offer the best guidance we currently have, and hope to fix as many issues as possible, but there are some things just not under Unraid's control. Marvell and realtek's consistent disregard for the linux community in favor of microsoft is one example, there are many others. For the most trouble free experience, find someone who is successfully doing what you want to accomplish, and copy their build. Unfortunately because of the fast moving nature of the PC business, it's difficult to post recommended parts lists, as that info is out of date within weeks or sooner sometimes.

Do you have any containers with custom IP addresses?

That'll do it.

Do you have any containers with macvlan IP addresses specified?

For some motherboards, the various ACS override functions can help break up groups, but that's not a guaranteed solution. Moving physical cards to other slots may also be needed, and in some cases the motherboard is simply incapable of separating them, meaning a different motherboard would be required. First try the various combinations of ACS overrides and see if you get any better results.

I could be off base, I'm far from expert on VM passthrough, but that screen sure looks like something is incorrectly writing to the video RAM addresses. Are you using a video BIOS file currently? If so, was it dumped from that exact physical card?

Not with Unraid.

I'm only sort of following your logic, but you need enough blank drives to hold all your data, and one or two extra drives for parity, parity drives must be equal or larger than any single data disk. Unraid will require you to fully erase all content on the drives you plan to include in the array. To transfer data from foreign disks, you can either do it across the network or directly attach them temporarily and use the Unassigned Devices plugin to mount them, assuming they are in a format it understands. Copying across a gigabit network will be just as fast as local copies assuming active parity.

syslog server

It should say that it's running on that same page, along with a % progress.

Yes, but not necessarily productive something. When diagnosing bare metal windows in that condition, I'll often let things run for way more than 2 hours, but the times that's helped is fairly small. If it is indeed applying updates it typically will tell you that. Perhaps set up a new VM, and point it at the current vdisk?

Dunno off the top of my head. I always just click the start button in the GUI for a SMART extended self test, then look at the results in the GUI. Some things require CLI, but I tend not to keep CLI stuff memorized that has a GUI shortcut.

Run a long SMART test and then post the results.

No. A SMART report and possibly diagnostics covering that time may be more informative.

Keep in mind that those testers only catch the worst failures, they can show good when the PSU is still unable to stay stable under full load. For a system that boots and runs, those testers will likely show good, because they are only able to test the resting output. When diagnosing a no POST system, those testers are indeed useful. Glad you fixed your issue!

Not sure what you are saying here.

Yep. As long as the root folder name is the same, case sensitive, it will participate in the existing Movies user share. Shouldn't take more than a couple seconds, as it's just updating the path, not really moving the files. After you go through each disk and ensure only share folders are in the root, you can go into the flash drive and remove all the extra share config files.

Overclocking is not recommended for server stability.

Be careful with this, you can blow things up if a ground differential forces current through circuits not meant to handle it, in your case probably the ethernet. Ideally you would have a separate ground wire that would be connected to the new location before removing power at the old.

Without an oscilloscope, test loads, and years of knowledge and experience, the only way I know is to deploy the parts cannon. Replace it including ALL power cables and see if the symptoms change.

No, but you can email support and they can help you.

I suspect a programming flaw of some flavor, perhaps bug. It's just too coincidental my tastes. I'm pretty sure there are going to be some PO'd people when their hard to finish collections get cratered. I've never liked plex, so I'm more than a little biased here, but emby FTW. Perhaps it's time to recommend setting media paths to read only.

The use of the word "cache" in Unraid isn't typical. Storage pools is a much better description. The parity array is the primary pool, and it's the only pool that works with the Unraid special sauce of independent file systems on each drive with the ability to mix and match sizes, with a dedicated drive to add parity protection for 1 or 2 device failures. The other pools can be either single volume XFS, or multi member BTRFS. The mover is configured to transfer files between the primary parity pool and the share defined pool. Each user share can be configured to write files initially to the main array or one of the pools, and to move the files or leave them. It's a little more complex than that, but not much. The traditional definition of "caching" only loosely applies, if at all. Originally when the main parity array was the only option and writes were slower than typical network speeds, a temporary fast write location was added, and the mover cleared it out overnight. The files never existed on both places, and subsequent access was in place, so writes to an already existing file were always slow. That was the "cache" drive concept, and it has been modified and added to ever since, but true caching was never a thing.

For the last 20 years or so, drives have been addressed not by physical cylinders heads and sectors (CHS), but by logical block addresses (LBA). This means that when the OS asks to store and retrieve data, it's no longer referencing a physical spot on the drive directly like MFM and RLL did. All modern drives have varying amounts of real physical space like you said, but they are all presented with an industry standard size available to the OS. They use the excess space as spares, or to enhance performance, or whatever the manufacturer decides. The result is that all modern internal interface drives present the exact same addressable space to the OS, and the old practice of writing bad sectors on the top of the drive in sharpie so you could tell the controller which addresses to avoid is all handled automatically in the firmware. ALL hard drives have bad sectors from the factory at the hardware level, but appear perfect to the OS because they are remapped. They also have automatic handling of sectors that are damaged or go bad during the lifetime of the drive, so as long as the remapping function has enough spare sectors left, the drive will keep the appearance of being error free to the OS, while triggering SMART alerts as the spare sector pool is used up.