On 4/12/2024 at 1:11 AM, ich777 said:

Please create a variable in the template:

Key: CONNECTED_CONTAINERS

Value: 27286

(This will enable the Connected Containers service)

 

For my containers it's pretty simply, also create a variable in the templates:

Key: CONNECTED_CONTAINERS

Value: 127.0.0.1:27286

 

For these containers you have to place one script on your server, let's say to /mnt/user/appdata/scripts/connected-containers-alpine.sh (make sure the script is executable on the host) and then mount it to the container like:

Container Path: /etc/cont-init.d/91-connected-containers

Host Path: /mnt/user/appdata/scripts/connected-containers-alpine.sh

Access Mode: Read Only

 

 

With that all containers should restart with OpenVPN-Client when you restart the OpenVPN-Client container.

 

Please make sure that all containers have:

in them so that the container actually restarts.

 

Of course all of that will only work if you connected them with:

--net=container:OpenVPN-Client

 

On 4/12/2024 at 1:11 AM, ich777 said:

Please create a variable in the template:

Key: CONNECTED_CONTAINERS

Value: 27286

(This will enable the Connected Containers service)

 

For my containers it's pretty simply, also create a variable in the templates:

Key: CONNECTED_CONTAINERS

Value: 127.0.0.1:27286

 

For these containers you have to place one script on your server, let's say to /mnt/user/appdata/scripts/connected-containers-alpine.sh (make sure the script is executable on the host) and then mount it to the container like:

Container Path: /etc/cont-init.d/91-connected-containers

Host Path: /mnt/user/appdata/scripts/connected-containers-alpine.sh

Access Mode: Read Only

 

 

With that all containers should restart with OpenVPN-Client when you restart the OpenVPN-Client container.

 

Please make sure that all containers have:

in them so that the container actually restarts.

 

Of course all of that will only work if you connected them with:

--net=container:OpenVPN-Client

 

Any chance you let me know what I need to create in my containers to get this feature to work?

binhex/arch-prowlarr

binhex/arch-radarr

binhex/arch-sonarr

ghcr.io/binhex/arch-deluge

flaresolverr/flaresolverr

On 11/29/2025 at 11:05 PM, classma said:

Why is that?

I removed a few of your screenshots since they provided sensitive information.

On 11/29/2025 at 11:05 PM, classma said:

I don't understand.

The command fails because of SMTP authentication as far as I can tell, why that is, I really don't know.
I tested it with a different provider and everything was working over here, even with sending attachments.

You first have to solve why SMTP authentication fails, this seems to be the main reason why it won't send you any mails.

11 hours ago, Richamc01 said:

Any chance you let me know what I need to create in my containers to get this feature to work?

I have a start script that works in Linuxserver.io containers and possible in the containers from @binhex but I'm not that familiar with his containers, however @binhex has his own method of doing the connected containers thing to restart all containers, maybe try to switch over to his containers and use his method.

10 hours ago, ich777 said:

I removed a few of your screenshots since they provided sensitive information.

The command fails because of SMTP authentication as far as I can tell, why that is, I really don't know.
I tested it with a different provider and everything was working over here, even with sending attachments.

You first have to solve why SMTP authentication fails, this seems to be the main reason why it won't send you any mails.

Hello,

Thank you for deleting the screenshot.

I thought I had been careful with the data.

It's strange about the SMTP authentication. I created a password with GMX. I entered it into the email program on my iPhone and it works perfectly. I can send and receive emails.

So why doesn't it work with LuckyBackup, or is it accessing other programs, or how can I find out?

How does it send?

Do I need to do any updates?

So LuckyBackup does backup jobs. I created a test folder and it was backed up.

But wait, the email isn't coming.

Would it help if I completely uninstalled LuckyBackup and reinstalled it?

Sorry for all the questions.

I already know quite a bit, but now I've reached the limits of my knowledge and need help.

Thanks for that.

18 hours ago, classma said:

It's strange about the SMTP authentication. I created a password with GMX. I entered it into the email program on my iPhone and it works perfectly. I can send and receive emails.

