bah1976

So i did a dumb thing. I accidentally copied another binary over the tar binary in /usr/bin - how can I get it back? I have no idea what version or size it used to be. I feel like a moron.

Ok, I don't know what happened, or when, but my radarr thinks I'm new all of a sudden. "You must be new around here, before you start adding movies you may want to check out the following links on our wiki" But it also says: Downloaded and Monitored: 35 Downloaded, but not Monitored: 624 It may have happened when I updated unraid to 6.4 - that was a few weeks ago and I don't know that I've been in here since. But even though I can look at my /media folder from inside the docker and see everything, Radarr doesn't "know" about it? I tried to bulk import the folders, and it says no movies were found. My equivalent Sonarr works fine. Do I have to delete this docker's appdata and start over? Or is there something I can do to fix this? Appreciate any tips.

To close the loop on my LAN Access issue.. I use airvpn, and had updated the vpn_remote variable to match the remote target in my airvpn.ovpn config file. I left the vpn port at the default 1198 - and that was my issue. After looking again, I noticed that my ovpn file had "remote <server> 443" indicating that it was using port 443 instead. I changed the docker vpn_port variable to 443 - and viola - everything works. My airvpn account indicates both binhex VPN sessions are active (deluge & sabnzbd) and I can access from my LAN. The checkmytorrentip.net torrent indicates it has a vpn'd connection. All is well again in my world. This is all with 6.2 RC4. Thanks for your excellent docker work!!

From inside the container, eth0 doesn't bind to a specific physical eth0, right? eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.4 netmask 255.255.0.0 broadcast 0.0.0.0 ether 02:42:ac:11:00:04 txqueuelen 0 (Ethernet) RX packets 299 bytes 21045 (20.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 75 bytes 5600 (5.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

