Cat_Seeder

2k is about right without any tweaks. rtorrent by itself (no web ui) can be pushed way further; check some of my previous posts for some hints on how to do it. Since this container has screen, rtorrent-ps and pyrocore, if you don't mind the command line you can certainly make it work. PS: rtorrent-ps and PyroScope both looks unmaintained and @binhex has already told the community that he may move the containers back to regular rtorrent. To be fair rtorrent is also usable by itself, but PyroScope certainly makes it nicer. PS II: rtorrent itself is also stuck in version 0.9.8 since 2019. Unfortunately a lot of torrent software is dying.

AFAIK, Unpack Plugin isn't shipped on automatic mode. Have you tried starting a brand new container (without pointing it to any of your current data / configuration files)?

Ok, so are you having a different issue now or have I missinterpreted your original post? From the original post I assumed that rutorrent was accessible. If the GUI isn't showing up this is very likely a configuration issue in your rtorrentvpn container. By rereading the messages knowing that rutorrent UI isn't accessible, I would assume that either the container is not able to finish starting or you are trying to access it from outside the LAN_NETWORK that you have specified (and thus packages are getting discarded). Is the client (as in, the computer where you are using your browser to access rutorrent) in the 10.0.0.0/24 subnet or in the 10.0.20.0/24 subnet? Also Follow@binhex's guides and send us some logs if you think that your container is failing to initialise properly.

When you say "can't access web UI" do you mean that you can't login to rutorrent (port 9080) at all? Or can you login to rutorrent but can't make Sonarr, etc connect go it? One alternative idea to bridge mode would be to use a docker compose file and / or add all containers to the same network. This is what I'm doing at the moment and my containers can reach out to each other via hostname as well as IP (https://docs.docker.com/compose/networking/). My rutorrent container is not even visible to my host. The only container visible to my host is a Nginx container acting as a reverse proxy.

