hammsandwich

Yes, the container has its own IP via macvlan, so its easy to distinguish this vs other Unraid traffic. Can you elaborate? I use a Palo Alto virtual firewall, and it does all my filtering and and traffic logging.

I have the Valheim server running on a specific IP, which I have NAT'ed and opened up externally on my firewall. It would be strange for SIP to be coming from your server, would it not? This is Valheim, I do not think there is voice chat enabled in the game. As soon as I start the container I see it trying to reach out to various IPs: 172.17.229.225 192.168.254.19 10.0.0.200 192.168.3.61 192.168.153.1 192.168.237.1 These are all internal IPs, and I do not have any of these network ranges on my internal network, so I see these in my firewall logs as drops. Could be internal IPs of people connecting to my server? I find this unlikely as I only have 4 external people connecting. Just some of the ports I am seeing, all UDP: 54678, 54676, 65468, 51777, 51779, 54056, 56492, 56496, 61559, 61557

Thanks for all the hard work on these dockers. I am host a private server and only allow my friends to connect via strict firewall rules (they give me their public IP to whitelist). I am seeing something pretty odd in my firewall logs. I am seeing lots of firewall from my server to internal IP addresses that are not on my network. 10.X addresses, 172.17 addresses. Since these addresses do not exist, all this traffic is getting dropped by the firewall. This traffic is all high UDP ports, 56000+. From local clients, I can see traffic passing between client and server on these, and wonder if this is normal. EDIT: I have the Valheim server running on a specific IP, which I have NAT'ed and opened up externally on my firewall.

As this docker relies on an older version of the upstream lancache dockers, and he is not tagging the builds or pulling tagged versions, I do not think this is currently possible.

Looks like a new version was built off a fork to remove snip proxy. Any pull this yet and see if it works? I am not in front of a computer to test.

Same here after latest update. Same error messages filling up nginx error logs.

I too am having this same issue. I have noticed actually my Unraid server idles at LOWER watts (10-15 watts lower) when the Windows VM with GPU pass-through is booted than when that VM is shutdown or sleeped. I might build a 1 CPU 2 GB VM to run and pass-through the GPU to while I am not using it. I have a RTX 2070 Super, and upgraded from a AMD RX 480 which I did not notice this issue.

So I have narrowed this down to being an issue with Unraid VMs accessing any binhex containers on the same Unraid host. From a separate client (i.e.laptop), everything works perfectly fine. I can access rutorrent UI, Privoxy, all working perfectly. From a VM on Unraid, I can access all my container UIs (netdata, radarr & sonarr [linuxserver]), but Privoxy and rutorrent UI remain inaccessible. Any ideas?

