tankertux

I'm experiencing this today with Unraid 6.12.8 trying to install CA Plugin 2024.03.17 plugin: installing: community.applications.plg Executing hook script: pre_plugin_checks plugin: downloading: community.applications.plg ... done Executing hook script: pre_plugin_checks Cleaning Up Old Versions Fixing pinned apps Setting up cron for background notifications plugin: downloading: community.applications-2024.03.17-x86_64-1.txz ... plugin: community.applications-2024.03.17-x86_64-1.txz download failure: Generic error Executing hook script: post_plugin_checks darktower-diagnostics-20240319-0803.zip

For wireguard, yes. For jackett, you can, it will do nothing and will not hurt to remove or leave it. On the nginx container, I map the ports that I would have needed on the client containers (i.e. your port mappings from Jackett should be here) The following is my nginx.conf file, modified to match your network container name (wireguard) and your client app ports (9117). I'm not sure what configuration you should have for Jackett after the "location /", but this is what I've found necessary for qbittorrent and deluge. user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; keepalive_timeout 65; server { listen 9117; location / { proxy_pass http://wireguard:9117/; proxy_set_header X-Forwarded-Host $server_name:$server_port; proxy_hide_header Referer; proxy_hide_header Origin; proxy_set_header Referer ''; proxy_set_header Origin ''; add_header X-Frame-Options "SAMEORIGIN"; # see note } } include /etc/nginx/conf.d/*.conf; }

Here is the solution I ended up with: First, I created a custom network for the container that "owns" the network (i.e. wireguard in your case, vpn in mine). Mine is a bridge network called "pianet". The reason for this is to avoid using the legacy docker link functionality to address the "host" container from the reverse proxy. https://i.imgur.com/Gi1jkxD.png Then, I created my network container, and specified the custom network in its template definition. https://i.imgur.com/yMlI9fl.png Next, I created my "client" containers (i.e. jackett in your case, torrent client in mine) specifying the containers use the network stack of the "host" container (e.g. --network=container:wireguard-container-name ). Each secured application will need to listen on distinct ports, as they are all sharing the port space internal to the "host" container https://i.imgur.com/cBQQP7Y.png Lastly, I setup a reverse proxy (Nginx in my case) configured to pass connections from the custom network into the "client" container. The reverse proxy is configured to use the custom network and addresses the "host" container by container-name in the nginx configuration. This container is where you will specify your port mappings, because all connections to the secured containers will need to come in as requests through the reverse proxy container, which will route the requests to the "host" container on the appropriate port, thusly being directed to the "client" application because the host/client share the same network stack. https://i.imgur.com/yMlI9fl.png I hope this explanation helps!

@ken-jiThank you, I did miss that I could specify extra parameters in the template. I've just now found binhex' template repository on Github that I can use as a reference. The XML schema for the templates does not seem well documented (here is the most comprehensive reference I could find). It is ambiguous that the extra params (--network="container:vpn") would override the default <networking><mode>container:vpn</mode></networking> section. I attempted the latter solution in a template and failed to get it working, so I'll give the extra parameters a try. @BRiT Thanks for that, boot order was not something I had considered yet! I found the Docker Autostart manager on CA

I ended up achieving my setup using docker-compose from the command line, using a slimmed down version from my CentOS server. I'm surprised that unRaid does not facilitate container network mode as documented in the official Docker documentation. As it stands right now, I have the functionality I need, but unRaid informs me that there is always an "update ready" when there is not. I have also yet to experience the helpful community that everyone seems to tout as a benefit of unRaid over a comparable free solution like SnapRaid + mergerfs or FreeNAS.

I would like to add that the reason I am attempting this setup is that Private Internet Access.com has a limit on devices. By having both containers connect to the internet via a single VPN connection, I get protection for both using a single device while partitioning which downloaders specific users can see/use. I think that if Deluge had better user management, I would not need anything beyond a single delugevpn container.

I have a use case where I want 2 containers to use the network of a third container. I am on an unRaid trial and am attempting to recreate my docker compose setup via the unRaid interface. I have two deluge containers (network_mode: "service:vpn") that connect through a vpn container (named "vpn" in compose). So far, I have used binhex/delugevpn to get a deluge+vpn setup. I would like to start a second container (binhex/deluge or linuxserver/deluge) that uses the initial containers' network. How can I achieve this via unRaid?