Yeah, but it doesn't as you can see in your screenshot.

18 hours ago, classma said:

So why doesn't it work with LuckyBackup, or is it accessing other programs, or how can I find out?

This has nothing to do with luckyBackup, the application sendemail is used to send the Mail, you have to first solve the authentication issue. Maybe there is somewhere a setting that you can enable to make that work. I don't have a GMX account (and TBH, I don't want one) so I can't test that.

18 hours ago, classma said:

How does it send?

Through sendemail, however as said, with my provider (a local one over here) it works just fine.

18 hours ago, classma said:

Do I need to do any updates?

Nope, I think you have to contact GMX support or research further how they are doing authentication or why it's not working with GMX.

18 hours ago, classma said:

Would it help if I completely uninstalled LuckyBackup and reinstalled it?

No, since you see that the Mail doesn't go through when using the command line, that's the whole issue, if you get it to send the Mail then nothing should prevent luckyBackup since it, as mentioned above, uses sendemail for sending the Mails.

Hi, Im not sure if this has been asked before and I've missed it.

Im currently having an issue with rustdeskserver-aio, everytime the container restarts its generating a new key. Is there any way to hardcover the key or to prevent this from happening in the future?

Thanks for any assitance!!

1 hour ago, Basenji said:

everytime the container restarts its generating a new key. Is there any way to hardcover the key or to prevent this from happening in the future?

Please see this post (different container but probably the same issue) :

Please see this post (different container but probably the same issue) :

On 12/6/2025 at 3:33 PM, ich777 said:

I checked and I've got it set correctly in the /mnt/user/appdata/rustdeskserver-aio folder. It still refreshes the key file ever time its reloaded.

Uploading Attachment...

Edited December 8, 2025Dec 8 by Basenji

On 5/25/2022 at 11:10 PM, ich777 said:

Open up the container console and type in this:

su $USERmkdir -p ${DATA_DIR}/.kde/share/config/kdeglobals
echo "[Locale]
Charset=iso8859-1
Country=GB
DateFormatShort=%d/%m/%Y
Language=en_GB
MonetaryThousandsSeparator=$0.$0
ThousandsSeparator=$0.$0" > ${DATA_DIR}/.kde/share/config/kdeglobals

 

Then close the console window and restart the container.

 

Hope that helps.

I am aware this is a hundred years old, but it doesn't seem to work anymore.
Is there any new way? I heard it works in binhex-krusader, but that one misses a bit too much for me :o

9 hours ago, Basenji said:

I checked and I've got it set correctly in the /mnt/user/appdata/rustdeskserver-aio folder. It still refreshes the key file ever time its reloaded.

What do you mean with reloaded?

If the path exists and the container is able to write to this path the key won't be refreshed, if it's refreshed there is something not correctly configured in terms of the path I assume.

I really can't tell since it's working on my server and I assume for many others here too.

The key is physically written into the main directory from the container and displayed on every start from the container in the logs, if the keyfile exists it won't be overwritten.

56 minutes ago, CameraRick said:

I am aware this is a hundred years old, but it doesn't seem to work anymore.

That should work just fine IIRC.

5 hours ago, ich777 said:

That should work just fine IIRC.

I'm afraid not :( I went into the console of the docker and pasted the box (I changed country code to DE and language to de_DE, but what gives). It accepted this instantly, I restarted the Docker.
Thing is, I can't even find the file, I have no ~/.kde folder it seems. I can see .config; shall kdeglobals go directly inside of that?

12 hours ago, CameraRick said:

Thing is, I can't even find the file, I have no ~/.kde folder it seems. I can see .config; shall kdeglobals go directly inside of that?

Yeah, the lines from my previous post, change the user, then creates the folder and creates the file if executed correctly.

However what is the exact issue?

I'm not familiar with any issues in German.

On 12/2/2025 at 2:11 PM, ich777 said:

Yeah, but it doesn't as you can see in your screenshot.

