Cat_Seeder
-
Posts
95 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Cat_Seeder
-
-
1 hour ago, puncho said:
Hi, I can't use port 6881 so looking to change the port. I went to rtorrent.rc in the config folder but don't see anywhere to change the incoming port connections (to 7881-7999). How can I change it? Do I need to change anything in the container page (and if so, what do I need to change/add)? Thank you!
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
-
1
-
-
1 hour ago, puncho said:
Any idea on where to start with this? Thanks
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/
-
2
-
-
6 hours ago, Tasteless said:
For the record, I don't think the issue lies with autodl-irssi or binhex's code. I think it is a messed up release on docker hub. If I build the image myself from source via binhex's git everything works great.
Looks like it. I'm building a custom image from source and can't reproduce the issue either.
-
3 hours ago, td00 said:
Thanks @Cat_Seeder I suppose this is my only option going forward.
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.
QuoteThe only other problem is that PHP56 is located on the AUR.
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.
-
5 hours ago, td00 said:
Hey @binhex,
Would it be possible for you to modify the image to include both PHP 7 and PHP56? The errors I'm getting with autodl might have to do with using PHP7 (which I know is probably preinstalled with the Arch image you're using) instead of PHP56. If you include it I might be able to go into the console and switch the versions to see if that corrects the issue.
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/
-
On 2/20/2020 at 4:40 PM, noraa said:
I haven't really got it to work yet.. I am still getting this "ERROR Closing Link: user_autodl[141.98.102.227] services.tracker.org (NickServ (GHOST command used by user_au1odl)" and on the trackers that I don't get this error I get this one "K-Lined: Don't IRC as root!". I'm glad the PGID/PUID is correct so that can be eliminated but, how do I solve the issue of getting K-Lined? I also can't seem to find anything in the other error. Like @Cat_Seeder said it is probably and IRC issue that can be solved with /NickServ but I have "/msg NickServ REGISTER Password Email" in the irssi settings and that doesn't seem to work either.
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.
-
1 hour ago, noraa said:
Ha odd thing is it actually does work on the other trackers... I have no clue why it doesn't on the others but they are actually the more important ones that I would be putting autodl-irssi to use. I guess I can start tweaking it though. Thank you!
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).
1 hour ago, noraa said:Edit - Scratch that it connects to the IRC chat and will monitor it for a few minutes on the other tracks but eventually drops out "ERROR Closing Link: user_autodl[141.98.102.227] services.tracker.org (NickServ (GHOST command used by user_au1odl)" with this error. I really don't know what to do to get it working.
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).
-
1 hour ago, noraa said:
Yup here you go!
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...
-
7 hours ago, noraa said:
Ya my fault that was a copy paste error the paths are
-v /mnt/user/appdata/binhex-irssi:/config \
-v /mnt/user/Downloads/autodl:/data \
I created a new user doing "useradd -u 1002 -g 214 autodl" and assigned those to the Environment Variables deleted the perms.txt and started the container everything except for perms.txt belongs to the "autodl" user.
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.
QuoteI've been trying to get this to work for a while now with no luck.. I've created new users and groups within unRAID as root and assigned the PGID/PUID to the Environment Variables with no luck I am still getting the same error. Does the PGID/PUID matter? Or can I assign any random number?
PGID and PUID should be the same as the host user.
QuoteAlso when I docker exec into the container it says my nick and user_name is "root".
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
QuoteI honestly have no idea what to do. I have 2 instances of rTorrent running 1 with the VPN and the 2nd one without and autodl-irssi enabled.
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.
QuoteThat being said I have to be doing something wrong so hopefully I can get it working in time. Thanks for all the help I appreciate it!
No problem. Hopefully the above steps will help.
-
5 hours ago, noraa said:
Correct it was done in the Unraid Box and not the container using "useradd -u 500 autodl" I have a mounting points for my Downloads and Config
-v /mnt/user/Downloads/autodl:/config \
-v /mnt/user/appdata/binhex-rtorrentirssi:/config \
Inputting the ls -l /mnt/user/appdata/binhex-rtorrentirssi I get the following https://pastebin.com/68prCuAe
It looks like every folder is going to the correct User/Group except for the perms.txt? I have tried deleting the Folder and relaunching with no success. Thanks for your patience and help.
Edit: So I managed to change the permission of the folders and now when I execute the ls -l command all of the directories are owned by the autodl user/group, however the error is still there. I noticed when launching the irssi it's giving me a user_name of root and a nick of root. Then this error
Closing link: ([email protected]) [K-Lined: Don't IRC as root!]
I'm out of ideas..
-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).
-
19 minutes ago, noraa said:
1. I executed the "Useradd" command as root creating the user with the UID/GID of 500.
Ok, I assume that this was done in the host right? (As in, your Unraid Box, not your container).
19 minutes ago, noraa said:2. Not entirely sure how to do this so this could be the issue? Sorry for the ignorance.
19 minutes ago, noraa said:How do I determine whether or not a user has the right permissions? I have also tried passing it to the other users that I have with no luck. Again sorry for the ignorance I really appreciate the help!
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.
-
51 minutes ago, noraa said:
Shouldn't it be running this with the newly created autodl user? I have changed it in the docker settings and deleted the perms.txt as well as the entire container and /config. Any suggestions are appreciated.
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.
-
38 minutes ago, noraa said:
I am also getting banned from the IRC' for attempting to use irc while root? I assume this means root user? How can I fix this? Any suggestions are appreciated sorry for the ignorance. Thank you
Check out the conversation between WiperWoper, binhex and me starting bellow. Long story short, you need to set the right UID and GID.
-
6 minutes ago, eman31 said:
Thanks for the reply and sorry to be a total noob, what IP address do I forward the port to on my router? Is it the address of my unraid server or does the docker have it's own IP? I've tried the server address but it still says the port is closed. Should the STRICT_PORT_FORWARD in the docker setting be set to "yes" or "no"? I previously had it set to yes running with PIA.
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,
-
1
-
1
-
-
@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.
-
-
13 minutes ago, DavidAUK said:
Thanks @Cat_Seeder. Genuinely appreciate the help.
Those lines are correct in my rtorrent.rc file. I just pulled a fresh rc file from the git repo and only changed the network.port_range.set line and it still didn't work. I don't use DHT so I think it's safe to rule that out.
The clues, as I see them, are the fact that the port is open and listening for a few minutes when it starts but then stops listening as it finishes initialising. I can fix it by setting it manually in the container. Also, there are lines in the log that say:
WARNING Not a valid number: '-' (invalid literal for int() with base 10: '-') INFO: Bad data packets written to '/tmp/xmlrpc2scgi-1000.xml' ERROR While calling network.bind_address.set('', '10.35.0.101'): <Fault -503: 'Invalid port_range argument.'STRICT_PORT_FORWARD was set to yes, but setting to no hasn't fixed the problem.
VPN_INCOMING_PORT isn't a environment variable for this container, is it?
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?
-
1
-
-
@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?
-
On 1/25/2020 at 10:04 PM, DavidAUK said:
Yes, I think you're right. The listening socket is not set when I use rtxmlrpc network.port_range to check it. It's listening as it starts, but then when rtorrent tries to connect to the web interface (if I'm understanding it right) it reconfigures and sets the listening port to null.
[info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP 10.35.0.101 different, marking for reconfigureHere's a log, which shows more.
2020-01-25 21:25:59,063 DEBG 'watchdog-script' stdout output: [info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP 10.35.0.101 different, marking for reconfigure 2020-01-25 21:26:20,367 DEBG 'watchdog-script' stdout output: WARNING Not a valid number: '-' (invalid literal for int() with base 10: '-') 2020-01-25 21:26:20,369 DEBG 'watchdog-script' stdout output: - 2020-01-25 21:26:25,509 DEBG 'watchdog-script' stderr output: INFO: Bad data packets written to '/tmp/xmlrpc2scgi-1000.xml' 2020-01-25 21:26:25,510 DEBG 'watchdog-script' stdout output: ERROR While calling network.bind_address.set('', '10.35.0.101'): <Fault -503: 'Invalid port_range argument.'The relevant lines in my rtorrent.conf look like this.
# SCGI Connectivity (for alternative rtorrent interfaces, XMLRPC) # # Use a IP socket with scgi_port, or a Unix socket with scgi_local. # schedule can be used to set permissions on the unix socket. # scgi_port = 0.0.0.0:5000 #scgi_local = /home/user/rtorrent/rpc.socket #schedule = scgi_permission,0,0,"execute.nothrow=chmod,\"g+w,o=\",/home/user/rtorrent/rpc.socket"Is that scgi_port setting incorrect? Thank you for your help! I feel like I'm getting closer.
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.
-
10 hours ago, DavidAUK said:
This worked for me. Thank you. How do I avoid doing this manually though?
For anyone who wants to try this for themselves, go to the shell in the container. To find out which ports are listening use
netstat -plntIf the port is not listening then you can dynamically set the port as Cat_Seeder describes by issuing the following commands.
rtxmlrpc network.port_range.set '' "XXXXX-XXXXX" rtxmlrpc dht.port.set '' "XXXXX"Where XXXXX is the rtorrent listening port. Then type the following command.
rtxmlrpc network.bind_address.set '' "The VPN assigned IP"I found the VPN assigned IP in the following line of rtorrentvpn container log where I've marked XX.XX.X.XX
Sat Jan 25 03:07:45 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS zz.z.z.z,dhcp-option DNS zz.z.z.z,sndbuf 524288,rcvbuf 524288,route zz.zz.z.z,topology net30,ping 5,ping-restart 30,compress,ifconfig XX.XX.X.XX zz.zz.z.zz,peer-id 0'Then issue the following command.
rtxmlrpc network.local_address.set '' "The External IP"I found the External IP in the following line of the rtorrentvpn.
[info] Successfully retrieved external IP address XX.XXX.XXX.XXXAfter I'd sent those four commands the netstat -plnt showed the port as listening, as did the rutorrent web interface.
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.
-
1
-
-
1 hour ago, Pirate said:
Any ideas whats causing this? No error in logs before the crash.
Heres a snippet from the crash.
Jan 22 20:49:55 Tower kernel: BUG: Bad page state in process shfs pfn:4c8407 Jan 22 20:49:55 Tower kernel: page:ffffea00132101c0 count:262144 mapcount:0 mapping:0000000000000000 index:0x1 Jan 22 20:49:55 Tower kernel: flags: 0x2fbff0000000000() Jan 22 20:49:55 Tower kernel: raw: 02fbff0000000000 dead000000000100 dead000000000200 0000000000000000 Jan 22 20:49:55 Tower kernel: raw: 0000000000000001 0000000000000000 00040000ffffffff 0000000000000000 Jan 22 20:49:55 Tower kernel: page dumped because: nonzero _count Jan 22 20:49:55 Tower kernel: Modules linked in: tun arc4 ecb md4 sha512_ssse3 sha512_generic cmac cifs ccm xt_nat macvlan ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod it87 hwmon_vid igb i2c_algo_bit e1000e edac_mce_amd kvm_amd kvm hid_logitech_hidpp k10temp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc i2c_piix4 ahci i2c_core libahci mpt3sas aesni_intel hid_logitech_dj wmi_bmof mxm_wmi aes_x86_64 crypto_simd cryptd ccp raid_class scsi_transport_sas glue_helper button wmi pcc_cpufreq acpi_cpufreq [last unloaded: i2c_algo_bit] Jan 22 20:49:55 Tower kernel: CPU: 4 PID: 25091 Comm: shfs Not tainted 4.19.94-Unraid #1 Jan 22 20:49:55 Tower kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5008 06/24/2019 Jan 22 20:49:55 Tower kernel: Call Trace: Jan 22 20:49:55 Tower kernel: dump_stack+0x67/0x83 Jan 22 20:49:55 Tower kernel: bad_page+0xec/0x106 Jan 22 20:49:55 Tower kernel: get_page_from_freelist+0x9f4/0xd0b Jan 22 20:49:55 Tower kernel: __alloc_pages_nodemask+0x150/0xae1 Jan 22 20:49:55 Tower kernel: ? __alloc_pages_nodemask+0x150/0xae1 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x35/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x41/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x35/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x41/0x70 Jan 22 20:49:55 Tower kernel: __do_page_cache_readahead+0x106/0x183 Jan 22 20:49:55 Tower kernel: ondemand_readahead+0x21d/0x22f Jan 22 20:49:55 Tower kernel: generic_file_read_iter+0x243/0x6d0 Jan 22 20:49:55 Tower kernel: __vfs_read+0xf9/0x132 Jan 22 20:49:55 Tower kernel: vfs_read+0xa4/0x124 Jan 22 20:49:55 Tower kernel: ksys_pread64+0x5d/0x79 Jan 22 20:49:55 Tower kernel: do_syscall_64+0x57/0xf2 Jan 22 20:49:55 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 22 20:49:55 Tower kernel: RIP: 0033:0x154aa5f36e27 Jan 22 20:49:55 Tower kernel: Code: 08 89 3c 24 48 89 4c 24 18 e8 b5 f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2d 44 89 c7 48 89 04 24 e8 e5 f3 ff ff 48 8b Jan 22 20:49:55 Tower kernel: RSP: 002b:0000154a7f3f8a50 EFLAGS: 00000297 ORIG_RAX: 0000000000000011 Jan 22 20:49:55 Tower kernel: RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 0000154aa5f36e27 Jan 22 20:49:55 Tower kernel: RDX: 0000000000020000 RSI: 0000154a602ba000 RDI: 0000000000000407 Jan 22 20:49:55 Tower kernel: RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 Jan 22 20:49:55 Tower kernel: R10: 000000001aa6a000 R11: 0000000000000297 R12: 0000154a7f3f8c18 Jan 22 20:49:55 Tower kernel: R13: 0000000000000000 R14: 0000154a6003ab78 R15: 0000000000000000 Jan 22 20:49:55 Tower kernel: Disabling lock debugging due to kernel taint Jan 22 20:49:55 Tower kernel: BUG: Bad page state in process shfs pfn:4c840d Jan 22 20:49:55 Tower kernel: page:ffffea0013210340 count:1048576 mapcount:0 mapping:0000000000000000 index:0x1 Jan 22 20:49:55 Tower kernel: flags: 0x2efff0000000000() Jan 22 20:49:55 Tower kernel: raw: 02efff0000000000 dead000000000100 dead000000000200 0000000000000000 Jan 22 20:49:55 Tower kernel: raw: 0000000000000001 0000000000000000 00100000ffffffff 0000000000000000 Jan 22 20:49:55 Tower kernel: page dumped because: nonzero _count Jan 22 20:49:55 Tower kernel: Modules linked in: tun arc4 ecb md4 sha512_ssse3 sha512_generic cmac cifs ccm xt_nat macvlan ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod it87 hwmon_vid igb i2c_algo_bit e1000e edac_mce_amd kvm_amd kvm hid_logitech_hidpp k10temp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc i2c_piix4 ahci i2c_core libahci mpt3sas aesni_intel hid_logitech_dj wmi_bmof mxm_wmi aes_x86_64 crypto_simd cryptd ccp raid_class scsi_transport_sas glue_helper button wmi pcc_cpufreq acpi_cpufreq [last unloaded: i2c_algo_bit] Jan 22 20:49:55 Tower kernel: CPU: 4 PID: 25091 Comm: shfs Tainted: G B 4.19.94-Unraid #1 Jan 22 20:49:55 Tower kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5008 06/24/2019 Jan 22 20:49:55 Tower kernel: Call Trace: Jan 22 20:49:55 Tower kernel: dump_stack+0x67/0x83 Jan 22 20:49:55 Tower kernel: bad_page+0xec/0x106 Jan 22 20:49:55 Tower kernel: get_page_from_freelist+0x9f4/0xd0b Jan 22 20:49:55 Tower kernel: __alloc_pages_nodemask+0x150/0xae1 Jan 22 20:49:55 Tower kernel: ? __alloc_pages_nodemask+0x150/0xae1 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x35/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x41/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x35/0x70 Jan 22 20:49:55 Tower kernel: ? __switch_to_asm+0x41/0x70 Jan 22 20:49:55 Tower kernel: __do_page_cache_readahead+0x106/0x183 Jan 22 20:49:55 Tower kernel: ondemand_readahead+0x21d/0x22f Jan 22 20:49:55 Tower kernel: generic_file_read_iter+0x243/0x6d0 Jan 22 20:49:55 Tower kernel: __vfs_read+0xf9/0x132 Jan 22 20:49:55 Tower kernel: vfs_read+0xa4/0x124 Jan 22 20:49:55 Tower kernel: ksys_pread64+0x5d/0x79 Jan 22 20:49:55 Tower kernel: do_syscall_64+0x57/0xf2 Jan 22 20:49:55 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 22 20:49:55 Tower kernel: RIP: 0033:0x154aa5f36e27 Jan 22 20:49:55 Tower kernel: Code: 08 89 3c 24 48 89 4c 24 18 e8 b5 f3 ff ff 4c 8b 54 24 18 48 8b 54 24 10 41 89 c0 48 8b 74 24 08 8b 3c 24 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2d 44 89 c7 48 89 04 24 e8 e5 f3 ff ff 48 8b Jan 22 20:49:55 Tower kernel: RSP: 002b:0000154a7f3f8a50 EFLAGS: 00000297 ORIG_RAX: 0000000000000011 Jan 22 20:49:55 Tower kernel: RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 0000154aa5f36e27 Jan 22 20:49:55 Tower kernel: RDX: 0000000000020000 RSI: 0000154a602ba000 RDI: 0000000000000407 Jan 22 20:49:55 Tower kernel: RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 Jan 22 20:49:55 Tower kernel: R10: 000000001aa6a000 R11: 0000000000000297 R12: 0000154a7f3f8c18 Jan 22 20:49:55 Tower kernel: R13: 0000000000000000 R14: 0000154a6003ab78 R15: 0000000000000000 Jan 22 20:49:55 Tower kernel: BUG: Bad page state in process shfs pfn:4c840e Jan 22 20:49:55 Tower kernel: page:ffffea0013210380 count:1310720 mapcount:0 mapping:0000000000000000 index:0x1 Jan 22 20:49:55 Tower kernel: flags: 0x2ebff0000000000() Jan 22 20:49:55 Tower kernel: raw: 02ebff0000000000 dead000000000100 dead000000000200 0000000000000000 Jan 22 20:49:55 Tower kernel: raw: 0000000000000001 0000000000000000 00140000ffffffff 0000000000000000 Jan 22 20:49:55 Tower kernel: page dumped because: nonzero _count Jan 22 20:49:55 Tower kernel: Modules linked in: tun arc4 ecb md4 sha512_ssse3 sha512_generic cmac cifs ccm xt_nat macvlan ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod it87 hwmon_vid igb i2c_algo_bit e1000e edac_mce_amd kvm_amd kvm hid_logitech_hidpp k10temp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc i2c_piix4 ahci i2c_core libahci mpt3sas aesni_intel hid_logitech_dj wmi_bmof mxm_wmi aes_x86_64 crypto_simd cryptd ccp raid_class scsi_transport_sas glue_helper button wmi pcc_cpufreq acpi_cpufreq [last unloaded: i2c_algo_bit]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,
-
1 hour ago, morreale said:
it does appear to be saving on two servers through restarts now. not sure why the original settings made did not hold.
Well, at least it's fixed
1 hour ago, morreale said:hopefully last question....
files are added and downloaded correctly. they are then moved using AutoTools to the correct location but end up in a "Pausing" state in the GUI and the path is not updated.
i haven't found a definitive cause to this issue. i have checked permissions / folder owners. (what are the correct settings? nobody?
Have you enabled "Start download automatically" in Autotools settings? https://github.com/Novik/ruTorrent/wiki/PluginAutotools
Quotelast thing i am leaning to - what should the UMASK during docker creation be set to 000, 1000?, 0? 777? or am I completely on the wrong path
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).
-
18 hours ago, DavidAUK said:
Thanks for the ideas. Do these lines go in rtorrent.conf or somewhere else?
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
-
6 hours ago, morreale said:
ok on to the next question.
i know you have to edit the rtorrent.rc file to save configuration changes but where do you save changes to the plugins?
for instance the Ratio Groups settings always revert back to default when editing via the gui.
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.
[Support] binhex - rTorrentVPN
in Docker Containers
Posted
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.