Cat_Seeder

Have a look at nginx logs for suspicious activity, particularly requests to /RPC2 from unusual IP addresses. Make sure to secure both ruTorrent and RPC2 with strong passwords (or disable RPC2 entirely I'd you don't need it). Don't use the defaulr auto-generated passwords as they are logged in plain text. If you can, do not expose anything over the internet (you can use a VPN to access your box). If you need to expose rutorrent do the internet then make sure to use a hardened reverse proxy (nginx-proxy / traefick, etc), Https only, with a real certificate (e.g., Let's Encrypt) and a strict fail2Ban configuration. Having said all that, keep in mind that there are vectors of attack other than your torrent client (e.g., if someone got access to your private tracker username / password somehow, or if one of the private tracker admins messed up / if your own machine was compromised, etc). I know that this is generic advice, but I hope it helps.

You are looking for network.port_range.set, for further information check rtorrent guide at https://rtorrent-docs.readthedocs.io/en/latest/cookbook.html The container README.md also has a sample configuration for AirVPN demonstrating how to change incoming ports: https://github.com/binhex/arch-rtorrentvpn/blob/master/README.md

Privoxy is starting fine at port 8118. Make sure to expose that port (e.g., -p 8118:8118 if you are using docker CLI) and then configure your end machine to use the host's IP address and port 8118. No need for FoxyProxy, Chrome / OS settings work fine. You can check that it's working on http://config.privoxy.org/

Looks like it. I'm building a custom image from source and can't reproduce the issue either.

Well, the easier alternative is to follow binhex advice and wait for someone more familiar with autodl-rutorrent codebase to have a look at the issue that you have reported. If you want to troubleshoot the issue by yourself I wouldn't expect much hand-holding, sorry. However, if you are ok with the frustration of being stuck, I'm not discouraging you from going down that route, trying to fix my own problems is how I got to learn a thing or two to share with the community. I'm not an arch guy but by what I understood you can clone the package source and run makepkg or install some of the many utilities to work with AUR packages. --- Other than trying to downgrade PHP you may also try to debug and investigate why you are getting errors from autodl-rutorrent plugin. Maybe you have a misconfiguration issue, or maybe something that used to be normal isn't anymore. PHP 7.4 is known to be much more strict than PHP 5.6. Having a quick look at your ticket and the source at https://github.com/autodl-community/autodl-rutorrent/blob/master/getConf.php#L46-L61 it looks like something that is assumed by the code to be a an array is actually a boolean ($userInfo maybe?). Once you understand where the code is chocking it's going to be easier to understand what is happening (wrong UID maybe? You can always log the uid to the console and verify if it exists in the container). Or maybe you can take the shotgun approach and modify the code to fix the issue. E.g., for the hypothetical and unverified scenario above you could add a check to confirm that $userInfo is an array: if (is_array($userInfo) && file_exists($userInfo['dir'].'... Assuming that you need a code change to fix your issue you may as well open a PR and contribute it upstream - even if you are not a PHP Developer, I'm certainly not :). Just my 2 cents.

Hey @td00, you can actually do it by yourself, although I've been running the container with PHP7 with no issues. In order to create your custom image running php5.6 first clone rtorrentvpn repo: https://github.com/binhex/arch-rtorrentvpn Then edit the following line to include the dependencies that you want: https://github.com/binhex/arch-rtorrentvpn/blob/master/build/root/install.sh#L53, for instance, you can replace php-fpm and php-geoip with php56-fpm and php56-geoip Finally you can run docker build command to build your custom image and run it locally with docker run. For more info about how to do that have a look at https://stackify.com/docker-build-a-beginners-guide-to-building-docker-images/

