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?