Ultimate Starter - (PAGE 1) - Jellyfin, Jellyseerr, NZBGet, Torrents and *ARR Media Library Stack

Tutorial Ultimate Starter - (PAGE 1) - Jellyfin, Jellyseerr, NZBGet, Torrents and *ARR Media Library Stack 0.01

No permission to download

Currently reading
Tutorial Ultimate Starter - (PAGE 1) - Jellyfin, Jellyseerr, NZBGet, Torrents and *ARR Media Library Stack

20
11
NAS
DS1511+, RS1221+
Operating system
  1. Linux
  2. macOS
  3. Windows
Mobile operating system
  1. Android
  2. iOS
geekau submitted a new resource:

Ultimate Starter - (PAGE 1) - Jellyfin, Jellyseerr, NZBGet, Torrents and *ARR Media Library Stack - Docker-Compose - VPN Enabled Jellyfin, Jellyseerr, NZBGet, Transmission and *ARR Stack in 30 minutes

PART 1 - Introduction

Set up a full VPN encrypted Jellyfin, Jellyseerr, NZBGet, Transmission and *ARR media stack using this docker-compose guide in less than 30 minutes, on Linux, Windows or Synology NAS environments.

This guide will cover all the steps needed to initially install and configure a secure docker hosted media environment, with all the applications needed to download torrents and Usenet content which you have a right to use in your media library, and...

Read more about this resource...
 
Code:
# Host Data Folders - linux Examples
#FOLDER_FOR_DOCKER_DATA=/opt/docker
#FOLDER_FOR_MEDIA=/opt/media
#FOLDER_FOR_TORRENTS=/opt/torrents
#FOLDER_FOR_USENET=/opt/usenet
#FOLDER_FOR_WATCH=/opt/watch
This may be a personal preference issue, but I do not advise the use of /opt for the following reasons.

