mattie112

I don't use CF myself. But in general: The .well-known directory MUST be reachable through unsecured HTTP on port 80. As letsencrypt must be able to verify the challenge even before the encryption has been set-up.

A HTTP 522 error is a CloudFlare connection timeout it seems: https://support.cloudflare.com/hc/en-us/articles/115003011431-Troubleshooting-Cloudflare-5XX-errors#522error https://www.ionos.com/digitalguide/hosting/technical-matters/error-522-explanation-and-solutions/ I don't use CF myself buy I would double-check the settings there.

Try to manually call certbot, see:

You can still have multiple servers, however as you just have 1 port 80 available (externally) you can only have 1 NPM running (on that port). Either: run other NPM on other port or Have just 1 NPM and have that also proxy the traffic for the other servers

Or (if you just have 2 Unraid servers) run NPM on 1 and add your hosts for unraid #2 in there so: service hosted on unraid 1 example.com -> localhost:1234 service hosted on unraid 2 otherexample.com -> ip.of.other.unraid:2345

So it seems like certbot is already running (or stuck) and cannot start a 2nd time. I would try to restart your container and see what happens then.

It seems to expect a file but that file does not exist. Did you manually remove something? Possible you can create just an empty file perhaps it will start then. Or remove al config for the domain with ID "15" so it does not try to load it.

Ah then I can't help you. I do it all myself including running my own nameservers so no CF or DNS providers for me

I don't use CF. Perhaps it caches the url it uses to verify? Afaik the '.well-known' directory. Perhaps try it without CF first?

So, does your domain point to the IP NPM is running on? Both 443 and 80?

I recently upgraded to 6.10.3 and it seems that since that time my NFS share is no longer working properly) (access denied). And using it via fstab: 192.168.100.200:/mnt/user/rsync /mnt/rsnapshot nfs defaults 0 0 This always worked and nothing was changed regarding this so I guess it has something to do with the 6.10 upgrade. Anyone else got issues or perhaps I missed something that was changed? I do have read rights but no write rights. The `sec=sys,rw` was always there. tower-diagnostics-20220712-1441.zip

Yes but no The `logs` directory is a symlink to `/log`. So really just a "shortcut" to an other directory. This is a Linux thingy and it looks like it is duplicated but I can guarantee you that is is not. If you go to your Unraid terminal to that directory and do `ls -alh` you can see that it is simply liked and not a 'real' directory. root@Tower:/mnt/user/appdata/NginxProxyManager# ls -alh drwxrwxrwx 1 nobody users 3.7K Jul 3 16:10 log/ lrwxrwxrwx 1 root root 3 Jul 4 13:17 logs -> log/ edit: Oh and to why: I don't know, perhaps it is kept for backwards compatibility or something?

Just to confirm: I just updated my 6.9 to 6.10 a few days ago. No problems at all. Even tried rebooting a couple of times -> works fine.

This is DHCP. I prefer to use that (with a reservation ofc). Just in case I need to change anything than I have no trouble accessing my server. (and this would be a workaround and not a fix :p)

Had this issue again (Unraid 6.10.3), my system kinda "crashed" (I think cache got filled 100% and docker did not like that). Rebooted -> had this issue, stopped docker & started it -> it works again. So even in the latest release this is still present.

Yeah, I can understand that, however the downside is that you then have an usecase that is not used a lot and that it can be hard to find a good tutorial. What you can do (as you are just experimenting now): first set it to port 80 so letsencrypt can just give you a certificate. And then change it back to an other port. Your certificate will just work but never renew. Might be a bit easier to set up and give you enough time to try it out.

No you should not do this manually (as it changes every time you'll need certificates). So: you should input your google credentials and then NPM (or really certbot in this case) will do an API call to update the TXT record and then letsencrypt can verify that. (also see: https://certbot-dns-google.readthedocs.io/en/stable/) Is there any reason why you want your webserver on non-80/443

What exactly are you trying to do? Your NPM (= proxy server) is listening on 80/443, you can add a host for anything within that. domainA.com -> 1.2.3.4:80 domainB.com -> 1.2.3.4:81 something.domainC.com -> 1.2.3.5:443 If you have an internal 'service' listening on both 80/443 choose one. Usually internally your services are terminated in 80 (as you don't have a ssl cert for them) but 443 should work just fine (as long as the cert is valid)

You should be able to do that through the UI:

I just have a fork of: https://github.com/jlesage/docker-nginx-proxy-manager into https://github.com/Mattie112/docker-nginx-proxy-manager that only changes the ports That project was not updated since 23 Feb. Are you looking for something specific? Perhaps I can get that part.

Externally you only have 1 IP so you can only 'open' 80/443 once. You don't really 'open' a port btw, you 'forward' it to a different IP. So for example: 1.1.1.1 -> your external IP 192.1.1.1 -> unraid 192.1.1.2 -> VM 1.1.1.1:80 -> 192.1.1.1:8080 1.1.1.1:443 -> 192.1.1.1:443 If you have this you can NOT have 1.1.1.1:80 -> 192.1.1.2:8080 But you CAN do 1.1.1.1:81 -> 192.1.2.8080 But why do you want to do that? The whole idea of NPM (or a reverse proxy) is that you have a single entry point. And that within that proxy you can send 'domainA.com' to server A port B and 'domainB.com' to server C port D

I don't use cloudflare myself but: Can you perhaps try the most simple case? For example with https://hub.docker.com/r/hashicorp/http-echo/ and just let it run on 80. Just to first make sure that cloudflare -> server works.

Nextcloud is on a different IP so that should work. Did you set the port mapping correctly? So 80 on your 'host' and 8080 in the NginxProxyManager for example. Can you show a screenshot of your ports? (If you need NPM to listen on 80/443 for IPv6 for example and you don't use IPv6NAT you can use my fork: https://github.com/Mattie112/docker-nginx-proxy-manager / https://hub.docker.com/repository/docker/mattie112/docker-nginx-proxy-manager)

You can switch over by changing this: Let me know how it works

Yeah or just change the repo url (assuming the env vars are the same)