On 10/12/2019 at 5:00 AM, markomax said:

If I am to troubleshoot this by trying a run command with a different umask, user, or group, do I need to delete the "perms.txt" file in the config folder before running everything again?

yes, if you change the values of PUID and PGID then you MUST delete the file /config/perms.txt and restart the container, otherwise the permissions will not be reset for the newly defined PUID and PGID values and permissions will be wrong causing all sorts of issues.

On 10/12/2019 at 5:00 AM, markomax said:

I had Privoxy working for about a week by launching fresh without any files in the session folder, then loading (and rechecking) all of the torrents from a watched directory.  For some reason, the Privoxy folder is only created the first time I launch with no other files in the config folder except those created by running the image. As soon as I restarted it, I see no other message in the log except for "[info] Privoxy not running" exactly like the second log I uploaded.

 

I agree it is likely a permissions thing that I don't understand how to fix. The permissions seem correct when I look at users, groups and the shared folder on my Synology DSM. If I am to troubleshoot this by trying a run command with a different umask, user, or group, do I need to delete the "perms.txt" file in the config folder before running everything again?

This sounds somewhat similar to what I'm experiencing (Privoxy works without checked torrents but stops when there are torrents). Unfortunately I'm completely new to Docker and not sure what/how to provide required details but this can't be good:

Quote

 

2019-10-17 23:06:16,553 DEBG 'watchdog-script' stdout output:

rtorrent: Error in option file: ~/.rtorrent.rc:134: Could not prepare socket for listening: Address already in use

2019-10-17 23:06:16,561 DEBG fd 31 closed, stopped monitoring <POutputDispatcher at 140275705938384 for <Subprocess at 140275705858648 with name watchdog-script in state RUNNING> (stdout)>

2019-10-17 23:06:16,561 DEBG fd 35 closed, stopped monitoring <POutputDispatcher at 140275705938552 for <Subprocess at 140275705858648 with name watchdog-script in state RUNNING> (stderr)>

2019-10-17 23:06:16,562 INFO exited: watchdog-script (exit status 1; not expected)

2019-10-17 23:06:16,562 DEBG received SIGCHLD indicating a child quit

 

rtorrent does load after a while but Privoxy never does. Any help (or suggestions on what I can do to help you help me) is appreciated.

I'm running Docker on Windows, have checked my LAN is ok, I'm unsure about users PUID and GUID stuff on Windows so from what's said above it could well be permissions but I've no idea how to fix it.

Thanks in advance.

Love your work binhex - blows my mind how awesome your stuff is.

I spent a few hours tracking down this (outdated) bug: https://github.com/rakshasa/rtorrent/issues/472

The issue materialized as a torrent always stuck in the "queued" state, and could never start after multiple attempts.

There weren't any useful debug log messages that I could find, just a stuck torrent.

 

After tmux attaching to the rtorrent process, I found the rtorrent log, and eventually found the setting to fix it (which appears to be fixed in the unstable branch back in 2016😞

system.file.max_size.set = 3000G

 

This would be good to include as commented out default rtorrent.rc

 

It would also be nice if more errors were surfaced or a guide on raising log verbosity:

log.open_file = "rtorrentdbg", /config/log/rtorrent_debug.log
log.add_output = "debug", "rtorrentdbg" 

 

Hi, all

I'm playing to get this container to work as I want, but still have a few questions.

 

1) What STRICT_PORT_FORWARD variable means in container configuration?

 

2) It seems the rtorrent does not see the symlinks. I believe there is an option to set it as my rtorrent which was running on my old qnap NAS was working with symbolic links without any issues. Container sees folders inside, but not symbolic links. I can access symlinks either via SMB and NFS.

 

 

Edited October 21, 20196 yr by Salata

23 hours ago, Salata said:

Hi, all

I'm playing to get this container to work as I want, but still have a few questions.

 

1) What STRICT_PORT_FORWARD variable means in container configuration?

 

2) It seems the rtorrent does not see the symlinks. I believe there is an option to set it as my rtorrent which was running on my old qnap NAS was working with symbolic links without any issues. Container sees folders inside, but not symbolic links. I can access symlinks either via SMB and NFS.

 

 

1) see here:- https://github.com/binhex/documentation/blob/master/docker/guides/vpn.md

 

2) why are you trying to use symlinks?, better to create a volume mapping if you need to add in additional shares. im assuming you are creating the symlinks on your host?

On 10/21/2019 at 5:28 AM, jraid said:

system.file.max_size.set = 3000G

lol a 3TB torrent, that would take a while to hash :-), ok i can put in the setting commented out.

21 minutes ago, binhex said:

lol a 3TB torrent, that would take a while to hash :-), ok i can put in the setting commented out.

