basically the application is broken.

[jucajuca]

I just wasted more than one hour trying to update my proxies.

I kept getting the same error again and again and again. Could not delete file. This is the absolutely basic functionality that should be offered by the nginx proxy manager right? I would expect a proxy manager to be able to edit the proxies.

But it basically can't do this basic thing. This added to the even worse handling of the SSL certificates led me to the conclusion that I need a better solution.

So to anyone reading this: look for other solutions: caddy, traefik, whatever. Do not waste time here.

And to the developers, please do the world a favor and archive this project.

[1/24/2024] [5:07:50 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/14.conf

[1/24/2024] [5:07:50 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -t -g "error_log off;"

[1/24/2024] [5:07:50 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/14.conf

[1/24/2024] [5:07:50 PM] [Nginx    ] › ⬤  debug     Could not delete file: {

  "errno": -2,

  "code": "ENOENT",

  "syscall": "unlink",

  "path": "/data/nginx/proxy_host/14.conf"

}

[1/24/2024] [5:07:50 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/14.conf.err

[1/24/2024] [5:07:50 PM] [Nginx    ] › ⬤  debug     Could not delete file: {

  "errno": -2,

  "code": "ENOENT",

  "syscall": "unlink",

  "path": "/data/nginx/proxy_host/14.conf.err"

}

[1/24/2024] [5:07:50 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -t -g "error_log off;"

[1/24/2024] [5:07:51 PM] [Nginx    ] › ℹ  info      Reloading Nginx

[1/24/2024] [5:07:51 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -s reload

[1/24/2024] [5:07:57 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -t -g "error_log off;"

[1/24/2024] [5:07:57 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/14.conf

[1/24/2024] [5:07:57 PM] [Nginx    ] › ⬤  debug     Could not delete file: {

  "errno": -2,

  "code": "ENOENT",

  "syscall": "unlink",

  "path": "/data/nginx/proxy_host/14.conf"

}

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes : image: jc21/nginx-proxy-manager:2.11.1
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes. There are open and it seems that the team does not care.

Describe the bug

try to edit a proxy. It is impossible. Check the logs, see the result above.

Nginx Proxy Manager Version

image: jc21/nginx-proxy-manager:2.11.1

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

Maybe it should work?

Screenshots

Operating System

Additional context

[samtoxie]

Same experience, downgraded to 2.9.22. Seems to work better but I'm considering migrating away as NPM requires more maintenance than plain NGINX :/

[jorgepsmatos]

I wish I could say I only wasted one hour on this. Even 2.9.22 I have the same error. Maybe because I'm using the ARM version

[blackoutland]

I can't even add new hosts now - it started initially when I mistakenly request a certificate before changing it in DNS thus leading to an error. From then on whatever I do even when using completely different domains and trying to add them it all fails with "Internal error" and the message shown above.

[pathia]

2.10.4 doesn't seem to have this issue. Perhaps try reverting to that version in the meantime.

[blackoutland]

I looked at the code - the error is logged (I would simply add a missing "if" to check if the file to be deleted actually exists) but this does not cause any other issue - it's not aborting because of that - it just logs the error.

The problem I faced is that this tool is extremely optimistic as such that it does not actually care about any errors returned by letsencrypt and doesn't give any more details on this. For me the real reason was this: "Some challenges have failed." which came after this error.
It also logged "Saving debug log to /tmp/letsencrypt-log/letsencrypt.log" - when looking at this log I found out that for whatever reason Let's Encrypt used the old server IP and not the new one even though the NS was not changed, I changed the IP in both NS and when querying them with "dig" the correct new IP was returned - in WHOIS those NS were there for years.
But that's another issue.

So for me the main problem is that this tool does this:

• always creates the host entry
• when Let's Encrypt fails it only shows "Internal error" which is actually wrong, because it's an external error caused by Let#s Encrypt - this tool has to parse the Let's Encrypt result and show the corresponding message to the user, but it appears it was never implemented - that's what I call extremely optimistic
• when you try too often Let's Encrypt itself locks you out for one hour for the given host - something you'll also only see in the log

@jucajuca Do you also get the error "Some challenges have failed" after this error? If you do you should look at the letsencrypt.log

[schneekluth]

i feel your pain. Lately I did some research for a replacement and I think this one looks promising. I just leave the link in case it might be an option for you guys.

Webseite: https://zoraxy.arozos.com/

Github: https://github.com/tobychui/zoraxy

[coeki]

@blackoutland

I somewhat agree with you conclusions, I got side tracked by the error too, although at least something popped up.
The logs for almost everything are empty., docker compose logs gave me small hints.
In my case I made an error myself in configuration, but it let me request certs, set's up the host. But looking in the cert itself, dns failed. There's nothing in the logs anywhere, and you don't get a warning. My bad, I set the docker NPM container port to 8080 on the host, that's a nono ;).
Anyway it works now, but yeah logging and letting the user know, can obviously be better.

[manuelmanharta1]

Having the same issue but my letsencrypt renewal went through smoothly. The error is as non informative as it can get, because it tries to delete a file which is not even existing in my container (it is /data/nginx/proxy_host/3.conf in my case).

Altough I do like the UI, I am as well thinking to switch back to either a plain NGINX or to jwilder-nginx-proxy as I am running everything dockerized.

[manuelmanharta1]

Update: I could solve it through deleting the problematic entry and recreating it. From my (users) point of view nothing changed but it seems that something went corrupt under the hood.

Still it is very sad because when debugging is almost impossible, you can just hope to never encounter bugs.

[saman-taghavi]

though it has worked well for me but i too face the same problem hate to migrate though

[Reasonable-Human]

Hello, I have the same error as the original post, but it seems to only affect hosts that have custom location in use. After deleting the custom locations the proxy host works fine again.

[drzwi-cal]

I cannot work without custom locations. For me it is key feature. I need to proxy /uploads folder to another service. Is there any workaround for this to work, but without custom locations?

[pathia]

I cannot work without custom locations. For me it is key feature. I need to proxy /uploads folder to another service. Is there any workaround for this to work, but without custom locations?
put uploads on a different subdomain?
Or otherwise plan nginx (https://hub.docker.com/_/nginx ) and create your own nginx proxy manager. You can re-use some of the configs inside the nginx-proxymanager container. There's no magic involved here. It's just a nice graphical ui over a vanilla nginx.

[bkilinc]

As a workaround, I downgraded to version 2.10.4 with docker-compose. I hope there are no corruptions in the backend data ??