Merijeek

Ah. Never occurred to me to actually hit the remove button. I was just clearing them out figuring it would do the same thing. But actually thinking about it makes it clear that wouldn't be liked. I don't really see any evidence that the script has been loaded/run/whatever in the logs, but it is accessible: You can see on the right that it can see the script, and that once I bounced the OVPN container it stayed up with its loopback only. But, unless I'm missing something, I don't see the script being executed anywhere in the logs, either when the OVPN went down, or even on startup.

Well, I'd like to, but it's asking for pointers to hardware as far as I know: I've tried to leave these as the shown defaults, and zeroing them out and fails on creating:

@ich777 - question for you I've continued to notice that while the connected containers thing works for the containers using your repository, the attempted script isn't working for the others. Don't know why, but they are just never rebooting. Well, until I do it manually anyway. However, maybe I'm looking at things wrong. I looked at the linuxserver prowlarr, and from what I can see when it is "down" is that it just has no network interfaces apart from loopback: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2196 errors:0 dropped:0 overruns:0 frame:0 TX packets:2196 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:440358 (430.0 KiB) TX bytes:440358 (430.0 KiB) But after a fresh reboot I've got an eth0, an lo, and tun0. I'm no Docker expert. Is it expected that a reboot of the OVPN container would cause this? Is it normal?

Good thinking: /package/admin/s6-overlay-3.1.6.2/etc/s6-rc/scripts/cont-init: line 20: /etc/cont-init.d/91-connected-containers: Permission denied /package/admin/s6-overlay-3.1.6.2/etc/s6-rc/scripts/cont-init: line 20: /etc/cont-init.d/mam-cookie.sh: Permission denied So I guess next is to fix the permissions on those files. It's been a while, but doesn't this indicate that the world should have access to them read and write? root@UnRAID:/mnt/user/prod/scripts# ls -l *.sh -rw-rw-rw- 1 nobody users 238 Jun 14 10:30 cc-alpine.sh -rw-rw-rw- 1 nobody users 448 Jul 4 14:12 mam.sh

Both linuxserver: root@UnRAID:~# docker ps | grep qb 1f82127f3514 lscr.io/linuxserver/qbittorrent "/init" 2 days ago Up 15 hours qbittorrent-50004 root@UnRAID:~# docker ps | grep prow 1ebfa8d6bac5 lscr.io/linuxserver/prowlarr "/init" 33 seconds ago Up 30 seconds prowlarr-50005 (prowler I had just bounced, so time on there is because of that)

Here you are:

OK so I think any of your containers are working fine. This most recent problem time I had were with my Qbitorrent and Prowlarr containers. Neither of which have your Connected Containers bit built in. When I look inside them (left, Prowlarr, right Qbittorent) I seem to see the script correctly:

As far as I know, I did? That's Sonarr. It's definitely using the OPVN container OpenVPN--Client-1 for its network. And that's the OVPN container. If there's more that should be done inside it for config, I've missed it. But I don't think there was.

Alright, so I'm back into the connected containers rodeo. I've been having various (other) issues so haven't been working on this one. This morning I find my OpenVPN up 7 hours, Sonarr up 12, and Sonarr is inaccessible. From the OPVN setup: ...and from the Sonarr setup: Any thoughts on what I could have wrong here?

So, I've been having some general weirdness in my Dockers. Mostly, I've been finding that I need to bounce the things on a daily basis, which seems funny. Generally, they just go unresponsive. Now that I'm taking a serious look, one thing I've noticed on one of them (readarr) is that it's getting sqlite errors. Specifically, that it's trying to write to a read-only file. Which, you know, it isn't. At least it shouldn't be. I thought maybe my issue was my cache drive. According to the SMART report (attached) there doesn't seem to be anything too worrying, though I'm running an extended test to check it out. With the possibility of it being a read-only, I was going to see about running the new permissions utility, but everything seems to indicate that it should not be used on a cache drive. So...right now, just looking for general guidance on where to start looking for the causes of these errors. unraid-smart-20240704-1701.zip

So...a situation I've hit more than once, and I don't know what to do about it. I've got containers with their network type set to "none" and then they use an OVPN container for their network access. And in general it works fine. But, OK, I need to make a change to my OVPN docker. So I do whatever, and, oops, I did something that caused the redeployment to fail. The OVPN container is now no longer on my screen. And now all of my containers that reply on OVPN are in a "rebuilding" stage. All I need to do is get back into the OVPN container and fix whatever mistake I made. But I can't. Because (presumably?) all those rebuilds are going on, and I can't do any container actions on the Docker page because all of my buttons are greyed out. To fix this in the past, I've turned off any autostart dockers that use the OVPN, then gone under settings->docker and done a disable/enable. Then I can redeploy my OVPN with whatever issues fixed, and put everyone back to normal. Is there a better way to fix this situation?

(actually I lied) I understand what you're saying as a concept, but not how to implement it. Maybe it's my fundamental lack of Docker understanding, well, almost certainly, but let's break it down Barney Style I should add a path in my container setup so that the path /opt/scripts/user.sh maps to the actual script on my server. So....like this? Where mam.sh contains the block of scripting you sent me?

It does. Thanks, I'll give it a shot.

@ich777 - Is it possible using your OpenVPN container to run a script after the connection is made? For the sake of one tracker, I need to run this after the tunnel is up: (example, obviously) /path/docker/persists/tun_up.sh #!/bin/bash curl -c /path/docker/persists/mam.cookies -b /path/docker/persists/mam.cookies https://t.myanonamouse.net/json/dynamicSeedbox.php

I did notice it created the folder when I forgot to put the .sh the first time I did the path.

OK, done. I've got it set like this: The part where you seem to have a path in the container path but a file in the host path doesn't make sense to me, but I'm going to go out on a limb and assume that you know when you're doing since I certainly don't.

Awesome, thanks, I'll give that a shot when I'm back in front of my PC.

Hey @ich777 questions for you continuing from a few pages back (and again, thanks for all your work on this) I did a rebuild on my *arr setup. Contains ich777/openvpn-client ich777/lidarr ich777/sonarr ich777/radarr lscr.io/linuxserver/qbittorrent lscr.io/linuxserver/prowlarr All these guys are routing through the OVPN client. All your dockers are set to use the connected containers setup. The problems I'm still having probably come down to... The qbittorrent and prowlarr aren't yours so the connected containers setup isn't part of their build. Have you got a workaround for that? Or intend to release your own versions of qb and prowlarr? The only solution I've found is to reboot them. And since they're both single points of failure in all this, well, having them go and not get bounced automatically kind of kills the value on the rest of the containers auto-restarting. What do yo think?

I've started having bunches of errors again, so I went ahead and just added this to Sonarr and will get the rest cut over eventually. I'll let you know what I see.

...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?