aptalca

No idea why it's doing that. But if it is updating every so often, it should be fine.

Start from the beginning. Forget about the reverse proxy. Forward port 80 on your router to port 80. Check the docker log, make sure cert is retrieved. Then check the landing page

I'll look into adding it

Your server names aren't matching for 80 and 443, bw vs bitwarden

The way you set up your a record and cnames is correct. You just need to make sure that the a record remains up to date. You can use a docker image like ddclient to update it, or some routers can also do it. If you're doing dns validation, look into getting a wildcard cert and then you only need to create one cname for "*" without the quotes and you'll be good. Between the a record and that wildcard cname, your domain and all subdomains will be covered.

Is it using host networking or bridge? Nothing wrong in the docker log

Yeah, it's optional for default config but you specifically turned it on when you included the following two lines in your conf: auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; Either create the .htpasswd or comment those lines out. The error you're getting specifically says that nginx can't find the .htpasswd file

Did you create an .htpasswd file? The command to do so is in the image readme linked in the first post

It's probably the dns cache. You have to turn it off and wait a bit

Turn cloudflare proxy off. Click on the orange cloud and make sure it's gray

No. Nothing on the host ip can connect to macvlan. One user here tried putting openvpn on macvlan as well, in order to be able to connect to other containers on macvlan but he had other issues I believe. Don't recall the details, it was beyond my networking knowledge.

Spent about an hour digging through their scripts and their post install of their package to see what could be missing. Wasted time. Openvpn pulled the 2.7.2 release. We pushed an update to set latest back to 2.6.1. If you updated to 2.7.2 today, update again to go back to 2.6.1 and things should go back to normal.

Openvpn-as devops is a bit of a mess, really. They like to make significant (breaking) changes to their db and data through their package updates, but not during service start. With this docker image, we don't do in place package updates, we replace the package along with the docker image. So the changes within their package updater need to be made manually. That happened about a year ago as well. Essentially, you're seeing a version mismatch between the app and its data and unfortunately it's not something we can easily prevent in the future

There are 3 types, host, bridge, and macvlan. Macvlan is the only one with that restriction.

Check your port forwarding

"as" stands for "access server", and is the gui version by openvpn. You need an openvpn client to connect to an access server. Linuxserver.io doesn't provide a client image. No idea about the other docker images

Nginx is not listening on port 80 by default because mapping port 80 is optional for this image (unless you're doing http validation) The readme states that listening on 80 for http and redirecting to https can be enabled in the default site config

Define not working. Post your config. It works fine here. Read the last few pages here for more info.

No idea about unms built-in letsencrypt so can't help you with https://unms.mybusinessdomain.co.uk. When you use the 6443 port, you are bypassing the letsencrypt container and connecting directly to unifi, so no proper cert, only self signed, hence the warning message. With regards to unifi.blah address, use the proxy conf for it, make sure you only have one active unifi conf, set the server name to that full unifi domain url. Also noticed that you changed your container name to "Unifi". That won't work as nginx won't resolve names with uppercase letters. Make sure your unifi container is named "unifi". Just keep the unifi proxy conf default except for the server name directive.

Fyi, the container now contains its own interface called eth0 inside. In bridge networking, this eth0 network gets bridged to the host's interface.

Exposing guis like sab and radarr is the exact reason for a reverse proxy. As long as a proper auth is used (http auth with fail2ban as implemented in this image) it's perfectly fine.

If you change the set, you'll be able to get a cert because your current restriction is "for the exact set of domains". I recommend starting with one duckdns subdomain as the url and see what happens. You can then expand if you need to

Unfortunately the serviio image has been deprecated. The existing image will remain on docker hub but there will be no further updates or refreshes

It seems when you messed with the permissions, you prevented the container from properly deleting the certs folder and when it regenerated certs, it created a duplicate folder with a 0001 appended to the name. Start over, don't change any permissions. Also a side note, duckdns shouldn't really be the url variable. Url should be yoursubdomain.duckdns.org and subdomains should be any sub-subdomains you would like to use ie. "sonarr" so you can access sonarr.yoursubdomain.duckdns.org If you need to add additional duckdns subdomains (usually needed for servers with different IPs, although I doubt that's the case here since they all need to point to the same letsencrypt instance), put them in the extra domains.

It's the last line in the config file you posted, the line that starts with proxy pass