fix(filebrowser_quantum): repair direct access on port 8071 (#2998)

* fix(filebrowser_quantum): repair direct access on port 8071

1.5.1.1 published the port but direct access still did not work, in two ways
measured against a running instance:

1. The root redirect was absolute, so nginx built it from $server_port and
   sent the browser to :8072 — the container-internal port, not the published
   one. `absolute_redirect off` keeps the redirect relative.
2. The page served under /filebrowser_quantum/ referenced its assets under
   the app's own baseURL (the ingress entry path), which that vhost did not
   route: GET /api/hassio_ingress/<hash>/public/static/favicon.svg returned
   404 while the same file under /filebrowser_quantum/ returned 200. The page
   loaded and every asset on it failed.

Rather than translating paths, the vhost now passes requests through
unchanged and redirects only the bare root to the app's baseURL, which is
what its own links already point at. Asset, API and websocket URLs then work
without any response rewriting. Ingress is untouched.

* docs(filebrowser_quantum): describe the legacy redirects accurately

The comments, CHANGELOG and README still said only the bare root was
redirected, which stopped being true when the two /filebrowser_quantum
compatibility redirects were added. Raised by CodeRabbit and Codex.

filebrowser_quantum/CHANGELOG.md

@@ -1,4 +1,12 @@
  
+## 1.5.1.2 (2026-08-19)
+- Fix direct access on port 8071, which was broken in 1.5.1.1: the root
+  redirect pointed at the container-internal port 8072 instead of the
+  published one, and the page it led to referenced assets under a path the
+  add-on did not serve, so every asset returned 404. Requests are now passed
+  through unchanged, with the bare root and the two previously documented
+  `/filebrowser_quantum` URLs redirected to the app's configured base path.
+
 ## 1.5.1.1 (2026-08-16)
 - Expose the web UI on host port 8071, reachable at `<your-ip>:8071`
   (redirects to `/filebrowser_quantum/`). Direct access is served by a new,

filebrowser_quantum/README.md

@@ -42,11 +42,11 @@ comparison to installing any other Home Assistant add-on.
 1. Click the `Save` button to store your configuration.
 1. Start the add-on.
 1. Check the logs of the add-on to see if everything went well.
-1. Access the web UI through the sidebar or at `<your-ip>:8071/filebrowser_quantum/`.
+1. Access the web UI through the sidebar or at `<your-ip>:8071`.
 
 ## Configuration
 
-The web UI can be found at `<your-ip>:8071` (redirects to `/filebrowser_quantum/`) or through the Home Assistant sidebar when using Ingress.
+The web UI can be found at `<your-ip>:8071` or through the Home Assistant sidebar when using Ingress. Direct access redirects to the add-on's configured base path, so the address bar will show a longer URL than the one you typed.
 
 **Default credentials:**
 - Username: `admin`

filebrowser_quantum/config.yaml

@@ -118,4 +118,4 @@ schema:
 slug: filebrowser_quantum
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
-version: "1.5.1.1"
+version: "1.5.1.2"

filebrowser_quantum/rootfs/etc/cont-init.d/99-run.sh

@@ -43,13 +43,9 @@ declare ingress_interface
 declare ingress_port
 #declare keyfile
 
-# The app's own baseURL is always the Supervisor ingress-entry path — this is
-# unchanged from before. FileBrowser Quantum has no known "ignore baseURL for
-# routing" leniency the way classic filebrowser's app does, so ingress access
-# is left completely untouched here. Direct ip:port access is handled below by
-# a second, separate nginx vhost (direct.conf) that rewrites a fixed public
-# path onto this same ingress-entry baseURL, instead of changing the baseURL
-# itself.
+# The app's own baseURL is the Supervisor ingress-entry path, unchanged from
+# before: FileBrowser emits that prefix as absolute links in its HTML and JS,
+# so it is also the path direct ip:port access has to use (see direct.conf).
 FB_BASEURL=$(bashio::addon.ingress_entry)
 export FB_BASEURL
 
@@ -67,11 +63,11 @@ sed -i "s|%%port%%|${ingress_port}|g" /etc/nginx/servers/ingress.conf
 sed -i "s|%%interface%%|${ingress_interface}|g" /etc/nginx/servers/ingress.conf
 sed -i "s|%%subpath%%|${FB_BASEURL}/|g" /etc/nginx/servers/ingress.conf
 
-# --- Direct ip:port access (separate from ingress, see comment above) ---
-# Publishes a second nginx vhost on a fixed internal port (published to the
-# host as 8071 via config.yaml's `ports:`), at a fixed public path
-# (/filebrowser_quantum/), that proxies to the same backend the ingress vhost
-# uses. This keeps the app's own baseURL, and therefore ingress, unchanged.
+# --- Direct ip:port access (separate vhost, ingress untouched) ---
+# Listens on 8072, published to the host as 8071 by config.yaml's `ports:`.
+# Requests are passed through unchanged; the bare root and the two legacy
+# /filebrowser_quantum paths are redirected to the app's baseURL, which is what
+# its own links already point at.
 sed -i "s|%%protocol%%|${ADDON_PROTOCOL}|g" /etc/nginx/servers/direct.conf
 sed -i "s|%%subpath%%|${FB_BASEURL}/|g" /etc/nginx/servers/direct.conf
 

filebrowser_quantum/rootfs/etc/nginx/servers/direct.conf

@@ -6,19 +6,35 @@ server {
 
     client_max_body_size 0;
 
+    # nginx listens on 8072 inside the container but is published to the host
+    # as 8071. An absolute redirect would be built from $server_port and send
+    # the browser to :8072, which is not published and therefore unreachable.
+    absolute_redirect off;
+
+    # FileBrowser serves under its baseURL (the Supervisor ingress entry) and
+    # emits that prefix as absolute links in its HTML/JS, so the browser must
+    # use that same path here. The bare root and the two legacy paths below
+    # redirect to it; every other request is proxied through untouched, which
+    # keeps asset, API and websocket URLs working without response rewriting.
     location = / {
-        return 302 /filebrowser_quantum/;
+        return 302 %%subpath%%;
     }
 
+    # 1.5.1.1 briefly documented /filebrowser_quantum/ as the direct URL. The
+    # app never served that path itself, so send those bookmarks on instead of
+    # letting them fall through to a 404.
     location = /filebrowser_quantum {
-        return 301 /filebrowser_quantum/;
+        return 302 %%subpath%%;
     }
 
-    location /filebrowser_quantum/ {
-        add_header Access-Control-Allow-Origin *;
+    location = /filebrowser_quantum/ {
+        return 302 %%subpath%%;
+    }
+
+    location / {
         proxy_connect_timeout 30m;
         proxy_send_timeout 30m;
         proxy_read_timeout 30m;
-        proxy_pass         %%protocol%%://backend%%subpath%%;
+        proxy_pass         %%protocol%%://backend;
     }
 }