Yeah I know that's a bit extreme :p,

you can set it something lower, but the original limit of 128GB is now no longer out of the question.

 

While you're updating the settings file I also noticed 2 small inconsistencies:

Quote

#throttle.max_uploads.set = 15

is in there twice (both commented out)

 

Quote

 

# The example value allows incoming encrypted connections, starts unencrypted

# outgoing connections but retries with encryption if they fail, preferring

# plaintext to RC4 encryption after the encrypted handshake

 

This comment didn't get updated when the encryption options were:

Quote

protocol.encryption.set = allow_incoming,try_outgoing,enable_retry

 

Edited October 22, 20196 yr by jraid

Hi guys, so historically it has been difficult/impossible to change the listening port for rtorrent programmatically whilst its running, this lead to the only option which is to sigint rtorrent and change the port and then restart the process, this unfortunately can lead to situations where the process does not end nicely and thus rtorrent cannot be restarted.
 

Wind forward in time and this is now possible, however in order to do this we need to supply the credentials the authenticate with rtorrent before we can issues commands. As i don't know what each user has set their rpc2 and web ui passwords to (and i obviously shouldn't know this either!) then the only way for me to do this going forward is to allow the user to define the credentials for rpc2 and web ui as environment variables.
 

So from the next build if you have changed the username and password from the defaults (user admin, password rutorrent) then you will need to add in the following 'variables' :-
 

Key                 Value               Default         Description
RPC2_USER           <your username>     admin           sets the username for RPC2 auth
RPC2_PASS           <your passs>        rutorrent       sets the password for RPC2 auth
ENABLE_WEBUI_AUTH   yes/no              yes             sets web ui authentication for web ui (nginx) - if you are reverse proxying you probably want this set to no, otherwise yes.
WEBUI_USER          <your username>     admin           sets the username for web ui auth
WEBUI_PASS          <your passs>        rutorrent       sets the password for web ui auth

The above will result in a more stable rtorrent/rutorrent experience, whilst allowing us to maintain a working incoming port during all situations, i hope you agree a worthy improvement! (testing was a bitch).

 

Any questions please post them.

 

Edited October 22, 20196 yr by binhex

22 hours ago, binhex said:

 

Key                 Value               Default         Description
RPC2_USER           <your username>     admin           sets the username for RPC2 auth
RPC2_PASS           <your passs>        rutorrent       sets the password for RPC2 auth
ENABLE_WEBUI_AUTH   yes/no              yes             sets web ui authentication for web ui (nginx) - if you are reverse proxying you probably want this set to no, otherwise yes.
WEBUI_USER          <your username>     admin           sets the username for web ui auth
WEBUI_PASS          <your passs>        rutorrent       sets the password for web ui auth

 

 

Thanks for the post, I was wondering why my container didn't start properly. I set the keys in the unraid docker interface but my username and password is still the default.

 

edit: turns out both my set user/pass and the default works to login.

 

edit2: I had to manually remove the default admin/pass from webui_auth. Can you just create this from the environment variables instead of appending to it? 

Edited October 23, 20196 yr by psycho_asylum

1 hour ago, psycho_asylum said:

I had to manually remove the default admin/pass from webui_auth. Can you just create this from the environment variables instead of appending to it? 

ive read this three times and still cant work out what you mean :-), there is no webui_auth key, only enable_webui_auth and this is a toggle of value yes or no, can you clarify what you mean.

 

edit - twigged it, you mean the file, as in /config/nginx/security/webui_auth, well that will only be appended to if the file exists, if it doesnt exist then it will be created, there isnt really much i can do here, as people may in the future store more than one credential in the file, so i cant just delete it and re-create it every time, but it will update your password for your account if you specify an existing user.

Edited October 23, 20196 yr by binhex

15 minutes ago, binhex said:

ive read this three times and still cant work out what you mean :-), there is no webui_auth key, only enable_webui_auth and this is a toggle of value yes or no, can you clarify what you mean.

 

edit - twigged it, you mean the file, as in /config/nginx/security/webui_auth, well that will only be appended to if the file exists, if it doesnt exist then it will be created, there isnt really much i can do here, as people may in the future store more than one credential in the file, so i cant just delete it and re-create it every time, but it will update your password for your account if you specify an existing user.

There ya go, I should have included the entire path. If you change the environment variable in the docker ui, it keeps the previously entered user/pass combo. It requires manually editing that file to remove the user.  Just thought it'd be good to have it here in case someone else noticed the same.

Edited October 23, 20196 yr by psycho_asylum

1 minute ago, psycho_asylum said:

it keeps the previously entered user/pass