Traditionally /opt is intended for 3rd-party software, not for file storage. More importantly, on partitioned Linux installs, /opt is contained within the root partition, which itself, may be relatively small in capacity, and may be easily overwhelmed by docker metadata (Note: Docker's own overlay2 folder is a daunting load on root partitions).

There is also the consideration of back-up methodologies, where typically / contains the OS and software packages, and /home (a vastly larger partition) contains user files. OS upgrades are another consideration. With rolling upgrades there is little risk to /opt, however full upgrades may prove frustrating.

For these reasons, I advocate using the home partition. If desired, one may create a unique user account for this assemblage of media-related containers.
Code:
# Host Data Folders - linux Examples
#FOLDER_FOR_DOCKER_DATA=/home/telos/docker
#FOLDER_FOR_MEDIA=/home/telos/media
#FOLDER_FOR_TORRENTS=/home/telos/torrents
#FOLDER_FOR_USENET=/home/telos/usenet
#FOLDER_FOR_WATCH=/home/telos/watch
While I've yet to read every word of this post, I commend the OP for their effort to make this relatively simple.

With a stack with multiple containers, managing image updates needs a plan, as with this docker compose structure, updating the stack will involve disrupting (momentarily, at least) all operating containers.
 
Thanks for the feedback mate, I very much appreciate it, helps to improve for all.


Traditionally /opt is intended for 3rd-party software, not for file storage. More importantly, on partitioned Linux installs, /opt is contained within the root partition, which itself, may be relatively small in capacity, and may be easily overwhelmed by docker metadata (Note: Docker's own overlay2 folder is a daunting load on root partitions).

To be honest, I did struggle to come up with some good data storage locations for the guide, in order keep it as simple as possible for the inexperienced user and also take advantage of atomic-moves within the containers by keeping the local files on the same partition etc..., and rightly /opt may not be the ideal location. I tried to address these as consideration points in the discussion, however I concede not everyone will apply the principles equally.

I also see in some discussions people want to use the /media folder for their media (which is fair), but it will break atomic-moves depending on the locations / partitions they use for the other folders.... usenet and torrents mainly.


With a stack with multiple containers, managing image updates needs a plan, as with this docker compose structure, updating the stack will involve disrupting (momentarily, at least) all operating containers.

Yes, my trade off here is to use the earlier guide I wrote for Docker / Portainer / Watchtower, and let watchtower auto-update all the images / containers nightly if they're needed (I understand this also has issues), however for ease / survivability, the more inexperienced users will be able to complete all of their images and containers, then re-build the stack and be back up and running in a few minutes.

Hopefully we can get enough people to testing it further on Synology, Linux, Windows... and other OS, and get some more feedback / guidance into it.

Regards
 
geekau submitted a new resource:

Ultimate Starter - (PAGE 1) - Jellyfin, Jellyseerr, NZBGet, Torrents and *ARR Media Library Stack - Docker-Compose - VPN Enabled Jellyfin, Jellyseerr, NZBGet, Transmission and *ARR Stack in 30 minutes



Read more about this resource...
First off... I love this. Second, I seem to be an idiot. I'm on TrueNAS Scale... running docker natively (not using their app system) so it should (in theory) function as a docker environment inside of a Debian host.

I keep getting this error when trying to deploy and can't make heads or tails of it:

Code:
failed to deploy a stack: Network media_network Creating Network media_network Created Container gluetun Creating Container gluetun Created Container transmission Creating Container nzbget Creating Container prowlarr Creating Container jellyfin Creating Container readarr Creating Container mylar Creating Container radarr Creating Container lidarr Creating Container whisparr Creating Container jellyseerr Creating Container sonarr Creating Container whisparr Created Container nzbget Created Container jellyseerr Created Container lidarr Created Container mylar Created Container readarr Created Container sonarr Created Container radarr Created Container transmission Created Container prowlarr Created Container jellyfin Created Container gluetun Starting Container gluetun Started Container readarr Starting Container radarr Starting Container lidarr Starting Container transmission Starting Container nzbget Starting Container whisparr Starting Container jellyfin Starting Container mylar Starting Container jellyseerr Starting Container sonarr Starting Container prowlarr Starting Error response from daemon: OCI runtime create failed: container_linux.go:364: creating new parent process caused: container_linux.go:2005: running lstat on namespace path "/proc/121802/ns/net" caused: lstat /proc/121802/ns/net: no such file or directory: unknown

Any thoughts?
 
First off... I love this. Second, I seem to be an idiot. I'm on TrueNAS Scale... running docker natively (not using their app system) so it should (in theory) function as a docker environment inside of a Debian host.

I keep getting this error when trying to deploy and can't make heads or tails of it:

Code:
failed to deploy a stack: Network media_network Creating Network media_network Created Container gluetun Creating Container gluetun Created Container transmission Creating Container nzbget Creating Container prowlarr Creating Container jellyfin Creating Container readarr Creating Container mylar Creating Container radarr Creating Container lidarr Creating Container whisparr Creating Container jellyseerr Creating Container sonarr Creating Container whisparr Created Container nzbget Created Container jellyseerr Created Container lidarr Created Container mylar Created Container readarr Created Container sonarr Created Container radarr Created Container transmission Created Container prowlarr Created Container jellyfin Created Container gluetun Starting Container gluetun Started Container readarr Starting Container radarr Starting Container lidarr Starting Container transmission Starting Container nzbget Starting Container whisparr Starting Container jellyfin Starting Container mylar Starting Container jellyseerr Starting Container sonarr Starting Container prowlarr Starting Error response from daemon: OCI runtime create failed: container_linux.go:364: creating new parent process caused: container_linux.go:2005: running lstat on namespace path "/proc/121802/ns/net" caused: lstat /proc/121802/ns/net: no such file or directory: unknown

Any thoughts?
I came across something similar, try commenting out these lines in YAML file, under Jellyfin:

Code:
#    devices:
#      - /dev/dri:/dev/dri

This is used to pass the hardware encoder through to container, however Synology and other NAS don't typically have this device, so will fail to build.

I'll change default in the file to comment this out.
 
Code:
... Started Container nzbget Started Error response from daemon: OCI runtime create failed: container_linux.go:364: creating new parent process caused: container_linux.go:2005: running lstat on namespace path "/proc/175314/ns/net" caused: lstat /proc/175314/ns/net: no such file or directory: unknown

I commented out the lines but still get this
 
Code:
... Started Container nzbget Started Error response from daemon: OCI runtime create failed: container_linux.go:364: creating new parent process caused: container_linux.go:2005: running lstat on namespace path "/proc/175314/ns/net" caused: lstat /proc/175314/ns/net: no such file or directory: unknown

I commented out the lines but still get this
Looks like its related the NZBGet, have you created all the sub-folders in each of the FOLDER_FOR_* locations?

Also, you can comment out all of NZBGet to see if the builds without that container:

Code:
#  nzbget:
#    image: lscr.io/linuxserver/nzbget:latest
#    container_name: nzbget
#    restart: unless-stopped
#    depends_on:
#      - gluetun
#    volumes:
#      - ${FOLDER_FOR_DOCKER_DATA:?err}/nzbget:/config
#      - ${FOLDER_FOR_USENET:?err}:/data/usenet
#      - ${FOLDER_FOR_WATCH:?err}:/data/watch
#    environment:
#      - PUID=${PUID:?err}
#      - PGID=${PGID:?err}
#      - TZ=${TIMEZONE:?err}
#      - DOCKER_MODS=ghcr.io/gilbn/theme.park:nzbget
#      - TP_THEME=${TP_THEME:?err}
#      - NZBGET_USER=${PORTAL_USERNAME:?err}  # WebUI Portal Authentication - Optional
#      - NZBGET_PASS=${PORTAL_PASSWORD:?err}  # WebUI Portal Authentication - Optional
#    network_mode: "service:gluetun"

If its still failing, try commenting out some of the additional containers to narrow it down.
 
There is no need to put everything behind Gluetun. Only the downloaders, and possibly jackett. All that unnecesarily complicates the compose file by adding in the "arr" packages.

What advantage do you see using the env files? Just "because you can" doesn't make it right.

I'm still plowing through the text and may have more to ask.
 
I understand the recommendation that downloaders / Prowlarr need to go behind VPN, however I live in a land downunder, and I trust none of the government with their ISP metadata laws, so everything is behind a VPN to start with, but its easy to change the network mode if anyone wants.

I use the ENV file because I want to make it easy for new users, most people don't know how to use some of these app, let allow docker-compose. So if we can give them a working environment using this guide.

Am also getting some guide on apps from /Radarr reddit, so may swap out Transmission / qBittorrent and NZBGet / SABnzbd, as NZBGet is no longer under maintenance and Transmission doesn't handle categories properly.
 
Last edited:
Okay, but with 3 OS, and a myriad of directories, along with env files, and a huge compose file which makes troubleshooting daunting, and many "arr" settings outside of the defaults, this may put off inexperienced users... In contrast to the bite sized practices offered by Dr Frankenstein.

FWIW, I started with qbittorrentvpn, and migrated to qbittorrent + Gluetun... And added sonarr and radarr separately... And later Plex, jellyfish, and others, incrementally. The "keep it simple" plan is my way... Stuff like lidarr, etc, can wait. Good luck with your treatise.
 
I ended up getting rid of all the arr containers inside the script except for Prowlarr leaving Gluetun, NZBGet, Transmission, and Prowlarr and got the script to work. I had to make some modifications to the Gluetun container including the pre-shared key (specific to my wireguard settings), I got rid of the HTTPProxy option and firewall settings. I get the right results when pulling ifconfig.io so I am satisfied. I agree with @Telos and honestly think if you just included the ultimate starter with the four containers I included (and maybe sonarr & radarr at most) it would be better.
 
Last edited:
I've been going through this whole guide with minimal issues until the YAML and ENV files you provided which are not working in the slightest and don't even appear to be formatted at all correctly based on other examples I've found. They are full of HTML markup. I was able to tediously remove hundreds of spaces that broke YAML validation, but it still gives an error saying it's missing critical header info. And then ENV loaded it hundreds of lines of scripts into Portainer that of course was a mess. Am I missing something or did you provide bad files?
 
Last edited:
Last edited:
Making progress, but I'm stuck in deployment. The error message gives me a whole host of services it is starting, and then it ends with:

YAML:
Error response from daemon: OCI runtime create failed: container_linux.go:363: creating new parent process caused: container_linux.go:1946: running lstat on namespace path "/proc/23178/ns/net" caused: lstat /proc/23178/ns/net: no such file or directory: unknown

Any ideas? I notice that every time I run it, the last *arr referenced changes. So I don't think it's any specific one.
 
Making progress, but I'm stuck in deployment. The error message gives me a whole host of services it is starting, and then it ends with:

YAML:
Error response from daemon: OCI runtime create failed: container_linux.go:363: creating new parent process caused: container_linux.go:1946: running lstat on namespace path "/proc/23178/ns/net" caused: lstat /proc/23178/ns/net: no such file or directory: unknown

Any ideas? I notice that every time I run it, the last *arr referenced changes. So I don't think it's any specific one.
This may also help, I've pulled all of the applications out of the larger YAML file, into their own individual YAML file, and uploaded them there:

https://github.com/geekau/media-stack/tree/main/individual-apps # <-- In the "individual-apps" folder.

Follow the README on the page to get started.

This should help to fault find individual docker apps as you build them, and also only need to build what you want to use.

The Gluetun app MUST be built first, as it sets up the VPN, and also sets up the Docker Bridge network for the rest of the containers.

Initially ALL Docker apps are hidden behind the VPN, however each docker-compose YAML explains how to bypass the VPN if you want to do direct to the Internet.

I've tested on Synology, Linux and Windows, so should help you get started.
 
A little more progress every time, but most of these are giving me this error in SSH when doing the install. The Pulls work fine, but then:

Code:
Creating sonarr ... error

ERROR: for sonarr  Cannot start service sonarr: Container 8977c22026ccf59b8dff80f8266d01a63e11381cddaa3f71dc446253442af64b is restarting, wait until the container is running

ERROR: for sonarr  Cannot start service sonarr: Container 8977c22026ccf59b8dff80f8266d01a63e11381cddaa3f71dc446253442af64b is restarting, wait until the container is running
ERROR: Encountered errors while bringing up the project.
Annoyingly, a couple worked are are running in Portainer, but most say "created" and if I try to run them, I get an error "Code 409" with no further information.
 
A little more progress every time, but most of these are giving me this error in SSH when doing the install. The Pulls work fine, but then:

Code:
Creating sonarr ... error

ERROR: for sonarr  Cannot start service sonarr: Container 8977c22026ccf59b8dff80f8266d01a63e11381cddaa3f71dc446253442af64b is restarting, wait until the container is running

ERROR: for sonarr  Cannot start service sonarr: Container 8977c22026ccf59b8dff80f8266d01a63e11381cddaa3f71dc446253442af64b is restarting, wait until the container is running
ERROR: Encountered errors while bringing up the project.
Annoyingly, a couple worked are are running in Portainer, but most say "created" and if I try to run them, I get an error "Code 409" with no further information.
I'm assuming Sonarr half set up a container but failed. You should be able to set a list of containers in portainer, or via SSH:

sudo docker container list
sudo docker container stop sonarr
sudo docker container rm sonarr
sudo docker container prune -all

Possibly also:
sudo docker container rm 8977c22026ccf59b8dff80f8266d01a63e11381cddaa3f71dc446253442af64b

Then run the docker-compose again to build the container.

Sometimes in Portainer, you can select a container (if its visible), and select to "recreate", which is just another way to rebuild using the initial configuration it was built with.
 
Hello geekau, first of all I would like to thank you immensely for your tutorial, it was exactly what I needed, as I am inexperienced.
I have a Synology DS220+ and I'm trying to install via portainer, and the error appears after uploading the yaml and env. file ''failed to deploy a stack: 1 error(s) decoding: * error decoding 'Ports': Invalid ip address: http''
I have no idea which ip is wrong, I tried to simplify, trying only with gluetun and sonarr and I got the same error.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

geekau submitted a new resource: Ultimate Starter - (PAGE 2) - Jellyfin, Jellyseerr, NZBGet, Torrents and...
Replies
0
Views
1,504
NAS_Master submitted a new resource: Ultimate Starter - Docker, Portainer, Portainer Agents, and...
Replies
0
Views
1,307

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top