strike

Remove "ncp-disable" from your .ovpn file and retart the container.

This seems to be your issue: 2023-02-13 08:56:48 VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: C=US, ST=VPN, L=VPN, O=VPN, OU=VPN, CN=VPN, name=VPN, emailAddress=VPN, serial=1 2023-02-13 08:56:48 OpenSSL: error:0A000086:SSL routines::certificate verify failed 2023-02-13 08:56:48,838 DEBG 'start-script' stdout output: 2023-02-13 08:56:48 TLS_ERROR: BIO read tls_read_plaintext error 2023-02-13 08:56:48 TLS Error: TLS object -> incoming plaintext read error 2023-02-13 08:56:48 TLS Error: TLS handshake failed It looks like your vpn provider is issuing a week cert, you need to get a updated one from your vpn provider.

You have redacted too much of the log. What is your LAN_Network set to? What is the IP of your unraid server? And what network type do you have set in the docker template?

Try to delete the perms.txt in your appdata and restart the container. Post a new log if you can't get to the webui.

Glad you got it fixed

Do this: https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Remove or comment out "ncp-disable", it was on the list in the link posted earlier.

Can you add this to your faq? I might need it sometime.

That will do it, I guess your old version was still v1 something. Glad you got it fixed.

It should, but I have found out that's not the case,remember having this issue myself loong ago. Also you should stop the container before making any changes, then restart it. I have serveral times changed the core.conf file while the container was running then restarted, and found the changes was not sticking.

But have you commented out the default one? And just to clearify, you're trying to connect with the thin client right? I'm asking because you only mention the webui in your post. The 58846 port is for connecting to the daemon with the thin client. If the auth file is correct and in the right place it should work. There was another user having almost the same issue not long ago, but he had puth the auth file in the wrong place.

You're sure you don't have another line in the auth file that is not commented out? Can you post the content of the auth file?

Not AFAIK, it has been that way since the start. But yes, you're correct it can work, sometimes.. I too had it working for a long time, then I changed network hardware and I couldn't get it to work anymore. Nothing else changed, just the hardware. So now I'm using the thin client instead. I suppose it can be firewall releated, but I couldn't find my firewall was blocking either.

Download a different ovpn file and replace the one you have in your appdata.

That's your issue. You have 2 options when using custom br0. 1. Don't specify a IP adress 2. Forget about using the webui and use the thin client instead Or change your network type to bridge.

What network type do you use?

If you don't want the prompt at all you can use the thin client instead of the webui and set it to automatically connect. Doesn't solve the webui issue, but it's an alternative.

Sorry if I was offending you, that was not my intention. But it's just facts. Same as I'm not as smart in your proffesion whatever that is. Say I want to bulid a house and I'm not a carpernter. The carpenter gives me advice on how a house should be built, but I choose to ignore the most important parts. Wouldn't you say that's pretty dumb? The carpenter would at least think that. Peolple are so easily offended these days.

That might be. Have you ever tested your backups of the containers you have running during the backup when using the previous version? Specifically containers with databases which are most prone to corruption.

Average users like to tinker as well, you'd be surprised how much they tinker. Too much for their own good sometimes

Fair enough. I don't expect the average user to know, that's for sure. I've worked in IT and anybody who has knows that the average user is, to put it nicely, not that smart. And as a developer you have to work around that and make certain choices for them to ensure that whatever you're developing is working as intended, even if sometimes the user makes the wrong choice. And when we have users demanding a feature which will essentially break what the plugin is supposed to do and expect all other users to not only be okey with that, but they expect the average user to make the same choices as them self even if they actually have no idea how things work in the first place. Like I said, I've worked in IT and therefore I don't expect the average user to know as much as I do, that's why they called IT... So my approach is to always think about the average users and what they might and might not do and think. Thus my question in the last post. As the average user probably won't know, I don't expect them to know anyway. But yeah idk. I just don't like the idea of breaking a plugin with this "feature" which ignores important errors. I won't be using this feature anyway, but I think about all the users who will come here complain about why their backup doesn't work. But maybe a warning will be enough to stop most of them, idk. Many of us here will help answer them (too bad we can't help them since their backup is screwed up) if they come I'm not worrying about that, but it's just.. It could all be avoided in the first place if they could just do it the right way..

And you just assume that every user knows this? How do a user determine if it's safe or not? Or do you expect the developer to inform the user which containers are not safe to have running during backup? Not to be rude or anything, but you obviously don't work in IT.

For you maybe, but what about users that have more important containers with databases then pihole? The worst part is that they will come here and complain "why their backups are not usable, isn't that what this plugin is for?" There should at least be a big red waring message that having containers running during backup might cause some files to be incomplete or have corrupt files. That way they can't say they haven't been warned.

Yeah, that's what I've been trying to say too. But I guess some people need to learn the hard way. But media apps like plex,and the *arrs is not that critical to loose either way, they just have to pull down the metadata and build a new database. But sucks to have a backup you cant use. I guess they will learn that in time

In many cases yes, but what about those other cases and the important files which can change? I think it's a bad idea. I don't mean to be condescending but most users are not smart. How do you suggest the developer determine which files is ok to be changed and which are not? As I said earlier if you don't care about files being changed why do the backup at all? Isn't that what the backup is for, an exact copy of your files? If you really want it that way there is no one stopping you from just runnning the rsync command against your appdata yourself, just create a user script. You don't really need this plugin if all you want is to copy the filles and nothing else. You clearly don't care about the files and you clearly don't want the containers to stop, so what do you need this plugin for? Those smart users you're where talking about can just figure out which files they don't care about and exclude them if they really want to. That will stop the errors.