mattie112

I'm not sure what exactly is in this log (I don't seem to have this file so I guess it's only created when it fails). I would recommend to check it perhaps it is already clear then why it is failing?

Can you check the logfile mentioned: /var/log/letsencrypt/letsencrypt.log (this file exists in your docker container so docker exec -it NginxProxyManager sh and then cat /var/log/letsencrypt/letsencrypt.log) Also: Is this the only domain that fails or does everything fail?

Hm that is strange (perhaps restart your container?) But yes you should be able to do it from the CLI. Again SSH to your unraid and do: docker exec -it NginxProxyManager sh (If your container has a different name use that you can see it on the web UI from Unraid) In your container do: certbot renew or certbot renew --force-renewal This will renew everything or use the --cert-name flag to only do the ones you need edit: I would restart my container after doing this.

The 8181 port should be the webinterface, but perhaps you use an other port? You can also go to the docker tab in unraid and then click on NPM end then choose "WebUI". I think the container uses certbot internally but I'm not 100% sure so if the UI works I would suggest to try that first.

If you go to yourip:8181/nginx/certificates you can 'renew' the certificate. This should generate a new one and store it to your disk. I'm not really sure if you can see what site "9" is so I guess the first one on that page? Or perhaps an error is already displayed there? edit: You can see it in the config files /mnt/user/appdata/NginxProxyManager/nginx/proxy_host and then look into (`cat`) the 9.conf file

You could try logging in with ssh as root and then access the file. Or from the webinterface go to SSL Certificates and then renew it to see if that fixes the problem.

Again: what exactly is the problem? "Dies" is not something we can help you with. What does work and what not? What HTTP status codes are displayed. What do the logs say? Can you confirm your SSL settings? It seems it is trying to load a certificate that either does not exist on the filesystem or there is no permission. You can also check the filesystem yourself to make sure this file exists.

And what exactly "dies" ?

If you have a single PEM file with both the key and the certificate then you need to split them. Simply open the PEM file in notepad and create 2 separate files. One with everything from BEGIN CERTIFICATE and one from BEGIN PRIVATE KEY (or perhaps it is listed as public key instead of certificate)

Did you remove the 'domain names' for the purpose of the screenshot? I don't think it works without a domain name.

Can you show your config? This is not an error, only a warning (that it will give an error in the next version)

Perhaps show your config? And in case of Gee1 the exact error. Without info there is no way someone can help you...

Yes you can but then you have to do that every ~3 months and that does not seem like a solution to me. docker exec -it NginxProxyManager sh and then certbot renew But a quick google shows that in CloudFlare you should be able to exclude an url (yoursite.com/.well-known/*) from being cached and then it should work perfectly.

Fixing the issue you are having I would suggest checking cloudflare if you can exclude a directory from being cached so that the letsencrypt verification works.

Just keep in mind that if your certificate needs to be renewed it will most likely fail due to the same issue!

Nice one, I can understand that that is really confusing (imo when checking an email adres casing should not matter, so strlower in the DB and strlower the user input and then check )

Hmmm that is really strange.... Perhaps just for funs: stop your container. Rename the appdata/npm folder. Start the container (you should now have a fresh instance. Can you login now? Then change the user/password to what it should be. Can you login now? Then try the reset password option. If everything works I have no idea. If that doesn't work either there is something strange with your browser (adding a space or something) or there is something horrible broken. And just to confirm: are you 100% sure you try to login into the correct NPM instance? So is there only 1 container running?

It seems to be yeah: #!/bin/sh usage() { echo "usage: $(basename "$0") USER_EMAIL [PASSWORD] Reset password of a Nginx Proxy Manager user. Arguments: USER_EMAIL Email address of the user to reset the password. PASSWORD Optional new password of the user. If not set, password is set to 'changeme'. " exit 1 }

You can try something like this: docker exec -it NginxProxyManager sh # you are now in the container mysql # you are now connected to the internal mysql shell select * from user; select * from user_permission; select * from auth; You can check IF there is an user (that is not disabled/deleted) and if you are using the correct username. If not you can update the password or insert a new user. I am guessing the standard mysql/mariadb encryption is used to in order to change the password: update user set secred=PASSWORD('yourpasshere') where id = <id_from_your_user>; But perhaps @Djoss can confirm if this is the correct hasing/method. (you could also create a new instance of NPM and check the tables for the default user and then copy that over to your existing instance)

Do you want to try and fix your current installation or just start over? For the last one you can remove the container, then remove /mnt/user/AppData/ngnx-proxy-manager and then reacreate it for a clean start.

Well depending on his setup it could be CORS or the fact that the site is configured for a domain and not an IP that is preventing the images to load. But yeah definitely check the network tab. Also if you can provide us with the url that might speed things up

I'm sorry I was asking about the domainname you where using just so we can check if it resolves correctly And I am talking about the hosts file on your computer. That file basically "overrides" the DNS (your PC first checks that file then searches the internet). So just in case there is something misconfigured you can try it out that way.

Can you give the DNS you are using? Just to confirm it resolves correctly. I would suggest to try to do the following: In your host file add: yourdomain -> internal.ip.from.unraid and after you have tested that change it to yourdomain -> your.external.ip (what it is at that moment not the duckdns stuff) And also: nonexistingdomain -> internal.ip.from.unraid That should lead to a connection to NPM but as it cannot find a valid proxy host it should display a 404 (or 403) so you can at least confirm it reaches your NPM.

Can you ping the IP from within unraid? (Or an other docker container?)

Can you explain a bit more how it is configured? You have a (sub)domain that has an A record to what? Cloudflare? And then Cloudflare is linked to your NPM? Can you try to disable cloudflare just to confirm your NPM works as expected? (most easy way would probably to edit your own /etc/hosts || C:\Windows\system32\drivers\etc\hosts file)