7thSon

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.

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.

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

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

I've rebooted the host multiple times since this issue arose... UPDATE: Christ almighty.... I found the problem.... the disk was FULL! *facepalm*

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?

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.

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

Did you have any further input on my lack of connectivity/traffic discussed on the previous page? I'm completely stuck with it.

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

Here's a screenshot of my folder settings:

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.

I attached the log from deluge with debug enabled. deluge.log

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?

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?

Does anyone have a working setup of rTorrent in the nzb360 app currently? It used to work for me, and I'm unsure of what's causing me to not be able to log in, but I'm thinking it might be the username/password settings for the container.

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.

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.

Yeah, it works again with that fix applied. Thanks.

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

I'm not able to set the "Incoming Port" in deluge UI to 58846, it reverts to 0 when I click "apply". Is this intended, or is it some kind of restriction/bug?

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.

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

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?

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?