Hi Nora, unfortunately there ain't much that I can do to help since both problems are in the IRC side of things. As I've previously recommend, I would get acquainted with IRC (see https://opensource.com/article/16/6/irc-quickstart-guide for a quick start) as well as with the specific rules for each one of your trackers (you can generally find a Rules and FAQ for each private tracker) before even attempting to use autodl-irssi. Once you feel confident - IRC looks complicated but it really isn't - join each one of the tracker's respective IRC channels to figure out what went wrong. In the server where your bot has been k-lined you will have to join the tracker's IRC channel, respectfully ask to talk to an ops and try to understand for how long your bot has been banned. Depending on the tracker and channel it can take several hours until an ops can answer you - just wait and be polite. If it was banned permanently I would - again very respectfully - try to explain that you are new to autodl-irssi and inadvertently logged in as root, ask him if it's possible to lift the ban against your bot. Personal anecdote: I once had a VPN misconfiguration spam a tracker by quickly logging in and logging out of it (my torrent client logged in using dozens of different IPs in a few minutes). I don't have to say that I was banned. This what a very prestigious tracker associated with other very prestigious trackers that also banned my account. I was told by a lot of people that admins from this particular tracker were ruthless and that there wasn't much that I could do. By patiently waiting several days and politely explaining my mistake on IRC I managed to get unbanned. As for your second problem, once logged in to the right IRC server with a real client you can get a better understanding of why your bots are being ghosted. I can only guess, but two possibilities are that you are either: 1) Using the same user id as another user or 2) Mostly likely, you are logging in with two different IRC clients using the same set of credentials at the same time (e.g., you may be using the same user id and IRC key on two different channels from the same server, or maybe you are starting two different containers, both running autodl-irssi with the same credentials against the same server). I hope that this helps.

No problem. If I were you I would join your private tracker IRC channel and talk with mods to understand if you haven't been k-lined permanently and, maybe, if you can get unbanned (careful on how you approach mods, some private trackers are terrible). This is definitely on the IRC side of things instead of the container. If you are not familiar with NickServ I would Google for it (long story short, you want to register a unique username for your bot, make sure that only one process is ever using this nick and that autodl-irssi correctly identifies it).

To my untrained eyes The PGID and PUID looks ok. I'll leave the in-depth analysis of the logs to binhex. I was thinking about your problem though, are you always testing and getting K-Lined on the same server? If so, could you try a different one? Nowadays most servers are pretty reasonable and use bots that only temporarily ban users logging as root (generally for a few minutes), however, there are exceptions to the rule...

Try deleting the entire contents of /mnt/user/appdata/binhex-irssi and /mnt/user/Downloads/autodl. It's a long shot but some leftovers from previous runs may be getting in the way. PGID and PUID should be the same as the host user. That's ok. Docker doesn't map usernames (I.e., they don't match), all it does is to assign the host UID to the container user. For more info see: https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf Start by simplifying your setup so that you can get acquainted with the container. Stop both containers, remove them and prune docker system (docker system prune -af . Be warned that this command will discard all images and their related containers) This time start from scratch with a single container and IRSSI enabled. Use fresh folders (as in, the folders in the host should be empty when you first start the container), make sure to set the right PGID and PUID on the first run and make sure that all files are created with the right permission this time. With this new single container open rutorrent and configure a single filter / tracker / IRC server (if you are not acquainted with using rutorrent autodl-irrsi plugin see https://www.rapidseedbox.com/kb/use-rutorrents-autodl-irssi-plugin for more info - do not copy your IRSSI configuration files from other containers), check if autodl-irssi has connected as expected and new files are being downloaded correctly. Once you get to this point, if autodl-irssi is working correctly it should be easy to add your other trackers your on top of that. No problem. Hopefully the above steps will help.

-v /mnt/user/Downloads/autodl:/config \ -v /mnt/user/appdata/binhex-rtorrentirssi:/config If that's not a copy and paste error the above lines are wrong. What the two lines above are doing is to mount two different folders from the host (/mnt/user/Downloads/autodl and /mnt/user/appdata/binhex-rtorrentirssi) to the same place in the container (/config). This does not make much sense from a file system perspective and I really don't know what docker would try to do with it, this may be the cause of your issue. What you actually need is something like: -v /mnt/myuser/myrtorrentvpnfolder/data:/data \ -v /mnt/myuser/myrtorrentvpnfolder/config:/config Where /mnt/myuser/myrtorrentvpnfolder is a valid folder that you've created in your host. The folder above and everything bellow it should be owned by the user and group that you are passing to PUID and PGID. I would suggest creating fresh folders in the host and starting over (stop and delete your container and start everything from scratch pointing to the new folders).

Ok, I assume that this was done in the host right? (As in, your Unraid Box, not your container). You are mounting several volumes from your host into your container right? For instance, using the options bellow taken from rtorrentvpn's README: -v /root/docker/data:/data \ -v /root/docker/config:/config /root/docker/data and /root/docker/config are both folders in the host owned by a user (example: docker), this user most likely has read and write permissions to the folder that it owns. I'm not familiar with Unraid but if you have ssh access to your host, the following command will display the owner and group of a folder: ls -l /path/to/folder Once you know the owner of the group you can obtain the UID and GID with the id commad (https://kb.iu.edu/d/adwf), and pass it to your docker container. Don't forget do clean the folders before starting the container to avoid permission issues.

Just to verify. 1. You have created a new user in the host right? 2. Have you given access to your shared folders in the host to this new user? 3. Have you passed the new user's UID and GID through PUID and PGID docker's environment variables as mentioned in https://github.com/binhex/arch-rtorrentvpn/blob/master/README.md? Just to clarify, no new user has to be created in the container. Actually, you don't even need to create a new user in the host unless you need isolated permissions for security reasons, all that is required for you to do is to figure out the UID and GID of an existing user (in the host) with the right permissions to access the folders that you're sharing. Once you have the user's UID and GID, feed the values to the container using PUID and PGID environment variables.

Check out the conversation between WiperWoper, binhex and me starting bellow. Long story short, you need to set the right UID and GID.

While I know next to nothing about Unraid, I would like to add to binhex answer above. There are 3 layers to think about when setting up port forwarding: 1. rtorrent has to be configured to listen at the desired port (what you did with rtorrent.rc) 2. Docker has to publish the ports to the outside world (e.g, with -p 1234:1234) 3. Your router has to forward requests to your Unraid box. That's what you do in the router's admin interface passing your Unraid server IP and port. Other than that you may also want to set your router DHCP server to always allocate the same IP to your Unraid box so that the setup is stable. Cheers,

@WiperWoper, the commands to figure out the UID and GID should be run at the host (your sinology machine), not the container. As a good default pick whatever user that docker is running or that actually owns the folders that you are writing to. More info about uid / gid and docker: https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf I would also start from the scratch, delete all files created before and run a new container with the right IDs.

As always thank you very much @binhex (🍺 coming your way soon). Also thanks @DavidAUK for persisting with us through the troubleshooting

VPN_INCOMING_PORT is used in rtorrent.sh (although it is not documented and I'm not really sure if it's meant to be used directly). Could you try to set it with the desired port just for the sake of testing? IMO, as per my comment to binhex above, the port statements should not run for providers other than PIA (this is a code change that either myself or binhex would have to do), however, there is a chance that setting VPN_INCOMING_PORT will provide a temporary workaround for your problem. Could you please try it?

@binhex, now that I'm thinking about it, maybe the logic in rtorrent.sh should skip setting port-range and dht when provider is not PIA (or at least when VPN_INCOMING_PORT is empty). What do you think?

Hi David, the SCGI socket itself is static and fixed to 5000. It has nothing to do with port forwarding. Considering that the desired fixed VPN port is XXXXX, the lines that you need in rtorrent.rc are: network.port_range.set = XXXXX-XXXXX network.port_random.set = no And If you also need dht (for public trackers): dht.mode.set = auto dht.port.set = XXXXX Considering the error messages above it looks like either: 1) One of those lines are not in your rtorrent.rc; or 2) VPN_INCOMING_PORT environment variable is empty for some reason (check that it's set in your docker configuration and that you don't have any PIA specific setting like STRICT_PORT_FORWARD=yes) Let me know if the above helps.