Hi. Thanks for all the hard work for this and all your other containers. I am having issues with getting Privoxy to function in any of your containers. I am running 6.7.0-rc5. When I run your rtorrent container, with privoxy flag set to yes, rtorrent works, vpn works, I can DL and UP torrents just fine. However, I cannot access the Privoxy port. Just firing this container up on its own results in the same behavior. When I set the proxy address in my browser all internet access dies until I remove it. Using Wireshark I see TCP Retransmission like the container is not listening on the port, but netstat confirms its listening. Look at the container itself, it looks like IPTables is dropping all my packets. I can watch the DROP packets grow as I attempt to make requests to the container. Chain INPUT (policy DROP 5735 packets, 345672 bytes) pkts bytes target prot opt in out source destination 415 446337 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0 6 1437 ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16 613 508227 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:1197 184 17355 ACCEPT tcp -- eth0 * 192.168.100.0/24 172.17.0.0/16 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 0 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 I am not sure what is causing the issue at this point. EDIT: I have multiple networks I access the container from, but none are working. The LAN_NETWORK variable I passed through is the local network my Unraid host lives on. Logs... 2019-03-27 20:08:41.014813 [info] System information Linux 0e63eb64d91b 4.19.31-Unraid #1 SMP Mon Mar 25 09:52:30 PDT 2019 x86_64 GNU/Linux 2019-03-27 20:08:41.037510 [info] PUID defined as '99' 2019-03-27 20:08:41.061268 [info] PGID defined as '100' 2019-03-27 20:08:41.141993 [info] UMASK defined as '000' 2019-03-27 20:08:41.161737 [info] Permissions already set for volume mappings 2019-03-27 20:08:41.183974 [info] VPN_ENABLED defined as 'yes' 2019-03-27 20:08:41.207072 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/CA Toronto.ovpn dos2unix: converting file /config/openvpn/CA Toronto.ovpn to Unix format... 2019-03-27 20:08:41.237058 [info] VPN remote line defined as 'remote ca-toronto.privateinternetaccess.com 1197' 2019-03-27 20:08:41.257092 [info] VPN_REMOTE defined as 'ca-toronto.privateinternetaccess.com' 2019-03-27 20:08:41.277559 [info] VPN_PORT defined as '1197' 2019-03-27 20:08:41.300507 [info] VPN_PROTOCOL defined as 'udp' 2019-03-27 20:08:41.320781 [info] VPN_DEVICE_TYPE defined as 'tun0' 2019-03-27 20:08:41.340612 [info] VPN_PROV defined as 'pia' 2019-03-27 20:08:41.360414 [info] LAN_NETWORK defined as '192.168.100.0/24' 2019-03-27 20:08:41.380493 [info] NAME_SERVERS defined as '209.222.18.222,209.222.18.218' 2019-03-27 20:08:41.400990 [info] VPN_USER defined as '##########' 2019-03-27 20:08:41.420590 [info] VPN_PASS defined as '###########' 2019-03-27 20:08:41.440432 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS) 2019-03-27 20:08:41.460092 [info] Starting Supervisor... 2019-03-27 20:08:41,551 INFO Included extra file "/etc/supervisor/conf.d/privoxy.conf" during parsing 2019-03-27 20:08:41,551 INFO Set uid to user 0 succeeded 2019-03-27 20:08:41,553 INFO supervisord started with pid 6 2019-03-27 20:08:42,554 INFO spawned: 'start-script' with pid 126 2019-03-27 20:08:42,555 INFO spawned: 'watchdog-script' with pid 127 2019-03-27 20:08:42,556 INFO spawned: 'privoxy-script' with pid 128 2019-03-27 20:08:42,556 INFO reaped unknown pid 7 2019-03-27 20:08:42,559 DEBG 'start-script' stdout output: [info] VPN is enabled, beginning configuration of VPN 2019-03-27 20:08:42,560 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2019-03-27 20:08:42,560 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2019-03-27 20:08:42,560 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2019-03-27 20:08:42,561 DEBG fd 17 closed, stopped monitoring <POutputDispatcher at 23044378945584 for <Subprocess at 23044378470160 with name privoxy-script in state RUNNING> (stdout)> 2019-03-27 20:08:42,561 DEBG fd 21 closed, stopped monitoring <POutputDispatcher at 23044379402824 for <Subprocess at 23044378470160 with name privoxy-script in state RUNNING> (stderr)> 2019-03-27 20:08:42,561 INFO exited: privoxy-script (exit status 0; expected) 2019-03-27 20:08:42,561 DEBG received SIGCLD indicating a child quit 2019-03-27 20:08:42,598 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2019-03-27 20:08:42,600 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2019-03-27 20:08:42,602 DEBG 'start-script' stdout output: [info] Adding 209.222.18.218 to /etc/resolv.conf 2019-03-27 20:08:42,650 DEBG 'start-script' stdout output: [info] Docker network defined as 172.17.0.0/16 2019-03-27 20:08:42,653 DEBG 'start-script' stdout output: [info] Adding 192.168.100.0/24 as route via docker eth0 2019-03-27 20:08:42,653 DEBG 'start-script' stdout output: [info] ip route defined as follows... -------------------- 2019-03-27 20:08:42,654 DEBG 'start-script' stdout output: default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.4 192.168.100.0/24 via 172.17.0.1 dev eth0 2019-03-27 20:08:42,654 DEBG 'start-script' stdout output: -------------------- 2019-03-27 20:08:42,674 DEBG 'start-script' stdout output: [info] iptables defined as follows... -------------------- 2019-03-27 20:08:42,674 DEBG 'start-script' stdout output: -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1197 -j ACCEPT -A INPUT -s 192.168.100.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1197 -j ACCEPT -A OUTPUT -s 172.17.0.0/16 -d 192.168.100.0/24 -o eth0 -p tcp -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT 2019-03-27 20:08:42,675 DEBG 'start-script' stdout output: -------------------- 2019-03-27 20:08:42,676 DEBG 'start-script' stdout output: [info] Starting OpenVPN... 2019-03-27 20:08:42,731 DEBG 'start-script' stdout output: Wed Mar 27 20:08:42 2019 WARNING: file 'credentials.conf' is group or others accessible Wed Mar 27 20:08:42 2019 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018 Wed Mar 27 20:08:42 2019 library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10 2019-03-27 20:08:42,732 DEBG 'start-script' stdout output: [info] OpenVPN started 2019-03-27 20:08:42,732 DEBG 'start-script' stdout output: Wed Mar 27 20:08:42 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.67.41:1197 2019-03-27 20:08:42,732 DEBG 'start-script' stdout output: Wed Mar 27 20:08:42 2019 UDP link local: (not bound) Wed Mar 27 20:08:42 2019 UDP link remote: [AF_INET]172.98.67.41:1197 2019-03-27 20:08:43,023 DEBG 'start-script' stdout output: Wed Mar 27 20:08:43 2019 [5f2d76bec334993911ead2379ec24b00] Peer Connection Initiated with [AF_INET]172.98.67.41:1197 2019-03-27 20:08:44,198 DEBG 'start-script' stdout output: Wed Mar 27 20:08:44 2019 auth-token received, disabling auth-nocache for the authentication token 2019-03-27 20:08:44,198 DEBG 'start-script' stdout output: Wed Mar 27 20:08:44 2019 TUN/TAP device tun0 opened Wed Mar 27 20:08:44 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 2019-03-27 20:08:44,198 DEBG 'start-script' stdout output: Wed Mar 27 20:08:44 2019 /usr/bin/ip link set dev tun0 up mtu 1500 2019-03-27 20:08:44,199 DEBG 'start-script' stdout output: Wed Mar 27 20:08:44 2019 /usr/bin/ip addr add dev tun0 local 10.6.10.10 peer 10.6.10.9 2019-03-27 20:08:44,202 DEBG 'start-script' stdout output: Wed Mar 27 20:08:44 2019 Initialization Sequence Completed 2019-03-27 20:08:44,291 DEBG 'watchdog-script' stdout output: [info] Privoxy not running 2019-03-27 20:08:44,291 DEBG 'watchdog-script' stdout output: [info] Attempting to start Privoxy... 2019-03-27 20:08:45,295 DEBG 'watchdog-script' stdout output: [info] Privoxy process started [info] Waiting for Privoxy process to start listening on port 8118... 2019-03-27 20:08:45,298 DEBG 'watchdog-script' stdout output: [info] Privoxy process listening on port 8118