This has nothing to do with luckyBackup, the application sendemail is used to send the Mail, you have to first solve the authentication issue. Maybe there is somewhere a setting that you can enable to make that work. I don't have a GMX account (and TBH, I don't want one) so I can't test that.

Through sendemail, however as said, with my provider (a local one over here) it works just fine.

Nope, I think you have to contact GMX support or research further how they are doing authentication or why it's not working with GMX.

No, since you see that the Mail doesn't go through when using the command line, that's the whole issue, if you get it to send the Mail then nothing should prevent luckyBackup since it, as mentioned above, uses sendemail for sending the Mails.

Hello,

I was able to solve it.

It's very simple!

Deleted Docker LuckyBackup!

Reinstalled it...

Re-entered the paths, including email settings with app password.

And boom, it's working again!

Many thanks to the helpful people here, you guys are doing a great job!!

19 minutes ago, classma said:

Deleted Docker LuckyBackup!

Reinstalled it...

Re-entered the paths, including email settings with app password.

And boom, it's working again!

Really strange... However if it's working then I'm fine with it. :)

6 hours ago, ich777 said:

Yeah, the lines from my previous post, change the user, then creates the folder and creates the file if executed correctly.

However what is the exact issue?

I'm not familiar with any issues in German.

I just changed to german because that is my language, I just adjusted this in case it "overrides" the date-format. Basically, the only issue I have is the date format, I'd love to have it in a non-US way, not too concerned if YY comes first or last :)

I am not sure how to change the user - I just used the commands you posted some years back, was that wrong? :o

5 minutes ago, CameraRick said:

I'd love to have it in a non-US way, not too concerned if YY comes first or last

Never bothered me but I haven't looked into that yet if that's even possible to change.

IIRC someone already asked because he found no solution to that.

Yeah, I asked because Krusader also shows the irrational US-format dates. No solution yet, but IIRC the other Krusader containers manage to use local formats.

On 12/8/2025 at 7:56 AM, ich777 said:

What do you mean with reloaded?

If the path exists and the container is able to write to this path the key won't be refreshed, if it's refreshed there is something not correctly configured in terms of the path I assume.

I really can't tell since it's working on my server and I assume for many others here too.

The key is physically written into the main directory from the container and displayed on every start from the container in the logs, if the keyfile exists it won't be overwritten.

Sorry, by reloaded I mean when he conainer starts it replaces the key file with a new one and I end up needing to re-enter the new key in my devices. I'll try deleting it and re-installing it later today and see if that fixes my issue but I dont use a cache on my system and its writing to the default appdata folder directory that all my other containers write to without issue.

Hello, I was wondering if I could get some help setting up the Stun-Turn-Server for use with Nextcloud Talk.

My Nextcloud instance is the Nextcloud-AIO-mastercontainer from SpaceInvaderOne, proxied with Nginx Proxy Manager and through a CloudFlare ZeroTrust tunnel. The AIO Stun/Turn server won't work through cloudflare, so I tried setting up the Stun-Turn-Server container to use instead. My docker run looks like this. The network type is my custom docker network with a fixed container IP (I also tried host mode, but it didn't work because the nextcloud AIO Talk container wouldn't start anymore.) For realm, I tried it as "turn:nxtcld.my-domain", as well as "nxtcld.my-domain.org".

My NextCloud AIO admin interface looks as follows. I've tried turn: only, turns: only, and turn: and turns: . The secret matches what's in my logs and the appdata folder.

When I run the webrtc Trickle ICE test for all IceTransport values, I don't get any relay results. When I test manually by calling two users on nextcloud talk outside of my home network, the Talk logs show "ICE failed for component 1 in stream 1..." and the calls just do a reconnecting loop. My network setup is an AT&T Fiber Gateway (BGW320-500) in DHCP mode with my Unraid machine connected to it directly. Ports 3478 and 5349 are open to my Unraid machine tcp/udp. I've checked with a port checker on another PC on the LAN and the port is open. I don't have the stun-turn-server proxied at all. Am I missing something simple? I shouldn't need to change anything in CloudFlare regarding my nextcloud instance, should I? Since the Turn server is running separately externally? Thank you