I was thinking about your problem, looking at the watchdogs script, and assuming that all environment variables are set correctly, everything should work out of the box for you. Two things that may help figuring out what is happening. 1. Running a new container with DEBUG enabled and keeping an eye on the external IP, VPN IP, rTorrent IP and ports. Maybe something is not right with one of those values? 2. If you can't spot anything out of the ordinary in the logs, just open a terminal and use rtxmlrpc to inspect the values configured for your container. (E.g., with: rtxmlrpc network.local_address) My gut feeling is that one of the 4 values above is wrong for some reason.

Wow, kernel crash due to shfs, that brings me back down memory lane. Unfortunately I don't have experience with Unraid. Nevertheless a quick search through the forums tells me that shfs is still not the greatest piece of software ever written. Although I'm over my head here, if I may suggest a path to start troubleshooting your issue, I would try to start a new rtorrent container with fresh /data and /config volumes bound to locations on a local drive. If it works then try again mounting volumes on a separate network mount, finally try a fresh container with volumes on the same network mount. If everything works it may be that some of your old data is corrupted, if it fails, knowing at what exactly step it failed may help you understand what is happening. Kind regards,

Well, at least it's fixed Have you enabled "Start download automatically" in Autotools settings? https://github.com/Novik/ruTorrent/wiki/PluginAutotools Depends on how paranoid you are about the container modifying file permissions in your host's mounted volumes. I personally let the container do whatever it wants (UMASK 000) with data and config files. I have a dedicated "docker" user on the host and am correctly setting user and group ids during container startup (see notes at: https://github.com/binhex/arch-rtorrentvpn/blob/master/README.md). I'm actually enforcing file permissions at the host level instead of the container. I have a good set of ACL rules ( https://wiki.archlinux.org/index.php/Access_Control_Lists) that let docker do whatever it wants with its files and also grants some permissions to Plex (so that it can read fully downloaded files and write to some specific folders). Neither the docker nor the Plex user can do much else on my NAS. Otherwise the container is very well behaved and I don't have any reason to distrust it (and if @binhex, for whatever reason, decides to 777 random files we know where to complain :D).

Those are shell commands directly inside the container. To open a shell inside your container you can issue the following command in your host: docker exec -it <container name> sh

Ratio info should be saved to rtorrent.rc file in your mounted volume (the plugin ultimately issues xmlrpc commands to modify ratio settings in rtorrent itself). If settings are reverting to default my guess would be a problem with either the mounted volume or file permissions.