mattie112

That folder is used by certbot. Somewhere in the nginx config it is defined. But the message is clear: a timeout while trying to connect to unsecured http on port 80. It could be as simple as restarting your modem. Or try to do an external port scan for example to verify / test.

Good to hear it is resolved Could be cached at letsencrypt (or rate limited?) not sure about that.

Are sure the .well-known folder can be accessed? Through unsecured http over port 80?

Did you try to manually run the command? Can you do a 'ps auxf' to see if it is already running? Or find and delete the lock file I think it uses. You are free to use any certificates with NPM. Just add them as a manual cert.

Try running cert or manually to get more debug info. Currently on my phone look a bit back in the topic posted the instructions a couple times before.

And what if you access your IP directly http(s)://your.external.ip ? What do you see? If you get a not found served by NPM at least that part is working. Or do you think the not found is send to you by nextcloud? Check the nextcloud container for example do you see your connection attempt there? (also: it seems kinda strange that you forward it to https://192.168.0.2:444 usually you forward to a http endpoint because that is where you use NPM for; ssl termination).

Open a shell into your NPM docker container and verify the result of your action (the nginx config file). I don't use this feature but perhaps it is already put into a location block?

I would post this in a more generic forum. While it could be NPM (are you running the latest version?) it might also be something else. I would suggest to leave NPM offline to see if that solves your problem

Sorry, I don't use SWAG so yeah I would ask it there.

Your server B is on the same internal network as server A right? Then you don't need to forward any ports. In your example just add a host in NPM for sonarr.domain -> ip.of.server.B:8989

I don't really see why you want them to be in the same docker network/interface. If you just want to be able to reverse proxy them then just expose the ports. For example Server A with NPM IP 1.1.1.1 Sonarrr is on server B with IP 2.2.2.2 (map sonar port to host port 12345) Then just add a host sonarr.domain -> 2.2.2.2:12345 And if you run them on a different IP you can use that IP instead of 2.2.2.2 But: you can't really use the same range as that is (by default) only handled internally. You can go to network settings and set a range (or an IP) to go through a different interface but then your router also needs to know where to forward it to as that range will not be 'known' by your local network. (and yes you can either direct attach or do some IPtables solution but I can't really help you with that) Perhaps it will work by adding a range and setting the gateway IP of your server B but I'm not sure.

What exactly do you want? containers on B to be able to access containers on A (behind the proxy) -> then why not access them through the proxy? NPM on A to be able to forward traffic to containers on B -> then why not expose a port (and/or IP) on B? But with some iptables magic you should be able to "bridge" networks I think but I can't really help you with that config.

Are you sure the port forwarding is correct? A 'start' and 'ends would indicate you are forwarding (allowing) that range to go to your server (or container). I do not see a 443 to 18443 forward for example. You could try NPM on 80/443 (if it has its own IP) to verify this. Or try to access port 18443 remotely then you can be sure.

Is it not listed in the UI? Perhaps manually delete `/etc/letsencrypt/renewal/npm-2.conf`

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