Wizard fails during installation

[enwikuna]

Describe the bug
The initial setup wizard (“Self Check” screen) in uozi/nginx-ui:latest never finishes and never allows proceeding to the actual UI. It always reports failing checks like “PID path not exist”, “Config directory not exist”, “Sites-available directory not exist”, even though Nginx is actually running in the container, the config directory is mounted correctly, and all required paths and files exist.

Because the wizard never turns green, there is no way to complete installation through the normal flow.

Additionally, /install does not present a normal “create admin user” wizard. Instead, calling / or /install returns {"message":"not found"} until the Self Check is passed — which in this case is impossible.

It looks like the wizard fails to parse live Nginx info even though Nginx is there and working.

To Reproduce

1. Start nginx-ui using the official uozi/nginx-ui:latest image with a bind-mount for /etc/nginx and /etc/nginx-ui, plus published ports 8080→80 and 8443→443.
2. Make sure /etc/nginx (on host we mount /opt/system/nginx-ui/nginx) is populated with a normal Nginx config:
   • nginx.conf with pid /var/run/nginx.pid;
   • conf.d/, sites-available/, sites-enabled/, etc.
3. Browse to http://SERVER_IP:8080 or via SSH tunnel (ssh -L 8080:127.0.0.1:8080 root@SERVER_IP) and let nginx-ui show the installer “Self Check”.
4. The Self Check shows multiple ❌ items:
   • “Config directory not exist”
   • “Sites-available directory not exist”
   • “Failed to read nginx.conf”
   • “PID path not exist”
5. Click “Attempt to fix” on each item. The UI still reports ❌.
6. Click “Recheck”. Still ❌.
7. You cannot advance past this screen.

Meanwhile, inside the running nginx-ui container:

• The config dir and files exist and are readable:

  docker exec -it nginx-ui ls /etc/nginx
  # conf.d  fastcgi_params  mime.types  modules  nginx.conf  scgi_params
  # sites-available  sites-enabled  streams-available  streams-enabled  uwsgi_params

• The PID path exists and contains the actual master PID:

  docker exec -it nginx-ui sh -c 'cat /etc/nginx/nginx.conf | grep pid'
  # pid        /var/run/nginx.pid;
  
  docker exec -it nginx-ui ls -l /run /var/run
  # /var/run -> /run
  # /run/nginx.pid (present, contains PID)

• nginx -V from inside the container clearly shows correct build flags:

  --conf-path=/etc/nginx/nginx.conf
  --pid-path=/run/nginx.pid
  --error-log-path=/var/log/nginx/error.log
  --http-log-path=/var/log/nginx/access.log
  

But nginx-ui logs spam errors like:

ERROR ... internal/nginx/resolve_path.go:91    nginx.GetConfEntryPath len(match) < 1
ERROR ... internal/nginx/resolve_path.go:67    nginx.GetConfPath len(match) < 1
ERROR ... internal/nginx/resolve_path.go:109   pid path not found in nginx -V output
...
PID path not exist

So nginx-ui fails to “see” the exact same paths it just printed from nginx -V. It never marks the PID path as valid, and because of that the wizard refuses to continue. The admin user screen is never reachable.

Expected behavior

• The installer should accept a valid, already-running Nginx config when:
  • /etc/nginx/nginx.conf exists and is readable,
  • /etc/nginx/sites-available and /etc/nginx/sites-enabled exist (they do),
  • the PID file path in nginx.conf exists and contains a PID (/var/run/nginx.pid -> /run/nginx.pid exists).
• Clicking “Attempt to fix” should populate any missing internal settings so that “Recheck” turns green and allows proceeding.
• If Nginx is already running and we’re just attaching nginx-ui to manage it, the wizard should not block forever.

Additionally:
If the project has moved to a “headless install” flow (env vars like NGINX_UI_NODE_SKIP_INSTALLATION, NGINX_UI_PREDEFINED_USER_NAME, etc.), then the wizard should either:

• honour those env vars and skip itself entirely, OR
• surface a login page directly, instead of trapping the user on Self Check.

Right now, the wizard is a dead end for me.

Screenshots

• Wizard Self Check screen shows many ❌ such as:
  • “Config directory not exist”
  • “Sites-available directory not exist”
  • “Nginx PID path exists: PID path not exist”
    even though /etc/nginx contains full config and /run/nginx.pid exists in the container.
• Clicking “Attempt to fix” does not flip them to ✅.

Info (please complete the following information):

• Server OS: Ubuntu 22.04 LTS (x86_64)
• Server Arch: x86_64
• Nginx UI Version: uozi/nginx-ui:latest as of 2025-10-28
• Your Browser: Firefox latest on desktop
• Docker runtime: compose v2, container runs in a custom external network proxy-tier

Relevant container logs at startup:

ERROR ... internal/nginx/resolve_path.go:91    nginx.GetConfEntryPath len(match) < 1
ERROR ... internal/nginx/resolve_path.go:67    nginx.GetConfPath len(match) < 1
ERROR ... internal/nginx/resolve_path.go:109   pid path not found in nginx -V output
DEBUG ... nginx version: nginx/1.29.1
...
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
 --conf-path=/etc/nginx/nginx.conf
 --error-log-path=/var/log/nginx/error.log
 --http-log-path=/var/log/nginx/access.log
 --pid-path=/run/nginx.pid
...
PID path not exist

As you can see, nginx-ui itself prints --pid-path=/run/nginx.pid from nginx -V, and /var/run/nginx.pid actually exists (with /var/run symlinked to /run), but the wizard still errors “PID path not exist” and never proceeds.

Additional context
Below is our docker-compose.yml snippet we use to run nginx-ui side-by-side with an existing nginx proxy. We mount empty host dirs into /etc/nginx and /etc/nginx-ui, then nginx-ui populates them. Ports 8080/8443 are for testing before we swap it to :80/:443 in production:

  nginx-ui:
    image: uozi/nginx-ui:latest
    container_name: nginx-ui
    restart: always
    environment:
      - TZ=Europe/Berlin
      # (we also tried without predefined vars, and with predefined vars)
      # - NGINX_UI_PREDEFINED_USER_NAME=enwikuna
      # - NGINX_UI_PREDEFINED_USER_PASSWORD=SuperSecret123!
      # - NGINX_UI_NGINX_CONTAINER_NAME=nginx-ui
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - /opt/system/nginx-ui/nginx:/etc/nginx
      - /opt/system/nginx-ui/ui:/etc/nginx-ui
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - proxy-tier

networks:
  proxy-tier:
    external: true

Inside nginx-ui, after first start, /etc/nginx looks like this (bind-mounted from host):

conf.d
fastcgi_params
mime.types
modules
nginx.conf
scgi_params
sites-available
sites-enabled
streams-available
streams-enabled
uwsgi_params

nginx.conf contains:

pid        /var/run/nginx.pid;
...
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*.conf;

And /run/nginx.pid exists and holds the current master PID.

TL;DR

• nginx-ui installer refuses to accept a perfectly valid running Nginx.
• It never advances past the Self Check.
• It incorrectly reports “PID path not exist” even though /var/run/nginx.pid (→ /run/nginx.pid) is present.
• There is no way to reach the login / dashboard without manually setting a bunch of undocumented env vars to skip the installation wizard.

It would help if:

• the wizard accepted /var/run symlinking to /run, or
• the wizard let us continue after manual confirmation, or
• these config paths could be entered in the wizard UI directly, or
• the documented env vars for non-interactive install were mentioned prominently so we can bypass the wizard cleanly.

[enwikuna]

I hope this can be fixed fast. I'm not able to setup a server. If there is no fix, I sadly need to go with the plain NGINX which would be mad because I always love effort in this kind of projects.

[enwikuna]

Hi there,

here is additional context from my environment that might help you reproduce the installer issue.

Summary

The first-time installation wizard (“Self Check”) never lets me proceed. It keeps showing red ❌ for things like:

• “Failed to read nginx.conf”
• “Config directory not exist”
• “PID path not exist”
• “Nginx.conf includes sites-enabled directory”

Even though:

• /etc/nginx exists and is mounted
• /etc/nginx/nginx.conf exists and is readable
• /etc/nginx/conf.d and /etc/nginx/sites-enabled exist
• /var/run/nginx.pid exists and contains the running Nginx PID
• Nginx is actually running inside the same container

Because the wizard never turns green, I never reach the actual UI unless I skip the wizard using environment variables.

Possibly relevant: parsing logic

From looking at internal/nginx/resolve_path.go, functions like GetConfPath(), GetConfEntryPath(), and GetPIDPath() try to detect paths by parsing the output of nginx -V using regex.

Example from the code:

r, _ := regexp.Compile("--conf-path=(.*)/(.*.conf)")
match := r.FindStringSubmatch(out)
if len(match) < 1 {
    logger.Error("nginx.GetConfPath len(match) < 1")
    return ""
}

and:

r, _ := regexp.Compile("--pid-path=(.*.pid)")
match := r.FindStringSubmatch(out)
if len(match) < 1 {
    logger.Error("pid path not found in nginx -V output")
    return ""
}

In my logs I repeatedly get:

• nginx.GetConfPath len(match) < 1
• nginx.GetConfEntryPath len(match) < 1
• pid path not found in nginx -V output

After that, the wizard reports the checks as failed and will not continue.

The important part

Inside the container, nginx -V returns:

nginx version: nginx/1.29.1
built by gcc 12.2.0 (Debian 12.2.0-14+deb12u1)
built with OpenSSL 3.0.16 11 Feb 2025 (running with OpenSSL 3.0.17 1 Jul 2025)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -ffile-prefix-map=/home/builder/debuild/nginx-1.29.1/debian/debuild-base/nginx-1.29.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