38 minutes ago, Friarsgate_Customs said:

Hello, I was wondering if I could get some help setting up the Stun-Turn-Server for use with Nextcloud Talk.

Please do keep in mind that a STUN-TURN Server needs to have direct access to the internet without any NAT and usually you don't have it on your network because otherwise it will give you the wrong IP addresses.

38 minutes ago, Friarsgate_Customs said:

The AIO Stun/Turn server won't work through cloudflare

Jup, STUN-TURN needs to be directly reachable from the Internet.

39 minutes ago, Friarsgate_Customs said:

The network type is my custom docker network with a fixed container IP (I also tried host mode

It has to run in host or in br0/eth0 mode otherwise it won't work properly.

2 hours ago, ich777 said:

Please do keep in mind that a STUN-TURN Server needs to have direct access to the internet without any NAT and usually you don't have it on your network because otherwise it will give you the wrong IP addresses.

Jup, STUN-TURN needs to be directly reachable from the Internet.

It has to run in host or in br0/eth0 mode otherwise it won't work properly.

I'm new to home networking so I'm sorry if I don't understand something. I can't bypass my NAT currently because my ISP is quite restrictive. However, I see under extra parameters where you linked the coturn github wiki that there is this section:

"-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X <ip>" then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X <public-ip/private-ip>", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used."

So I got my public IP via the unraid console with curl ipinfo.io/ip (Let's call it 99.99.999.99) and my container IP is 192.168.1.123. I then put "-X 99.99.999.99/192.168.1.123" in extra param. However, the logs on startup say "No external IP set". I also tried "-X 99.99.999.99" and it also says no external IP set. Shouldn't this work at least until my ISP updates my public IP? Sorry if I don't understand fully.

Here's my updated docker run if it helps:

I also tried making a DNS record on my cloudflare domain of coturn.my-domain. org and set it to my public ipv4 address with DNS only (no proxy). then I updated the realm field to this domain and updated my container. With this new domain. the test button on nextcloud administration panel returns a green checkmark. The trickle ICE test still won't return my public IP or any relayProtocols, and my nextcloud calls still reconnect endlessly. I think this is close to working

Edited December 9, 2025Dec 9 by Friarsgate_Customs

20 hours ago, ich777 said:

Never bothered me but I haven't looked into that yet if that's even possible to change.

IIRC someone already asked because he found no solution to that.

19 hours ago, Rick Gillyon said:

Yeah, I asked because Krusader also shows the irrational US-format dates. No solution yet, but IIRC the other Krusader containers manage to use local formats.

Okay, shame, because in Binhex (the only other I saw) I also didn't get it to work. Binhex lacks in other regards as well (like no gedit, or a simple image viewer), which is why this container is so great :( oh well, then I will just live with it.

Thanks guys!

18 hours ago, Friarsgate_Customs said:

I can't bypass my NAT currently because my ISP is quite restrictive.

Then hosting a STUN/TURN Server is most of the times impossible.

18 hours ago, Friarsgate_Customs said:

In that situation, if a -X is used in form "-X <ip>" then that ip will be reported as relay IP address of all allocations

But we are not talking about a Webserver, STUN/TURN, is it's own application and won't make use of that.

Again, a STUN/TURN Server should be deployed on a VPS outside your network, TBH most of the times it's enough to use any of the public available STUN/TURN servers since they only provide the IP where to connect.

You can take a look here.

A STUN/TURN Server is not a simple Webserver.

3 hours ago, CameraRick said:

Okay, shame, because in Binhex (the only other I saw) I also didn't get it to work. Binhex lacks in other regards as well (like no gedit, or a simple image viewer), which is why this container is so great :( oh well, then I will just live with it.

Sorry about that but currently my time is very limited and I barely have time to maintain everything, but as always I try my best. :)

If you find a solution please post it here so that others can also benefit from it.