Here's a thread showing one user's issues with this: "Best Practice" in this case dictates that both Sab and Sonaar have to have identical matching mappings for the downloads folder. Now, if Sonaar has different mappings (eg:/MyDownloads mapped to /mnt/user/Downloads), then its not going to be able to find the downloaded file because it will be looking in /Downloads for the file (like sab told it to), but that folder (/Downloads) does not exist in the Sonarr container. In this case, Sab tells Sonaar "I just downloaded a file and stored it in /Downloads" (remember that /Downloads is mapped to /mnt/user/Downloads)
Where it begins to matter is if you have multiple containers that need to communicate with each other. In most cases, it really doesn't matter that much what your host path and container paths are as long as you can get to the data that you want. IE: If the container path is /Downloads, then when ever you tell the container to save something into /Downloads, docker will then "map" it and actually store it on your unRaid system at /mnt/user/Downloads. On the container path side of things, you tell the container how it should "refer" to the host path. On the host path this would be something like /mnt/user/Downloads. Best practice for containers dictates that if the container only needs access to a Downloads share, that you only create a mapping for the Downloads share. The host path is (generally) your shares that you want to give the container access to. The container volume path and the host path. This is done in the mapping section of the Add Container screen. Because a container is completely separate from the unRaid system we have to tell it what folders (paths) that it has access to. But, this is my best shot at it purely using text.Ī container usually needs to access information (either read only or read/write) on the host (unRaid) system. What this section really needs is a video with lots of arrows, hand waving, etc. A container has no idea that its running on unRaid (or any other system), and has no concept of any other containers that may also be running. I've always had a real tough time trying to explain this because it is a confusing issue to try and explain, but trust me that once you understand it will make 100% perfect sense.įirst thing: Docker Containers are (for all intents and purposes) completely separate from the rest of the unRaid system. Truth be told the risks associated with violating the best practices are pretty low. Note: You'll notice throughout this that I talk about "best practice" a lot. Just in case this is too hard to read, if you're reading this part of the FAQ, you're probably going to be best off setting up your docker paths as /mnt mapped to /mnt. You will also need Community Apps with Docker Hub enabled.What are the host volume paths and the container paths I am running Unraid version 6.8.3 to make this happen. Here is a list of the build in its most basic form: The server I’m using is a left over one that was almost decommissioned. In this particular guide, we will only be configuring our container to stream to Twitch. At the end, you should be able to use Unraid to stream to Twitch, Mixer, YouTube, etc. Why would you want a server with the ability to stream to multiple services? Well, you're probably trying to reach a broad audience across different services, right? This is a great way to make that goal happen using your Unraid server. This is a guide to turn your Unraid server into a game re-streaming server.
0 kommentar(er)
