Merijeek

...just as an FYI, I haven't actually implemented the connected containers thing yet. However, since the PREVIOUS update you suggested, I haven't had to forcibly update the OpenVPN container (or manually get the Arrs to recheck their indexers and downloaders). So thanks for the help, and if I do have problems again I'll hit up the connected containers bit.

Good point. In that case it'd be Jackett, all the Arrs, and Qbittorrent.

Not using yours, though not for any particular reason. I'm sure there's a difference between, say, your Sonarr and linuxserer's, but I never put too much thought into it. Looks like I've got these of yours: ich777/sonarr ich777/radarr ich777/openvpn-client ich777/lidarr And a bunch that aren't: ghcr.io/mealie-recipes/mealie linuxserver/jackett binhex/arch-readarr lscr.io/linuxserver/duckdns binhex/arch-readarr netdata/netdata lscr.io/linuxserver/calibre lscr.io/linuxserver/bazarr binhex/arch-overseerr binhex/arch-jellyfin binhex/arch-plexpass binhex/arch-prowlarr hotio/overseerr binhex/arch-readarr ghcr.io/advplyr/audiobookshelf ghcr.io/ajnart/homarr gotson/komga binhex/arch-readarr deasmi/unraid-tailscale jlesage/jdownloader-2 jlesage/dupeguru jlesage/nginx-proxy-manager cr.hotio.dev/hotio/qbittorrent jaymoulin/jdownloader tzahi12345/youtubedl-material Honestly, I have zero issues switching them over. I can't imagine they'd be that difficult. If it'd help.

Awesome, I've added the variables and did the update. My main ones I'm using are basically Qbitorrent and most of the *arr suite. I don't know how quickly they freak if they lose access to download client or indexer. I'm betting 5 minutes can get past them if needed. I'll let this run and see what I can see as far as if this gets me past my issue or not. Thanks for the help. If you need the actual container names off github let me know and I can list them. I'm HOPING that I won't need to worry about bouncing the other containers if this guy notices and responds quickly enough. Whatever happens, thanks for all your effort on this. It's appreciated.

Hi everyone, especially @ich777! Been loving the docker-openvpn-client container. However, I've got one small problem I'm hoping I can get some help with. I've got it setup connecting to PIA and everything works fine. Most of the time. But, what I've got going on is that it will, spontaneously, lose connection. And then it's done. And everything that routes through it is also done. And because some of the things that route through it all rely on each other, I need to manually tell them all to check in with each other to get them up and working correctly again. Thing is...I've got no idea why this is happening. There's probably a way to get better logging out of the container that has a bigger buffer, but I don't know how to do that. No syslogs in the path that this docker uses that I can see. I just come back to something like this: ' 2024-04-11 07:33:27 RESOLVE: Cannot resolve host address: ca-vancouver.privacy.network:1197 (Temporary failure in name resolution) 2024-04-11 07:33:27 Could not determine IPv4/IPv6 protocol 2024-04-11 07:33:27 SIGUSR1[soft,Could not determine IPv4/IPv6 protocol] received, process restarting 2024-04-11 07:38:37 RESOLVE: Cannot resolve host address: ca-vancouver.privacy.network:1197 (Temporary failure in name resolution) 2024-04-11 07:38:47 RESOLVE: Cannot resolve host address: ca-vancouver.privacy.network:1197 (Temporary failure in name resolution) 2024-04-11 07:38:47 Could not determine IPv4/IPv6 protocol (and it goes on like this to fill the buffer) A restart of the container ALWAYS fixes this. It could be, though I'm not 100% sure, that the process restarting bit is from my adding "-inactive 3600 --ping 10 --ping-exit 60" to the container as an attempt to paper over this problem. But, it hasn't helped. Hoping someone can suggest a solution here, because as a solution for what I want to do, this container is fantastic, but having it fail for no reason (that I can find) ever 5 or 10 days is really annoying.

...are, unsurprisingly, causing a port conflict. So, when I create them (specifically, Readarr) I'm doing one at default 8787 and on at 18787. Should be fine. I'm routing them through an OpenVPN container, but I don't see that as the issue. Mostly because when I start my Readarr at 18787 I'm getting: The only reference I can find to a port 8787 in the Docker setup for this container is this: So I edit that, to make it an 18787. But I still end up with the same complaint in the log: I've absolutely got another instance of Readarr running, but it shouldn't be on that same port. I've even gone so far as to remove the WebUI value and change it to 18787. Can anyone offer a suggestion as to how to get around this problem?

OK, so to be clear, the misunderstanding here is that the delays are strictly there for containers that auto start when the disk array itself is started?

OK, I don't restart the array all THAT often. I was basing my complaint on my stopping all containers and then hitting the 'start all' button. Is that...incorrect?

Version 6.12.4. Like many people, I need some containers to wait for others before starting up to avoid issues. So I put them in order, and I did some delays. My understanding is that they'd boot top-down, and delay when they hit a delay. But as you can see from my delays and uptimes, that definitely isn't happening. Can someone explain what I'm doing wrong here?

Awesome, that did it. Thanks a bunch.

@ich777 - One more question on the OpenVPN container. I'd like to be able to have one of my Docker containers that get network via the OVPN container to be able to access something on my local 192.168.1.0/24 subnet. It looks like that isn't possible. Can you suggest a setting that might allow that?

Yeah, that was just a shot from before I did it. They're there and I can reach the containers behind it.

Here's some shots of my advanced QBT setup: As you can see, not much to it. However, I did add the FIREWALL variable to the OpenVPN container and so far I seem to be showing good: So...I'll throw a few more things in there and check back and see what I can see.

I don't know. I appear to have broken it via all the experimenting I was going. As far as me doing something differently, anything is possible, but I don't know how. So this is from scratch Completely basic setup: Created an OVPN file over at PIA, then put it and creds in the right spot: And it looks like it's up after a restart: My QBT and OVPN containers can both ping the outside world via DNS. I've got this happy and good and completely legal torrent that finished a few minutes ago: And I go and visit this site: https://ipleak.net/ and choose the "Torrent Address Detection" button, and then grab the magnet link and pop it into QBT: And when I go back to ipleak, I see: The top one being the VPN address, the bottom one being my own public IP. ....so then he goes ahead and does the same thing. Shuts down all dockers and changes the ovpn.vpn and auth.vpn files to the Privado versions. OVPN file is Privado's: ams-001.default (renamed, of course) Connected: Go back to IPLeak, grab a new magnet and put it into QBT: ...and poof, pretty much instantly Finally, lacking any better ideas, I change the DNS that the OVPN container is using. ....and boom, same as above. Meanwhile, on my extra Windows machine running the PIA client, I go through the same tests, and only my PIA VPN IP ever shows up in the ipleak site. I'm not saying I'm not possibly doing something wrong here, but I don't see how I can be.

As you can see above, I did. However, while doing all my screwing around, I can't even route through the OVPN container. Just not sure it's worth the effort. I've been trying to get everything off a windows box by shifting all this stuff to docker containers on the Unraid server. But it's turning out to be quite the headache. I'll start over one more time with the Privado setup through this container and see what we see.