I am having an issue with the latest 2 builds, 0.9.7-1-08 and 0.9.7.-1-09. I have been running and updating this container on a Synology with PIA for some time now without issue (disabling apparmor still). Last week I updated to the latest version -08 at the time, and my logs indicate a DNS issue. Today I saw a new version was release, and updated to -09, and the problem persists. 0.9.7-1-07 appears to be working properly at this time. See errors below. 2018-08-15 18:44:56,578 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2018-08-15 18:44:56,586 DEBG 'start-script' stdout output: [info] Adding 209.222.18.218 to /etc/resolv.conf 2018-08-15 18:44:56,594 DEBG 'start-script' stdout output: [info] Adding 1.1.1.1 to /etc/resolv.conf 2018-08-15 18:44:56,601 DEBG 'start-script' stdout output: [info] Adding 9.9.9.9 to /etc/resolv.conf 2018-08-15 18:44:57,514 DEBG 'start-script' stderr output: random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed 2018-08-15 18:44:57,519 DEBG 'start-script' stdout output: [crit] ca-toronto.privateinternetaccess.com cannot be resolved, possible DNS issues 2018-08-15 18:44:57,520 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 139872939437808 for <Subprocess at 139872939280288 with name start-script in state RUNNING> (stderr)> 2018-08-15 18:44:57,520 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 139872939600280 for <Subprocess at 139872939280288 with name start-script in state RUNNING> (stdout)> 2018-08-15 18:44:57,520 INFO exited: start-script (exit status 1; not expected) 2018-08-15 18:44:57,521 DEBG received SIGCLD indicating a child quit Both -08 and -09 exhibit the same behavior, while -07 works perfectly. I have also notice the same exact issue with the sabnzbdvpn container. Please let me know if you need any additional information.

