7thSon

Members
  • Posts

    38
  • Joined

  • Last visited

Posts posted by 7thSon

  1. I'm having some trouble running this container unprivileged with openvpn.

    I've set it up with `net_admin` privileges, but when I start the container I see that there is an error at one point:

    2022-02-09 18:05:45,625 DEBG 'start-script' stdout output: iptables v1.8.4 (legacy): can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded.

     

    The iptables kernel modules loaded on my host are:

    ❯ sudo lsmod | rg iptable
    iptable_nat            16384  0
    iptable_filter         16384  0
    iptable_mangle         16384  0
    ip_tables              28672  3 iptable_filter,iptable_nat,iptable_mangle
    nf_nat                 45056  4 ipt_MASQUERADE,xt_nat,nft_chain_nat,iptable_nat

     

    If I restart the container in privileged mode, then everything starts up fully and works.

    I tried this with tags v3.10-01 and v0.9.8-01, it's the same on both. Does the container always need to run as root?

    Reading the docs it seems to me that root should only be required when using WireGuard?

     

    Any ideas as to why this wouldn't run unprivileged welcome.

  2. I solved my VPN issue above, it was just a permissions issue for the mounted folders.

    On another note though; is there any lightweight health check endpoint that can be used to check that the container is working properly? Something like a rest endpoint, or a cli command in the container to check would also be great.

  3. I'm having trouble running this container with Hashicorp Nomad as the orchestrator. I have given the container `net_admin` privileges, as well as running it globally privileged with `privileged = true`, with both bridge and host networks, but it seems that at some point the init script halts or ends up with a silent error that doesn't display what's wrong. From reading the logs it seems that the rtorrent process doesn't start up, but there seems to be no indication as to why, and that is with `DEBUG=yes` I am using a custom vpn provider, and all the config files including ovpn are working on docker-compose, which I am migrating away from.

     

    Are there any other privileges that are needed for the container to work properly? I am currently running `binhex/arch-rtorrentvpn:v3.10-01` which, as mentioned above, works with docker-compose. Also, worth mentioning is that when I set `VPN_ENABLED=no`, then the container seems to start up properly.

     

    Here's a hastebin of the container logs: https://www.toptal.com/developers/hastebin/rejecihudu.yaml

    And here are the interfaces found in the container:

    [root@2fb55f5c7112 /]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
    2: eth0@if2187: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
        link/ether 62:3e:1a:a3:25:3b brd ff:ff:ff:ff:ff:ff link-netnsid 0
        inet 172.26.64.95/20 brd 172.26.79.255 scope global eth0
           valid_lft forever preferred_lft forever
    3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
        link/none
        inet <>/22 brd <> scope global tun0
           valid_lft forever preferred_lft forever
  4. Has something changed recently as my VPN connection seems to be failing suddenly?

    The connection to my VPN provider is timing out for some reason, I haven't changed credentials or anything recently, except now that I started troubleshooting this by pulling down new config files and certs from the provider.

     

    There doesn't seem to be anything wrong with the IP that the openvpn client is trying to connect to, I tried pinging it from inside the container and there is a response. I also tried using the same .ovpn file from my deluge setup (binhex/arch-delugevpn) which works just fine, but the rtorrent container fails to connect with the same configuration.

     

    I am running watchtower on my server where rtorrent is running, so it would have pulled the latest image automatically, is it possible that a something broke with a recently pushed image?

     

    NOTE: I reverted to image v3.10-01 and the VPN connects successfully, there is indeed something wrong with the 'latest' tag.

     

    In the beginning the connection acually results in a TCP connection error:

    2020-09-18 22:36:44,887 DEBG 'start-script' stdout output:
    Fri Sep 18 22:36:44 2020 Socket Buffers: R=[131072->131072] S=[16384->16384]
    Fri Sep 18 22:36:44 2020 Attempting to establish TCP connection with [AF_INET]<IP>:443 [nonblock]
    
    2020-09-18 22:37:16,891 DEBG 'start-script' stdout output:
    Fri Sep 18 22:37:16 2020 TCP: connect to [AF_INET]<IP>:443 failed: Connection timed out

    Then the process just loops with this over and over:

    2020-09-18 22:38:18,195 DEBG 'start-script' stdout output:
    Fri Sep 18 22:38:18 2020 [UNDEF] Inactivity timeout (--ping-restart), restarting
    Fri Sep 18 22:38:18 2020 SIGHUP[soft,ping-restart] received, process restarting
    Fri Sep 18 22:38:18 2020 WARNING: file 'ovpn-tls.key' is group or others accessible
    Fri Sep 18 22:38:18 2020 WARNING: file 'credentials.conf' is group or others accessible
    Fri Sep 18 22:38:18 2020 OpenVPN 2.4.9 [git:makepkg/9b0dafca6c50b8bb+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 20 2020
    Fri Sep 18 22:38:18 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
    Fri Sep 18 22:38:18 2020 Restart pause, 2 second(s)
    
    2020-09-18 22:38:20,195 DEBG 'start-script' stdout output:
    Fri Sep 18 22:38:20 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    
    2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:
    Fri Sep 18 22:38:20 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Fri Sep 18 22:38:20 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    
    2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:
    Fri Sep 18 22:38:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]<IP>:443
    Fri Sep 18 22:38:20 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
    Fri Sep 18 22:38:20 2020 UDP link local: (not bound)
    Fri Sep 18 22:38:20 2020 UDP link remote: [AF_INET]<IP>:443

     

  5. 2 hours ago, binhex said:

    if you can write to the drive whilst inside the container and on the host then im kinda out of ideas here, perhaps a good old reboot of the host may resolve this.

    I've rebooted the host multiple times since this issue arose... :/

     

    UPDATE: Christ almighty.... I found the problem.... the disk was FULL! *facepalm*

    • Like 1
  6. 5 hours ago, binhex said:

    try changing the incomplete and completed to:-

    
    /home/nobody/incomplete

    and

    
    /home/nobody/completed

    this is purely a test to see if downloads will start, if so then the issue is related to writing to that drive, do not let this run for long as it will be writing inside the docker container.

    Yeah, writing inside the container to completed/incompleted works. Hmm... what the hell has happened with my mount of this disk...
    I tried going into /mnt/ntfs1/downloads on my host with my user that has the same UID/GUID as the container (1000:100), and running "touch test" works just fine. Looking in /etc/passwd in the container I can see that "nobody" is set up correctly as 1000:100.

    I also did "su nobody" in the container, went into the downloads folder and tried "echo 'write ok' > test", this also works just fine.

     

    What else can I check to find out why the container user isn't able to write to the disk/folder?

  7. 1 hour ago, binhex said:

    are you using unassigned devices plugin for this drive?, im assuming so, if so you need to set the slave options, or some such for it to work correctly, cant remember the details, is this set?.

     

    edit - found some reference to it here:- https://forums.unraid.net/topic/50727-62-slave-option-for-volume-setting-what-is-it-and-where-is-it-solved/

     

    No, I'm not running this under Unraid at all, just in a docker container on an arch host.

    I've never had issues with writing to the disk in any way.

  8. 3 hours ago, binhex said:

    try this, ssh to the unraid server and type the following (do NOT use the built in web ui console for the container):-

     

    
    docker exec -u nobody -it <name of container> bash

    then type:-

    
    echo "test perms" > /mnt/ntfs1/Downloads/test

    im guessing this will tell you it cannot write to that location, aka permissions issue, if so you need to fix this for the PUID and PGID that you specified.

    Writing to /mnt/ntfs1/Downloads/test works fine, the test file is created without any issues.

  9. 23 hours ago, strike said:

    Unless you changed the default volume mappings your download folder is wrong. Please post your docker run command or a screenshot of the container settings.

    The download folder is not wrong. Below is my docker-compose file.

    version: "3.2"
    services:
      deluge:
        restart: unless-stopped
        image: binhex/arch-delugevpn
        container_name: deluge
        cap_add:
          - NET_ADMIN
        devices:
          - /dev/net/tun
        ports:
          - 8112:8112
          - 8118:8118
          - 58746:58746 # incoming port
          - 58846:58846
        environment:
          PUID: "1000"
          PGID: "100"
          VPN_ENABLED: "yes"
          VPN_USER: "redacted"
          VPN_PASS: "redacted"
          VPN_PROV: "custom"
          STRICT_PORT_FORWARD: "no"
          ENABLE_PRIVOXY: "yes"
          LAN_NETWORK: "192.168.1.0/24"
          DELUGE_DAEMON_LOG_LEVEL: "info"
          DELUGE_WEB_LOG_LEVEL: "info"
          DEBUG: "true"
          UMASK: "000"
        volumes:
          - /home/user/.config/deluge/:/config
          - /mnt/ntfs1/Downloads:/mnt/ntfs1/Downloads
          - /etc/localtime:/etc/localtime:ro
        sysctls:
          net.ipv6.conf.all.disable_ipv6: 0

     

  10. 1 hour ago, binhex said:

    thats a successful start, have you set deluge incomplete and completed folders using the deluge ui?, screenshot.

    yeah I have the download folder set, I don't use the incomplete folder. tried applying it in the ui again, but there's no difference.

  11. Roughly a week back my delugevpn container stopped receiving traffic completely. Looking in the logs I can't find anything out of the ordinary, but when starting the container the pending downloads I have seem to start for like a second, then they all drop down to 0kb/s and stop there.

     

    How should I start to troubleshoot this?

  12. 6 hours ago, binhex said:

    yep i do, but im not sure what use it will be to you as its very specific to my setup (nginx reverse proxy and custom ports), not to mention i would have to scrub out a lot of the info due to security concerns, all i can say, is keep at it, its definitely achievable.

    Could we sort this out in PM, I'm also using a reverse proxy? I just need to see how you formatted your credentials etc so I can match my input to the app and the way I run rTorrent?

  13. 9 hours ago, jonathanm said:

    Working fine here on 3 different boxes. Try setting your VPN_ENABLED to no and see if it allows you to connect. If so, you need to investigate your VPN files and credentials.

    Setting VPN_ENABLED=no makes no difference. And how does VPN even affect the ability to connect to the deluge daemon?

    I just renamed my core.conf to core.conf.old and restarted deluge so it recreated the file, and now I can connect again. I recall this happening before, somehow the core.conf file get corrupted and I can't connect to the daemon.

    • Thanks 1
  14. Have there been some breaking updates to the container in regards to connecting to the daemon?
    I can't connect using either the deluge-console ("deluge-console -d localhost -p 58846 -U user -P password"), or the desktop client (2.0.4.dev23).

     

    I've been able to successfully connect to the daemon up until about a week ago.

    The only new error I've seen is the "ngettext" issue from python, but that seems unlikely to be the source of this problem.

  15. Has something been changed with the rutorrent-script with regard to nginx?

    A few days ago my rutorrent UI stopped responding, and checking the logs I find this on startup:

    2020-01-22 17:25:38,433 DEBG 'rutorrent-script' stderr output:
    ln: failed to create hard link '/home/nobody/bin/nginx' => '/usr/bin/nginx'
    2020-01-22 17:25:38,433 DEBG 'rutorrent-script' stderr output:
    : Operation not permitted
    
    2020-01-22 17:25:38,434 DEBG 'rutorrent-script' stderr output:
    /home/nobody/rutorrent.sh: line 342: /home/nobody/bin/nginx: No such file or directory
    
    2020-01-22 17:25:38,434 DEBG fd 21 closed, stopped monitoring <POutputDispatcher at 140256739577568 for <Subprocess at 140256739577520 with name rutorrent-script in state RUNNING> (stdout)>
    2020-01-22 17:25:38,434 DEBG fd 25 closed, stopped monitoring <POutputDispatcher at 140256739636848 for <Subprocess at 140256739577520 with name rutorrent-script in state RUNNING> (stderr)>
    2020-01-22 17:25:38,434 INFO exited: rutorrent-script (exit status 127; not expected)
    2020-01-22 17:25:38,434 DEBG received SIGCHLD indicating a child quit
    2020-01-22 17:25:40,703 DEBG 'watchdog-script' stdout output:
    [info] rTorrent process started
    [info] Waiting for rTorrent process to start listening on port 5000...
    
    2020-01-22 17:25:40,713 DEBG 'watchdog-script' stdout output:
    [info] rTorrent process listening on port 5000
    
    2020-01-22 17:25:40,720 DEBG 'watchdog-script' stdout output:
    [info] Autodl-irssi not enabled, skipping startup
    
    2020-01-22 17:25:40,721 DEBG 'watchdog-script' stdout output:
    [info] Initialising ruTorrent plugins (checking rTorrent is running)...
    
    2020-01-22 17:25:40,738 DEBG 'watchdog-script' stdout output:
    [info] rTorrent running
    [info] Initialising ruTorrent plugins (checking nginx is running)...

    The process hangs for a long time waiting for nginx with nothing happening

  16. On 7/22/2019 at 11:54 PM, binhex said:

    as a side note, most people actually want to remove authentication when reverse proxying, otherwise you are going to end up with two lots of authentication (one for reverse proxy and one for the app), but the decision is yours :-).

    What is the correct way of removing the ruTorrent authentication?

    I set "ENABLE_RPC2_AUTH=no" and restarted, still get auth dialog.
    Also tried removing rtorrent/config/nginx/security/auth and also still get auth dialog.

    Also tried just removing the admin user with the deluser.sh script, still same.

  17. 20 hours ago, binhex said:

    no im saying you need to add the following to your docker-compose or run command as per fryfrog's comments:-

    
    --device=/dev/net/tun

     

    it is already included, this particular problem only affects arch linux users, and as the fix is done n the host there is nothing i can do to fix it up for you automatically.

     

    I added the below lines in my docker-compose file, but I'm still getting the same error?

        devices:
          - /dev/net/tun:/dev/net/tun

    Also tried it like this with the same outcome:

        devices:
          - /dev/net/tun

     

    EDIT: Ah, I had a docker update pending, after a reboot it works again :)

  18. 4 hours ago, binhex said:

    See here for solution to tun:-

     

    https://github.com/binhex/arch-qbittorrentvpn/issues/10

     

    Sent from my EML-L29 using Tapatalk

    I checked the issue on github but I'm not quite following what you are suggesting I do. Are you saying I should enter the container when I create it and run the tun parts of the start.sh script at line 148 from another container? It didn't work when I tried.

     

    Why is the tun check not added to the delugevpn container, if it's a known issue?

     

     

  19. I needed to create a new container for deluge-vpn after changing my vpn password, but now I keep getting some errors when I check the container logs.
    I've been on an older image for quite some time (a couple of years probably), just starting and stopping it as needed, in case that matters.

     

    The errors from the container logs:

    [warn] 'iptable_mangle' kernel module not available, you will not be able to connect to the applications Web UI or Privoxy outside of your LAN
    2019-03-01T16:56:11.451257413Z [info] unRAID users: Please attempt to load the module by executing the following on your host:- '/sbin/modprobe iptable_mangle'
    2019-03-01T16:56:11.451265784Z [info] Ubuntu users: Please attempt to load the module by executing the following on your host:- '/sbin/modprobe iptable_mangle'
    2019-03-01T16:56:11.451273999Z 
    2019-03-01T16:56:11.451394124Z 2019-03-01 17:56:11,451 DEBG 'start-script' stdout output:
    2019-03-01T16:56:11.451406522Z [info] Synology users: Please attempt to load the module by executing the following on your host:- 'insmod /lib/modules/iptable_mangle.ko'
    
    ...
    
    2019-03-01T16:56:18.965140888Z Fri Mar  1 17:56:18 2019 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
    2019-03-01T16:56:18.965149495Z Fri Mar  1 17:56:18 2019 Exiting due to fatal error
    

    Checked the tun device and iptable_mangle in the container, they're not found:

    [root@2dce11e396c5 /]# cat /dev/net/tun 
    cat: /dev/net/tun: No such device
    [root@2dce11e396c5 /]# modprobe tun
    modprobe: FATAL: Module tun not found in directory /lib/modules/4.20.12-arch1-1-ARCH
    [root@2dce11e396c5 /]# /sbin/modprobe iptable_mangle
    modprobe: FATAL: Module iptable_mangle not found in directory /lib/modules/4.20.12-arch1-1-ARCH
    [root@2dce11e396c5 /]# 

    I'm running the container from a docker-compose file like this:

    version: '3.2'
    services:
      deluge-vpn:
        restart: unless-stopped
        image: binhex/arch-delugevpn
        container_name: deluge-vpn
        cap_add:
         - NET_ADMIN
        ports:
         - 8112:8112
         - 8118:8118
         - 58846:58846
         - 58946:58946
        environment:
         - PUID=1000
         - PGID=100
         - VPN_ENABLED=yes
         - VPN_USER=*username*
         - VPN_PASS=*password*
         - VPN_PROV=custom
         - STRICT_PORT_FORWARD=yes
         - ENABLE_PRIVOXY=yes
         - LAN_NETWORK=192.168.1.0/24
         - NAME_SERVERS=*ip-numbers*
         - DELUGE_DAEMON_LOG_LEVEL=info
         - DELUGE_WEB_LOG_LEVEL=info
         - DEBUG=false
         - UMASK=000
        volumes:
         - /apps/docker/deluge/data:/data
         - /apps/docker/deluge/config:/config
         - /home/user/.config/deluge/state:/config/state
         - /mnt/Downloads:/mnt/Downloads
         - /etc/localtime:/etc/localtime:ro

    My host machine is running Arch, on which I'm not connecting to openvpn at the moment.

    What am I missing?