JonathanM

Stock Unraid doesn't currently have a way to allow containers to directly access video hardware. VM's are the only way to do video passthrough.

The biggest thing that needs to be addressed is your understanding of unraid's folder system. Unraid has several ways to view or work with your data, depending on the circumstance. <Direct disk access> /mnt/disk1-disk28 are your parity protected array disks /mnt/cache is the cache pool, regardless of how many disk members it has <User shares> /mnt/user is the root folders of BOTH the /mnt/diskX tree AND /mnt/cache /mnt/user0 is ONLY the root folders of /mnt/diskX, it omits the /mnt/cache portion There are no extra copies shown, if you delete something in one tree it's gone from all of them. Because the same exact content can show up in multiple trees, it's vital that you not copy or move between the disks and user shares unless you understand exactly where and what is happening. Directly referencing the disks via /mnt/diskX and /mnt/cache is not preferred, and when everything is working the way Limetech intended is not needed. However, there are still some situations where the preferred all encompassing /mnt/user tree doesn't quite work as intended, and using the disk paths is needed for some applications to work correctly.

If it were me, I'd put the drives back the way they were, get the USB fixed, make sure it runs ok, then update to the latest version of Unraid. The main reason I say that is v5 only supports ReiserFS, and it will perform VERY poorly with large drives. It maxes out at 16TB, but gets extremely slow when you get beyond 2TB used on a drive that has any kind of deletions and additions. If you update to v6, you can use XFS, which works much better on large drives. Once you're updated and stable, upgrade the parity drive, ADD the 12TB in a new drive slot and format it as XFS, then copy the contents of as many of the ReiserFS drives as you can to the empty 12TB data drive, and format the ones you copied to XFS.

Remove them all, run in normal mode and add them back in batches. I can't think of a reason, but why not just remove the plugins and run normally if that's what it takes?

plugins

Very possible, and explained in various places around the forum. Here are the highlights to give you a starting point for your research. Use the Unassigned Devices plugin to mount your 2nd NAS to a named spot in /mnt/disks Map that path in the plex container setup with the slave r/w option Browse to the container side of that mapping in plex to add those files to your plex library.

There is a fair chance there is file system corruption involved.

The letsencrypt nginx web server can serve pdf's as files, if you don't need a fancy manager.

The issue with that is if you have one of your critical drives full of content unexpectedly quit, you are relying on known failing drives to rebuild it. Unraid requires ALL drives to be read flawlessly to rebuild a failed drive. You may as well just run without parity, at least that way when a drive dies it doesn't immediately start stressing all the other marginal drives. I'm not being flippant here, you really do stand a better chance of keeping your data safe if you drop parity and use those two drives plus multiple other drives to keep backup copies of your data. You can set up scheduled copies with the user scripts add on, that way when drives die you have backups. Keeping questionable drives as members of the parity array will bite you. I lost data that way many years ago when I started with unraid, never again.

Are said downloads in the Media share when they are on the cache drive?

Yes, midnight commander. All you are doing is a rename, it should only take seconds. mv is a rename as well https://www.unix.com/unix-for-dummies-questions-and-answers/138904-mv-command-mv-vs-rename-operation.html

According to their FAQ, they only do port forwarding through their app. So unless they can tell you how to open and assign a specific port for a generic openvpn client that is used here, you are out of luck. https://support.ivacy.com/faqs/how-to-get-ports-opened/

That's it, pretty much. In step 2, you change the desired format type on the drive to XFS, then when you start the array, it should show that single drive as unmountable, and you will have the option to format it. Check to make sure only the drive that you changed shows as unmountable, as it will format all unmountable drives at once. Parity stays valid whatever the format or content of the drive as long as you don't set a new config and rearrange drive slots. Parity has no concept of files or formats or anything like that, only patterns of bits across all the drives.

Easiest thing to do is move the content of the new Disk1 folder to the root of the disk. You can do that using mc at the command line, it should only take seconds.

I think what you are referring to is trying to keep the data on the same slots after the conversion is done. If you don't particularly care which drive has which data when you are done, all you need to do is make sure all the data on your largest drive is copied elsewhere, then format it to XFS, and copy the data back to it. When you finish copying the contents of the 4 and 3 back to the 8, you format them to XFS, copy another 2 3TB drives to the now XFS 4 and 3, format those 2, copy the last 3, format, done. I really, really recommend copying instead of moving, for a couple reasons. First, when you copy, you can verify before erasing the source. Second, it's WAY faster to format a ReiserFS drive which erases it anyway vs. all the deletions that are needed during a move with parity enabled. ReiserFS is slow about deletions anyway, when you compound that with an array write to the destination drive, it can take many hours more to accomplish the same end goal. rsync -arv /mnt/disk3/ /mnt/disk1 rsync -narcv /mnt/disk3/ /mnt/disk1 The first command would copy all the files from disk3 to disk1, the second command would verify with checksums that the copy is complete. If the second command lists any files, it's because they don't match, and you need to figure out why. One reason would be that you forgot to keep something from writing to the server.

Nomachine

Unraid runs in RAM, and boots from your licensed USB stick. The sticks I use and highly recommend for durability and compatibility are these, in USB 2.0 https://www.kingston.com/us/usb-flash-drives/datatraveler-se9-usb-flash-drive bonus, they are cheap. The ultra tiny USB3 sticks have a less than stellar reputation for either durability, compatibility, or both.

Apparently you don't own the rights to use magmajitsi.com, it appears to be available for purchase.

Live USB boot red hat based linux distro?

Are you running rclone by any chance?

Does the array stop successfully? Not shutdown, just come back to a stopped screen with the option to start it again?

Instead of step 4, what happens if you hit the stop button on the Main gui tab? If it stops successfully, try the shut down button on the Main gui.

That wasn't the question. When you ping the url, what result do you get?

Does your url resolve to the proper IP address?

Screenshot of the error and the diagnostics zip file would be a good start to investigate it. I've never heard anything like that.