* Have you enabled RPC? * Are you using the RPC username and password to connect from Sonarr / Radarr? (This is set using different environment variables than rutorrent's username password. See Q3 here: https://github.com/binhex/documentation/blob/master/docker/faq/rtorrentvpn.md) * Assuming that you are also using docker containers for your *arr applications, can you open a shell (docker exec -i -t <container_name> /bin/bash) from one of your containers and ping the rtorrent's container ip? Can your *are applications reach rtorrent's IP address? * Assuming that you can ping the rtorrent container IP, how are you setting Sonarr's "Download Client" configuration? (See: https://quickbox.io/knowledge-base/how-to-connect-sonarr-radarr-with-rutorrent/)

See answer #21 in https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md on how to configure wireguard.

I can't vouch for the best / preferred solution. But PIA has been working fine here, and I managed speeds over 600 Mbps with the "new" wireguard VPNs. I'm currently using Switzerland and Spain servers (I'm in Europe).

Just delete the user and then create the same user again using the script

It's whatever you have set with the env variables. Just delete it, recreate it with a new password and later remove the env variables (or not, leave them as a distraction to anyone trying to hack into your container).

Hi, just bumping the thread. Any thoughts?

Yeah, this one I actually agree with. It would be awesome if security oriented people could use Docker secrets for this information (https://docs.docker.com/engine/swarm/secrets/). It only works with either swarm or docker compose but it would still be a fine addition nevertheless. I could offer to implement this myself but I have been swamped with work lately. Maybe someone else can open a PR? (Shouldn't be so complicated).

Hi Linguafoeda, I'm not sure if this has changed, but once you have created the container the password would remain there even if you remove the webui password env variable. Also there is a few scripts to add users. It's been a while, but if I'm not mistaken I've removed the original credentials by manually editing a text file inside the container and then I used a script to create the user with a different password. Update - From the documentation: If you want to create an additional user account for ruTorrent webui then please execute the following on the host:- docker exec -it <container name> /home/nobody/createuser.sh <username to create> <password for the user> If you want to delete a user account (or change the password for an account) then please execute the following on the host:- docker exec -it <container name> /home/nobody/deluser.sh <username to delete>

Hi guys, I've been lurking around the forums for a while and casually contributing to @binhex rutorrent container. I'm a Software Developer and have a huge mix of devices in a "home lab" environment. I got some extra budget this year and was thinking about replacing some of my stand-alone toys with a super-duper-hyper Unraid box. Things that I want to replace: 1. QNAP NAS. Currently running 4x6TB WD Reds in RAID 10. Mainly used for storage, has a few docker containers running backup and mount jobs (mainly rclone stuff) 2. Old Xeon 2.2ghz server running openSUSE and Btrfs file system. It is running docker swarm (I'm willing to move to K8s) with a few dozen containers (some with several replicas). This is mainly used as a Media Server. It has a fleet of containers for, Plex, rTorrent / ruTorrent, NZBGet, Sonarr, Radarr, Jackett, etc. It also runs Pi-Hole, a few small databases for my media software and development, (MariaDB, MongoDB, InfluxDB), OpenVPN (I'm willing to move to wireguard), Varken, Telegraf, Prometheus and Nginx reverse proxy. CPU usage is generally bellow 30%, but it lacks a good GPU and is starting to struggle when transcoding 4k video. 3. A Dual Boot Gaming / Hackintosh machine with a GTX 1070. I'm playing Triple AAA titles from 5+ years ago (Witcher 3, GTA V, Forza Horizon 4), and emulation (HyperSpin build with a currated 800 GB list). I boot macOS mainly for development and video editing. I'll be keeping a Chromebook and a ThinkPad that will hopefully act only as dumb thin clients to the VMs in Unraid. I was initially thinking about going with a Ryzen 9 5950x. A 6900 XT (I want an AMD Graphics Card that I can passthrough to the macOS VM). A Fast 2 TB NVMe SSD for the Windows and Hackintosh VMs and repurposing my WD RED drivers for storage. The docker containers will always be running. Hopefully they will be running on top of Unraid itself. If I need an OS / GPU passthrough for the Plex Server I may have one VM always running (and in this case I'll also buy another, less powerful, GPU). The Gaming and Hackintosh VMs will not be run at the same time and I was thinking about a setup where I could passthrough the same 6900xt video and at least 8 cores for both of them. For now I have no idea about cabinets, external enclosures, power supply, fans, etc. Has something like this been attempted before? Can it be done? Any list of parts that could be shared? Also, what would you use to remote in the gaming machine? Right now I'm using a combo of GameStream / Moonlight (requires an NVIDIA Card) and NoMachine (not great for gaming). I also had a terrible experience with parsec, so I don't really know what's the best way to remote in the VMs for gaming and heavy productivity work. Budget: £3000 to £4000 (Can go a little higher if required).

How many torrents are you seeding? And how fast are your drives? Rutorrent's PHP backend isn't exactly the fastest one, and honestly, after 1500 or so torrents it's easier to manage everything from the command line. I have SSD caches and well tuned Linux box, even so, deleting the data of a big torrent file using Rutorrent's File Manager often makes the UI unresponsive. If you are dealing with a few hundred torrents or less then rutorrent is manageable, otherwise I deeply recommend getting familiar with pyrocore. Using the CLI feels weird at first, but once you get used with it there's really little use for rutorrent.

You can make it run automatically on startup. See A2 here - https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md . For sinology: https://help.synology.com/developer-guide/integrate_dsm/run_with_system_boot.html

And everything is working again. Thanks Binex, you are awesome. I know that eventually we'll need to jump off rtorrent-ps (unless a miracle happens and it pick up the pace again). Hopefully there's a way to do it without having to force users to expose RPC2 mounts and someone will find a way to make file manager before that. For now, I'm glad to be on good ol' versions :).

For the old version of the container with rtorrent-ps + old version of file-manager (before it was split on its own repo) see: https://github.com/binhex/arch-rtorrentvpn/issues/96 For the latest version of the container + newest version of file manager I can't get it to work at all. Had to revert back. Please do let me know if you figure out.

rtxmlrpc is part of pyrocore. @binhex, without pyrocore we'll not have rtxmlrpc, and reverting to xmlrpc means that port-forwarding will need /RPC2 mounts and we'll be back discussing security shenanigans. I understand that you want to get alway from rtorrent-ps, but can you maybe include an individual release of pyrocore in the image?

I've installed an old version manually. Can't get the newer version working for the life of mine.

Well, with the last update my ancient version of rutorrent's file manager plugin is officialy dead. Did anyone get the newer version of https://github.com/nelu/rutorrent-filemanager, https://github.com/nelu/rutorrent-filemanager-media and https://github.com/nelu/rutorrent-filemanager-share to work? I can't live without file manager.

No comments about security, but it's certainly fast, and so far it has been stable. Thanks @binhex, sending another beer your way. By the way, did the autodl-rssi + recent version of php issue got sorted? Kind regards,

The unofficial script below already works with OpenVPN. https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh

PS. Looks like someone already managed to create a bash script to make port forwarding work with next-gen servers. It's experimental but according to the author comments it should also work with OpenVPN. https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh .

I got port forwarding working with the Spainish server (one of the old ones), before that I could make it to work with servers in Switzerland but it no longer works for me. Unfortunately, until PIA stabilises old servers or provide APIs to port forward on next-gen servers there's no much that can be done other than server hopping and praying.