JonathanM

Instead of screenshots, please post the docker run command for both the youtube and deluge containers.

That would appear to be the settings for the youtube container. You need to add the port to deluge.

Has this been resolved?

Think of containers as tiny vm's, they each have their own OS, and typically only have the bare minimum of tools installed to keep their size down. The container authors made a choice not to include curl.

Amend that to read "if you use the parity 2 drive slot" You will still run into the performance difference even if you only have single parity if it happens to be in the 2nd parity position.

To narrow down the issue, try enabling disk shares and writing directly to \\tower\cache\usershare\fold\file Don't do any other type of file management using disk shares until you understand how disk shares and user shares interact and how it's possible to corrupt data mixing the two types in a file management operation.

Capacitors all look good on the motherboard?

Did you add the port mapping that would normally be on the youtube-dl container to the vpn container?

You can however, use the container mapping of the qbit container. So, assuming the speedtest app is listening on 80, you should be able to add a mapping to qbit with container of 80 and host of whatever you want that isn't in use, and the speedtest app should answer on that port.

Just an FYI, but the newest version of Unraid allows multiple cache pools, so instead of trying to mount it as a UD, you could just use normal array management functions.

Sorry, I removed the API and cookie because I couldn't get them to make a difference. What does make a difference is changing the IP the container is going through every couple days whenever I get 429'd, typically every 36 to 48 hours. I'm already using a VPN container, so I just changed this container to network none and added --net=container:<name of vpn container> to the extra parameters line. Whenever I restart the vpn container it gets a new external IP. It's a little inconvenient, but it works. I suppose if I get too irritated I'll script something that watches for 429 in the log, and restarts both containers. I asked the container author to code a modification that would stop hammering the servers after the first few 429's, but that didn't seem to get any traction. Ideally it would watch for a 429, pause and show a notification in the app for a short interval, restart, if there was a 429 again, pause for double the interval, etc. Reset whenever the container is restarted. Apparently there aren't very many heavy users that get frequent 429s.

I'm not familiar with a nag screen on Emby. Could you link or attach what you are talking about?

In a nutshell, disk shares are the contents of each individual disk. The don't show up on the network by default, but you can turn that option on if you want. User shares are the combined view of all identically named root folders on each of the individual disks. The reason disk shares aren't shown by default is that it's easy for an inexperienced user to corrupt files if they combine file operations between the two different schemes. Until you figure out exactly how disk and user shares interact, don't mix them in file operations. Copy or move only disk to disk, or user to user, never disk share to user share. After you have a handle on exactly what's going on behind the scenes, it's easy to avoid the pitfalls and you can navigate as you please between the two. Novice users often see their files in two different named locations and think they accidentality created duplicates somehow, or try to take shortcuts with file management resulting in corrupting their files. Quick example. /mnt/disk1/shareA/Subfolder1/text.txt is /mnt/user/shareA/Subfolder1/text.txt, so deleting the first file makes both go away. If you instead manually create /mnt/cache/shareA/Subfolder1/text.txt so the same folder and file name are on both drives, then the user share named shareA will only show one of the two files, and if you delete the file visible in the user share, it will delete one of the files, and nothing will appear to happen because the user share will start showing the other file. Once you understand the nuances, you can do some interesting tricks with it.

Have you watched any of Spaceinvader One's youtube videos?

A path that doesn't exist currently is created in RAM when written to, and if you try to read from it, returns file not found. I was asking for a way forward, as in how to accomplish what you are asking for.

How would you handle VM or container use of array resources?

What you show here is only half the equation. You must look at each container app setup INSIDE the app, and make sure any data is being written to a mapped location. As an example, you have delugevpn configured with /data and /config pointing to array locations. If you have deluge itself saving data to /download, it's going to save the data inside the docker image. But, from what you posted here, there is no way to determine how you have deluge configured. You probably have deluge correct, or other things would be wrong, but that is just one example of where things can go wrong. You must examine each app to make sure it's only saving data to locations that are mapped to the array. What you posted here doesn't show any of that, only where the apps should be saving data, not where they actually are configured in their settings. Clear as mud?

Running at 100% is normal and you want it to be able to do that. Causing your server to shut down is NOT normal, and you need to figure out why. Can you monitor your CPU temps and see if they are out of control? It could be as simple as blowing the dust out of the heatsink, or maybe you need a larger heatsink fan combo.

There is a support link in the dropdown where you selected remove, try following up there.

That typically means you haven't removed the configuration folder. How did you install it the first time?

@SpencerJ This is still happening.

According to your run command, your qB download location as set in the application should be /data

Which makes sense, in a perverse sort of way. I can't read it as it's gone, so it's permanently unread. I'll stop now.

And it won't go away. It's at the top of my unread posts feed permanently, I guess until the next search index is complete.

However..... That post is gone, deleted, no more. It's an ex - post. I'm guessing the search index is still lagging a little.