it will do that ONLY if the user is different, so if you ran it first time with the default of admin/rutorrent and then edited the docker and changed it to bob/wibble then yes you would need to delete the file in order to remove the admin/rutorrent credentials. as i previously stated, not much i can do about that, as people may well want multiple users and there is no way for me to decide what credentials need removing (if any).

Hi! 

 

I just swapped last week from your deluge vpn to this rtorrent vpn and it has been much better for me (extra features & performance) however today (since rc3 update) I am getting dog slow performance! don't know if it is related or not but no matter what browser I use it takes minutes to respond and constant timeouts, any ideas?  I am using a Threadripper with 40GB free ram and barely a tickle on the cores

 

2019-10-23 23:00:33,957 DEBG 'watchdog-script' stdout output:
[info] rTorrent running
[info] Initialising ruTorrent plugins (checking nginx is running)...

2019-10-23 23:00:33,965 DEBG 'watchdog-script' stdout output:
[info] nginx running
[info] Initialising ruTorrent plugins...

2019-10-23 23:00:34,010 DEBG 'watchdog-script' stdout output:


2019-10-23 23:00:34,032 DEBG 'watchdog-script' stdout output:
[info] ruTorrent plugins initialised

2019-10-23 23:30:35,333 DEBG 'watchdog-script' stdout output:
[info] Attempting to curl https://portchecker.co/check...

2019-10-23 23:30:36,398 DEBG 'watchdog-script' stdout output:
[info] Curl successful for https://portchecker.co/check, response code 200

2019-10-23 23:33:15,522 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:33:15 [error] 1214#1214: *1859 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"

2019-10-23 23:35:45,549 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:35:45 [error] 1214#1214: *1894 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"
 

I just wanted to install this docker for the first time, but after filling in all the information in the template I get this error

/usr/bin/docker: invalid publish opts format (should be name=value but got '5000:5000/tcp')

I'm assuming, that this has something to do with my port mapping. If I use other ports to map to container port 5000 I get that error too.

30 minutes ago, abb0r said:

I'm assuming, that this has something to do with my port mapping.

 

looks like it, whats your run command? port publishing should look like this:-

-p 5000:5000/udp

 

4 minutes ago, binhex said:

 

looks like it, whats your run command? port publishing should look like this:-

-p 5000:5000/udp

 

I'm using the community applications plugin to install, so I'm not running any commands by myself. So then something with that must be wrong.

16 minutes ago, abb0r said:

I'm not running any commands by myself.

The run command was right above the error message.

 

Re-add the app.  Apps - Previous Apps, click the install icon on the app, apply when the template comes up and post the docker run command that appears if it gets an error.

44 minutes ago, Squid said:

The run command was right above the error message.

 

Re-add the app.  Apps - Previous Apps, click the install icon on the app, apply when the template comes up and post the docker run command that appears if it gets an error.

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-rtorrentvpn' --net='bridge' --log-opt max-size='10m' --log-opt max-file='3' --privileged=true -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='vpn username' -e 'VPN_PASS'='vpn password' -e 'VPN_PROV'='pia' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'ENABLE_AUTODL_IRSSI'='no' -e 'ENABLE_RPC2'='yes' -e 'ENABLE_RPC2_AUTH'='yes' -e 'ENABLE_WEBUI_AUTH'='yes' -e 'RPC2_USER'='admin' -e 'RPC2_PASS'='rutorrent' -e 'WEBUI_USER'='admin' -e 'WEBUI_PASS'='rutorrent' -e 'LAN_NETWORK'='192.168.178.0/24' -e 'NAME_SERVERS'='209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1' -e 'DEBUG'='false' -e 'PHP_TZ'='UTC' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '5000:5000/tcp' -p '9080:9080/tcp' -p '9443:9443/tcp' -p '81181:8118/tcp' -v '/mnt/user/downloads/torrents/':'/data':'rw' -v '/mnt/cache/appdata/binhex-rtorrentvpn':'/config':'rw' 'binhex/arch-rtorrentvpn'

/usr/bin/docker: invalid publish opts format (should be name=value but got '5000:5000/tcp').
See '/usr/bin/docker run --help'.

The command failed.

That's the full run command with the error.

On 7/25/2019 at 11:05 AM, binhex said:

you need to edit the nginx configuration file nginx.conf and look for these lines:-

 

change this:- 

        location / {
            index index.html index.htm index.php;
            auth_basic "Restricted Content";
            auth_basic_user_file /config/nginx/security/auth;
        }

to this:-

        location / {
            index index.html index.htm index.php;
        }

make sure you do this for http and https, save and restart the container.

Is this no longer the case for disabling authentication?  I've been getting in a login loop externally, and checking it this file had reverted.

 

Editing nginx.conf again and restarting the container saved the file, but when I check it again, the lines have been put back in.  Is there now a different way to disable authentication (or is it no longer possible, or am I being stupid)?