There is no v1 present. supervisord.log, starting with a new restart with empty log. As I read through this to verify no personal info, I noticed that it references eth0. I currently have eth0 & eth1 in an active/passive bond. ifconfig seems to indicate that eth1 is the active interface, based on the TX/RX bytes. Maybe that's a factor? I don't know iptables commands to see if I can tweak it to work. bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 ether 00:30:67:b1:fb:c7 txqueuelen 1000 (Ethernet) RX packets 2804489 bytes 2668606738 (2.4 GiB) RX errors 0 dropped 128266 overruns 0 frame 0 TX packets 2898495 bytes 2284148497 (2.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.10.19 netmask 255.255.255.0 broadcast 0.0.0.0 ether 00:30:67:b1:fb:c7 txqueuelen 1000 (Ethernet) RX packets 2615043 bytes 2598820213 (2.4 GiB) RX errors 0 dropped 1347 overruns 0 frame 0 TX packets 2056914 bytes 2216603088 (2.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 ether 02:42:36:a3:9a:22 txqueuelen 0 (Ethernet) RX packets 20666 bytes 3888671 (3.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 32217 bytes 31767732 (30.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 00:30:67:b1:fb:c7 txqueuelen 1000 (Ethernet) RX packets 128266 bytes 16767919 (15.9 MiB) RX errors 0 dropped 128266 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 00:30:67:b1:fb:c7 txqueuelen 1000 (Ethernet) RX packets 2676223 bytes 2651838819 (2.4 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2898495 bytes 2284148497 (2.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 memory 0xfe7e0000-fe800000 root@BEAST:/mnt/user/appdata/delugevpn_v2# cat supervisord.log 2016-08-18 13:56:35,283 CRIT Set uid to user 0 2016-08-18 13:56:35,283 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing 2016-08-18 13:56:35,287 INFO supervisord started with pid 14 2016-08-18 13:56:36,288 INFO spawned: 'start-script' with pid 17 2016-08-18 13:56:36,293 INFO spawned: 'webui-script' with pid 18 2016-08-18 13:56:36,299 INFO spawned: 'deluge-script' with pid 19 2016-08-18 13:56:36,301 INFO spawned: 'privoxy-script' with pid 20 2016-08-18 13:56:36,366 DEBG 'start-script' stdout output: [info] VPN is enabled, beginning configuration of VPN 2016-08-18 13:56:36,367 DEBG 'deluge-script' stdout output: [info] deluge config file already exists, skipping copy [info] VPN is enabled, checking VPN tunnel local ip is valid 2016-08-18 13:56:36,368 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-08-18 13:56:36,368 INFO success: webui-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-08-18 13:56:36,369 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-08-18 13:56:36,369 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2016-08-18 13:56:36,392 DEBG 'privoxy-script' stdout output: [info] VPN is enabled, checking VPN tunnel local ip is valid 2016-08-18 13:56:36,417 DEBG 'start-script' stdout output: [info] VPN provider defined as airvpn [info] VPN config file (ovpn extension) is located at /config/openvpn/AirVPN_United-States_UDP-443.ovpn 2016-08-18 13:56:36,423 DEBG 'start-script' stdout output: [info] Env vars defined via docker -e flags for remote host, port and protocol, writing values to ovpn file... 2016-08-18 13:56:36,441 DEBG 'start-script' stdout output: [info] VPN provider remote gateway defined as us.vpn.airdns.org [info] VPN provider remote port defined as 1198 [info] VPN provider remote protocol defined as udp 2016-08-18 13:56:36,496 DEBG 'start-script' stdout output: [info] Default route for container is 172.17.0.1 2016-08-18 13:56:36,514 DEBG 'start-script' stdout output: [info] Setting permissions recursively on /config/openvpn... 2016-08-18 13:56:36,554 DEBG 'start-script' stdout output: [info] Adding 192.168.10.0/24 as route via docker eth0 2016-08-18 13:56:36,555 DEBG 'start-script' stdout output: [info] ip route defined as follows... -------------------- 2016-08-18 13:56:36,556 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.10.0/24 via 172.17.0.1 dev eth0 2016-08-18 13:56:36,557 DEBG 'start-script' stdout output: -------------------- 2016-08-18 13:56:36,564 DEBG 'start-script' stdout output: [info] iptable_mangle module not supported, attempting to load... 2016-08-18 13:56:36,567 DEBG 'start-script' stderr output: modprobe: FATAL: Module iptable_mangle not found in directory /lib/modules/4.4.15-unRAID 2016-08-18 13:56:36,567 DEBG 'start-script' stdout output: [warn] iptable_mangle module not supported, you will not be able to connect to Deluge webui or Privoxy outside of your LAN 2016-08-18 13:56:36,638 DEBG 'start-script' stdout output: [info] iptables defined as follows... -------------------- 2016-08-18 13:56:36,640 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 1198 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT -A INPUT -s 192.168.10.0/24 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT -A INPUT -p udp -m udp --sport 53 -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 1198 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8112 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT -A OUTPUT -d 192.168.10.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -------------------- 2016-08-18 13:56:36,640 DEBG 'start-script' stdout output: [info] nameservers 2016-08-18 13:56:36,641 DEBG 'start-script' stdout output: nameserver 8.8.8.8 nameserver 8.8.4.4 2016-08-18 13:56:36,650 DEBG 'start-script' stdout output: -------------------- [info] Starting OpenVPN... 2016-08-18 13:56:36,676 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 OpenVPN 2.3.11 x86_64-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on May 12 2016 2016-08-18 13:56:36,677 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 library versions: OpenSSL 1.0.2h 3 May 2016, LZO 2.09 2016-08-18 13:56:36,684 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 Control Channel Authentication: tls-auth using INLINE static key file 2016-08-18 13:56:36,687 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2016-08-18 13:56:36,690 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Aug 18 13:56:36 2016 Socket Buffers: R=[212992->212992] S=[212992->212992] 2016-08-18 13:56:36,714 DEBG 'start-script' stdout output: Thu Aug 18 13:56:36 2016 UDPv4 link local: [undef] Thu Aug 18 13:56:36 2016 UDPv4 link remote: [AF_INET]104.129.24.154:1198

See pics.. I left out my user & password, obviously..

Yes, I've disabled & re-enabled the docker service as well..

It's been restarted many times - no difference..

Recently refreshed my delugevpn & sabnzbvpn containers due to 6.2 update. I can't connect to the admin interface from my LAN. Logs seem to indicate everything is running ok, but I can't get into the interfaces to confirm any activity. I have my LAN_NETWORK set as 192.168.10.0/24 I see this: [warn] iptable_mangle module not supported, you will not be able to connect to Deluge webui or Privoxy outside of your LAN But a) I'm trying to connect from inside my LAN (although not the bridged 172.16.x.x) and b) I thought that didn't matter with the change to LAN_NETWORK from LAN_RANGE. Any tips?

Hmm... I don't think I saw any traffic over my router's wan port while the backup was running when in bridge mode. It's possible that CrashPlan figured out I'm local. I'll continue testing..

Can you stop your other dockers and vms one at a time until this one starts without error? Curious to know what the conflict is, hopefully there is a work around. Figured out the conflict - but I don't know how to resolve.. Sparklyballs' MythTv container is where the VNC server is coming from. http://lime-technology.com/forum/index.php?topic=41110.0 I'm able to RDP into that container on port 3389 to a desktop of some sort, I don't know if there is a VNC component to that connection. MythTv is currently in host networking and is working well, and I hate to break it if it's working. But I'll try changing it to bridge and mapping in all the ports (the MythTv dockerfile has this:EXPOSE 3310 3389 5000/udp 5002/udp 5004/udp 6543 6544 6760 65001 65001/udp ) I'm not sure if MythTv will have a similar issue of detecting the wrong IP. I know there's something in the MythTv backend setup where you set an IP - This will have to be verified. I'm also going to try crashplan in bridged mode with the ports and see what happens. I'll watch my router and see where the traffic goes. My original comment is an assumption, not based on any facts as of yet.. Or if somebody knows how to contact sparklyballs and ask him if vnc can be changed/removed, that would help too.

If I run in bridge mode with ports mapped, everything works just fine. However, my crashplan client on my laptop, that backs up to my server, reports the IP as the 172.something of the bridged network, causing it to use the external/public address since it thinks it isn't local. When I change it to host mode, I get this error sequence repeating in the log: Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running Obt-Message: Xinerama extension is not present on the server Obt-Message: XRandR extension is not present on the server Openbox-Message: A window manager is already running on screen 0 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/BEAST:1 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running I have nothing on 4280 or 4279, and as far as I know no other dockers on my server is running a VNC server. However, I found this: root@BEAST:~# netstat -tulpn | grep 5900 tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 3765/x11vnc root@BEAST:~# ps aux | grep 3765 root 3765 0.1 0.0 98080 9956 ? S 16:20 0:00 x11vnc -display :1 -xkb root@BEAST:~# ls -l /proc/3765/exe lrwxrwxrwx 1 root root 0 Feb 17 16:26 /proc/3765/exe -> /usr/bin/x11vnc So - I don't think this is a crashplan docker problem - but does anybody know how to identify where this x11vnc process came from so I can kill it and let crashplan run in host mode? Is there a way to identify what processes are being used by each container?

I have a problem that I'm pretty sure isn't specific to docker, but I don't know where to start. I'm running your delugevpn with airvpn connection, and it seems to be ok. I have this: Tracker Status: checkmytorrentip.net: Error: Success, Your torrent client IP is: x.x.x.x But any other torrent that I try to start just says this and won't start up. Tracker Status: openbittorrent.com: Error: Can you direct me where to look to figure out what might be in error? I don't think I see anything torrent-specific in the supervisord.log. I see a lot of these in the deluged.log: rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. Googling seems to find old stuff that isn't applicable to current version. Any thoughts on what to look at? I've just recreated my docker.img (for other reasons) and therefore have fresh image. Should I wipe the /config folder too and start over? Thanks for your thoughts..

I've done this, and am having no luck getting the console to connect. I continue to get an 'unable to connect to backup engine'. My console shows version 4.4.1 - I don't know how to find out if the engine is the correct version. When I looked at the ui_info file initially it was set to the loopback 127.0.0.1, not 0.0.0.0, so I've tried that, the 172.17.42.1, as well as my unraid IP 192.168.x.x I should note that I've had the Crashplan docker running for some time (a year or so?), and I've only just now tried the -Desktop container to try and manage it. I can see online that the backup was recently run, so I know that part is working. I haven't had a way to manage this in some time - I used to have another linux server that would connect to it, but that quit working awhile ago and I didn't have time to figure it out then as long as it kept running. But now with the ease of docker I want to get it back up and functional. I'd be happy to remove the container and start over with new crashplan /config directory, but I'm not confident on how to retain my crashplan ID - I have a lot of data backed up on crashplan central, and several friends backing up to me. I've also done the "turn it off & turn it back on" approach: Stop both the CrashPlan and CrashPlan-Desktop dockers Update the CrashPlan docker, give it is a few minutes Update the CrashPlan-Desktop docker Any thoughts/direction? ***EDIT*** Thanks to LEIFGG's signature link!! I found my issue was in the my.service.xml file - it was listening on 127.0.0.1. I changed it to 0.0.0.0 as suggested, restarted everything, and it's all working well. Thanks!!