So --conf-path=/etc/nginx/nginx.conf and --pid-path=/run/nginx.pid are clearly present.

But the current regex logic in GetConfPath(), GetConfEntryPath(), and GetPIDPath() still fails to detect them and returns "", which then causes the installer UI to say these paths don’t exist.

As a result:

• The wizard reports “PID path not exist” even though /var/run/nginx.pid exists ( /var/run → /run symlink ).
• The wizard reports “Failed to read nginx.conf” even though /etc/nginx/nginx.conf exists and includes:

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*.conf;

Practical impact

Because these functions return "" instead of falling back to sane defaults (like /etc/nginx, /etc/nginx/nginx.conf, /var/run/nginx.pid), the wizard is effectively a dead-end. You cannot reach the login screen or dashboard.

The only way I can currently use Nginx UI is to skip the installer completely and inject all paths + an admin user via environment variables, e.g.:

NGINX_UI_NODE_SKIP_INSTALLATION=true
NGINX_UI_PREDEFINED_USER_NAME=...
NGINX_UI_PREDEFINED_USER_PASSWORD=...
NGINX_UI_NGINX_CONFIG_DIR=/etc/nginx
NGINX_UI_NGINX_CONFIG_FILE=/etc/nginx/nginx.conf
NGINX_UI_NGINX_PID_PATH=/var/run/nginx.pid
NGINX_UI_NGINX_SBIN_PATH=/usr/sbin/nginx
NGINX_UI_NGINX_ACCESS_LOG_PATH=/var/log/nginx/access.log
NGINX_UI_NGINX_ERROR_LOG_PATH=/var/log/nginx/error.log
NGINX_UI_NGINX_LOG_DIR_WHITE_LIST=/var/log/nginx
NGINX_UI_NGINX_TEST_CONFIG_CMD=nginx -t
NGINX_UI_NGINX_RELOAD_CMD=nginx -s reload
NGINX_UI_NGINX_RESTART_CMD=nginx -s reload
NGINX_UI_NGINX_CONTAINER_NAME=nginx-ui

That works (I get a login form and can use the UI), but it bypasses the installer entirely.

What would fix this (from my perspective)

It would probably be enough to make the detection functions more forgiving:

• In GetConfPath():

  • Use a simpler regex like --conf-path=([^\s]+) to grab the full value (e.g. /etc/nginx/nginx.conf) and then filepath.Dir(...).
  • If no match, fall back to /etc/nginx instead of returning "".

• In GetConfEntryPath():

  • Parse --conf-path=... the same way.
  • If no match, fall back to <ConfPath>/nginx.conf.
  • Only log an error if that ALSO fails.

• In GetPIDPath():

  • Parse --pid-path=([^\s]+).
  • If no match, try common defaults /var/run/nginx.pid and /run/nginx.pid before returning "" (on my system /var/run/nginx.pid exists and contains the PID).

This way the wizard would be able to continue with sane defaults, instead of blocking forever.

So in short:

• The core issue is not my Nginx.
• The core issue is that the first-time setup wizard can get stuck because the regex in resolve_path.go fails to parse nginx -V, and when that happens it returns "" instead of providing a fallback.
• The UI then reports “not found” and never advances.

Hope this helps, and thank you for building this project.

[enwikuna]

Please see our fix #1414

Build locally and deployed to our server. Path is now resolving successfully.

With the latest image:

025-10-29 13:03:57.414 ERROR github.com/0xJacky/Nginx-UI/internal/nginx/resolve_path.go:67 nginx.GetConfPath len(match) < 1

With the fix:

2025-10-29 13:05:24.171 DEBUG github.com/0xJacky/Nginx-UI/internal/nginx/resolve_path.go:80 nginx.GetConfPath fallback used base /etc/nginx

[Yanik39]

I have similar problems. They came after update. Everything working just fine except self check.

[enwikuna]

I have similar problems. They came after update. Everything working just fine except self check.

It’s a bug. I can confirm it since I fixed it myself locally with a Docker build. I you want I can provide a fixed version of the latest one to you until the guy of this is repo finds time to merge and release our two fix-pull-requests. I you want the fixed version, write me an email to: info[at]enwikuna.de and i will reply with an OneDrive link incl. short tutorial how to use it. Please note that you need to change the image At some point when the fix is merged to receive updates in the future.

[Yanik39]

I have similar problems. They came after update. Everything working just fine except self check.

It’s a bug. I can confirm it since I fixed it myself locally with a Docker build. I you want I can provide a fixed version of the latest one to you until the guy of this is repo finds time to merge and release our two fix-pull-requests. I you want the fixed version, write me an email to: info[at]enwikuna.de and i will reply with an OneDrive link incl. short tutorial how to use it. Please note that you need to change the image At some point when the fix is merged to receive updates in the future.

Thanks for your response. All my system is working. There is no effect to my sites etc. So its not urgent for me and would like to wait for official release. Thanks a lot for your suggestion.