Is this no longer the case for disabling authentication?  I've been getting in a login loop externally, and checking it this file had reverted.

 

Editing nginx.conf again and restarting the container saved the file, but when I check it again, the lines have been put back in.  Is there now a different way to disable authentication (or is it no longer possible, or am I being stupid)?

 

See post #3 in this thread, in short no you don't need to manually edit

 

Sent from my CLT-L09 using Tapatalk

 

 

 

36 minutes ago, binhex said:

See post #3 in this thread, in short no you don't need to manually edit

Perfect, thank you - added all of those settings to my template (for completeness) and set the auth flag to no.  All back to normal.

 

Apologies - I read that post the other day, and it didn't occur to me that I'd be affected.  Must've been tired. 

I have skimmed through this now lengthy 71 pages of support and would like to ask (that which has probably been asked but I didnt find).

Where in the gui of ruTorrent can I verify that my vpn (nord) is actually connected?

I know I applied my user creds set in the container variables but I was hoping to see something in the gui "vpn connected" or in the Settings.

 

Looking in the container logs I can see where it initially connected but I would prefer to get a gui notification or confirmation of the vpn status rather than having to periodically hitting the container logs to sift through for vpn status.

 

Otherwise it seems pretty sweet so far.

Thank you in advance.

Mike

3 hours ago, slidermike said:

I have skimmed through this now lengthy 71 pages of support and would like to ask (that which has probably been asked but I didnt find).

Where in the gui of ruTorrent can I verify that my vpn (nord) is actually connected?

I know I applied my user creds set in the container variables but I was hoping to see something in the gui "vpn connected" or in the Settings.

 

Looking in the container logs I can see where it initially connected but I would prefer to get a gui notification or confirmation of the vpn status rather than having to periodically hitting the container logs to sift through for vpn status.

 

Otherwise it seems pretty sweet so far.

Thank you in advance.

Mike

The docker won't start unless vpn connection is successful and you can test for further peace of mind here

https://www.vpnuniversity.com/bittorrent/how-to-check-your-torrent-ip-address

 

 

On 10/23/2019 at 11:47 PM, mbc0 said:

Hi! 

 

I just swapped last week from your deluge vpn to this rtorrent vpn and it has been much better for me (extra features & performance) however today (since rc3 update) I am getting dog slow performance! don't know if it is related or not but no matter what browser I use it takes minutes to respond and constant timeouts, any ideas?  I am using a Threadripper with 40GB free ram and barely a tickle on the cores

 

2019-10-23 23:00:33,957 DEBG 'watchdog-script' stdout output:
[info] rTorrent running
[info] Initialising ruTorrent plugins (checking nginx is running)...

2019-10-23 23:00:33,965 DEBG 'watchdog-script' stdout output:
[info] nginx running
[info] Initialising ruTorrent plugins...

2019-10-23 23:00:34,010 DEBG 'watchdog-script' stdout output:


2019-10-23 23:00:34,032 DEBG 'watchdog-script' stdout output:
[info] ruTorrent plugins initialised

2019-10-23 23:30:35,333 DEBG 'watchdog-script' stdout output:
[info] Attempting to curl https://portchecker.co/check...

2019-10-23 23:30:36,398 DEBG 'watchdog-script' stdout output:
[info] Curl successful for https://portchecker.co/check, response code 200

2019-10-23 23:33:15,522 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:33:15 [error] 1214#1214: *1859 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"

2019-10-23 23:35:45,549 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:35:45 [error] 1214#1214: *1894 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"
 

Hi @binhex sorry to nag but wonder if you have any ideas what could cause these performance issues?  it becomes unusable, lidarr, radarr, sonarr all lose connection to this docker and the UI is too slow to use.  It seems to sort itself out after a while and may be ok for hours then it does it again.  As I stated earlier, I have masses of resources available so don't know where to start with diagnosis.  Never had any issues with your deluge docker but need the features of rtorrent.

 

Thanks

5 minutes ago, mbc0 said:

Hi @binhex sorry to nag but wonder if you have any ideas what could cause these performance issues?  it becomes unusable, lidarr, radarr, sonarr all lose connection to this docker and the UI is too slow to use.  It seems to sort itself out after a while and may be ok for hours then it does it again.  As I stated earlier, I have masses of resources available so don't know where to start with diagnosis.  Never had any issues with your deluge docker but need the features of rtorrent.

 

Thanks

are you still running unraid 6.8.0 rc3?, if so and the issue started with that version i think your first thing to try is to roll back to the previous version that worked. i myself run this image and have zero performance issues with it (running unraid 6.7.2), so im confident that its something to do with your setup.