I was the initial person on this forum to point out the issue the this container on Synology and the AppArmor issues. I am also the same person who posted that on Reddit. I have opened a trouble ticket, as well as put in a feature request and posted on the Synology forums (https://forum.synology.com/enu/viewtopic.php?f=3&t=118103). Unfortunately, I still have not found a resolution other than disabling AppArmor. Another interesting issue I have run into is Docker refuses to start other other containers after I disable AppArmor. I have a startup script that runs on my Synology, which starts all my other containers, loads the proper kernel modules for this docker, and then disables AppArmor. docker start mysql //EXAMPLE CONTAINER TO START insmod /lib64/modules/tun.ko insmod /lib64/modules/iptable_mangle.ko insmod /lib64/modules/xt_mark.ko ##Disabling apparmor /usr/syno/etc.defaults/rc.sysv/apparmor.sh stop I have recently been seeing posts indicating people have installed an un-castrated version of Docker on their Synology. I might give this a shot (after backing all my data up of course).

This looks a lot like the permissions issue I was getting due to apparmor and the symlink to the nginx config.

what are you changing in the rtorrent.rc file?, it should be simply changing to the values below:- # Enable DHT support for trackerless torrents or when all trackers are down. # May be set to "disable" (completely disable DHT), "off" (do not start DHT), # "auto" (start and stop DHT as needed), or "on" (start DHT immediately). # The default is "off". For DHT to work, a session directory must be defined. # dht = off # Enable peer exchange (for torrents not marked private) # peer_exchange = no keep in mind if your editing using windows notepad then you could be screwing up the line endings, use notepad++ and follow this for how to keep unix style line endings:- From the "Edit" menu, select "EOL Conversion" -> "UNIX/OSX Format". You can also set the default EOL in notepad++ via "Settings" -> "Preferences" -> "New Document/Default Directory" then select "Unix/OSX" under the Format box. Thank you, that worked perfectly. I was setting them both to "off". Also, thanks for the tip for the EOL in notepad++. Great to know.

I am having difficulties disabling DHT and Peer Exchange. When I do it through the UI, it re-enables after the container is restarted. If I change the settings via rtorrent.rc, the container never starts.

The webui never loads if I dont enable the iptable_mangle module. Might just be my Synology though. Also, Synology support also informed me there is nothing they can do to fix the apparmor issue I am facing with this container. For now, disabling apparmor is my only option. I have this container working perfectly in Ubuntu 16.04 with apparmor enabled. What would happen if I mapped the nginix.conf through Docker to the appropriate path in the container?

Docker does rely some on host kernel modules and libraries, even though the containers are isolated. The modules might be on your system, just not loaded on startup. You can manually load them using the insmod command like i showed. Those paths are also the common path those modules, but I am not familiar enough with unRAID to know offhand where they are. I am sure Google, or this great forum for unRAID can point you in the right direction.

Above in your quote is your issue. You do not have the proper kernel modules loaded. The three I needed to load to get this working were: insmod /lib/modules/tun.ko insmod /lib/modules/iptable_mangle.ko insmod /lib/modules/xt_mark.ko

docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: d91c7b3 Built: Fri Mar 18 04:44:54 UTC 2016 OS/Arch: linux/amd64 Server: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: d91c7b3 Built: Fri Mar 18 04:44:54 UTC 2016 OS/Arch: linux/amd64 On a side note, I have been running your Deluge container with no issue for the past couple weeks until I can get this working. That one works perfectly, however I noticed it does not use nginx.

ya it is -R. Still did not work. Deleting the entire config directory and standing up a new container also did not work. I tried the latest docker as root, UID=0 GID=0, and that also did not work.

ls -al /volume2/docker/rtorrent/config/nginx/config/ total 4 drwxrwxr-x 1 rtorrent users 20 Apr 13 11:13 . drwxrwxr-x 1 rtorrent users 38 Apr 13 11:13 .. -rwxrwxr-x 1 rtorrent users 3083 Apr 14 09:21 nginx.conf I chown rtorrent:users the whole /volume2/docker/rtorrent/* just to be sure, and deleted the perms.txt and reran the container and got the same result. I am going to delete the whole config folder, pull the container again, and start over to see what happens.

I am still seeing an error rated to the ngnix.conf file [emerg] 703#0: open() "/etc/nginx/nginx.conf" failed (13: Permission denied) I have deleted and repulled the docker, deleted and allowed the container to recreate all files. Here is my docker run command docker run -d \ --privileged=true \ -p 9080:9080 \ -p 9443:9443 \ -p 8118:8118 \ --name=rtorrentvpn \ -v /volume2/data:/data \ -v /volume2/docker/rtorrent/config:/config \ -v /etc/localtime:/etc/localtime:ro \ -e VPN_ENABLED=yes \ -e VPN_USER=p****** \ -e VPN_PASS=******** \ -e VPN_REMOTE=ca-toronto.privateinternetaccess.com \ -e VPN_PORT=1194 \ -e VPN_PROTOCOL=udp \ -e VPN_PROV=pia \ -e ENABLE_PRIVOXY=yes \ -e LAN_NETWORK=192.168.1.0/24 \ -e DEBUG=false \ -e PUID=1030 \ -e PGID=100 \ binhex/arch-rtorrentvpn I have tried the same with airvpn config as well and get the same error. I also have tried running it with PUID = 0 PGID = 0 to no avail. I am attaching full logs. rtorrentvpn.txt

we are running bash inside the docker, this is true but if the docker daemon isnt running with superuser privileges then you may not be able to do certain actions inside the container, it is a bit odd and like i say it is a grasping of straws, but i really have come to end of any meaningful tests i can run. 2016-04-04 19:59:19,055 DEBG 'webui-script' stderr output: 2016/04/04 19:59:19 [emerg] 671#0: open() "/var/log/nginx/access.log" failed (13: Permission denied) @anybody - does anyone else see the issue above?, i certainly cannot replicate it at present on unraid 6.1.9 one thing im going to do tomorrow is fire up a ubuntu vm and create an account, and then run the docker container as that user and see what happens. If this works ok and then it must be some quirkiness with the way docker is running on OMV, if possible can you try running this again on unraid 6.2, i know you did this previously but i would assume it now works ok on this platform. I have the same issue in Synology DSM 5.2. I will be happy to provide logs if needed.

I am having the same issue as deagle. Permission denied errors, and not able to launch rTorrent. [info] All checks complete, starting rTorrent... 2016-03-30 17:13:07,083 DEBG 'rtorrent-script' stdout output: Script started, file is typescript 2016-03-30 17:13:07,084 DEBG 'rtorrent-script' stderr output: script: cannot open typescript: Permission denied 2016-03-30 17:13:07,084 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 140246045292376 for <Subprocess at 140246045188608 with name rtorrent-script in state STARTING> (stdout)> 2016-03-30 17:13:07,085 INFO exited: rtorrent-script (terminated by SIGTERM; not expected) 2016-03-30 17:13:07,086 DEBG received SIGCLD indicating a child quit 2016-03-30 17:13:08,089 INFO gave up: rtorrent-script entered FATAL state, too many start retries too quickly