starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: Subfolder path being forced on after update v2.18.0 #2513

New Issue
Open
opened 2026-04-25 00:07:55 +02:00 by adam · 10 comments
adam commented 2026-04-25 00:07:55 +02:00
Owner
Copy Link
Copy Source

Originally created by @DieselTech on GitHub (Jan 21, 2025).

What happened?

After the v2.18.0 update that added subdirectory support, ABS defaults to it being turned on for existing installs.

Image

Because it is defaulting on, it is causing problems with setups that are configured for a specific path.

What did you expect to happen?

Not to be forced into using subdirectories after the update

Steps to reproduce the issue

  1. Update to v2.18.0

Audiobookshelf version

v2.18.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

Additional Notes

No response

Originally created by @DieselTech on GitHub (Jan 21, 2025). ### What happened? After the v2.18.0 update that added subdirectory support, ABS defaults to it being turned on for existing installs. ![Image](https://github.com/user-attachments/assets/5d28533a-e737-4401-91fe-10f5acc61310) Because it is defaulting on, it is causing problems with setups that are configured for a specific path. ### What did you expect to happen? Not to be forced into using subdirectories after the update ### Steps to reproduce the issue 1. Update to v2.18.0 ### Audiobookshelf version v2.18.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:07:55 +02:00
adam commented 2026-04-25 00:07:55 +02:00
Author
Owner
Copy Link
Copy Source

@mikelococo commented on GitHub (Jan 26, 2025):

For anyone looking to come up to speed on the history of this feature:

I haven't upgraded to v2.8.x yet because it felt like a strange choice to add a mandatory subpath rather retain consistency for existing installs via a disabled-by-default optional subpath and I was concerned about interactions with my proxy setup the side effects of these changes.

@mikelococo commented on GitHub (Jan 26, 2025): For anyone looking to come up to speed on the history of this feature: * [Design discussion](https://github.com/advplyr/audiobookshelf/discussions/3535): ~Frustratingly, it appears that comments from sapd discussing why some users would likely not be happy about a mandatory subpath were deleted.~ Maybe there just was no further discussion, seen further down this thread. * [Github Issue](https://github.com/advplyr/audiobookshelf/issues/385): The issue and PR have additional history and design discussion. * [Github PR](https://github.com/advplyr/audiobookshelf/pull/3810): Discussion that the ROUTER_BASE_PATH parameter doesn't function without a custom-build. * v2.8.1 fixed two problems subpathing broke in v2.8.0: * Epub ebooks fail to load when using subdirectory https://github.com/advplyr/audiobookshelf/issues/3865 * 404 not found for texture image when using subdirectory https://github.com/advplyr/audiobookshelf/issues/385 by @mikiher in https://github.com/advplyr/audiobookshelf/pull/3864 I haven't upgraded to v2.8.x yet because it felt like a strange choice to add a mandatory subpath rather retain consistency for existing installs via a disabled-by-default optional subpath and I was concerned about ~interactions with my proxy setup~ the side effects of these changes.
adam commented 2026-04-25 00:07:55 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 26, 2025):

Design discussion: Frustratingly, it appears that comments from sapd discussing why some users would likely not be happy about a mandatory subpath were deleted.

The comments are still there. https://github.com/advplyr/audiobookshelf/discussions/3535#discussioncomment-10993141

I haven't upgraded to v2.8.x yet because it felt like a strange choice to add a mandatory subpath rather retain consistency for existing installs via a disabled-by-default optional subpath and I was concerned about interactions with my proxy setup.

This change only affects the web client and OIDC, the API is unchanged (apps and custom API scripts wouldn't be affected). You would run into issues if you have middleware intercepting the client requests. Is there something specific with your reverse proxy that wouldn't work?

@nichwall commented on GitHub (Jan 26, 2025): > [Design discussion](https://github.com/advplyr/audiobookshelf/discussions/3535): Frustratingly, it appears that comments from sapd discussing why some users would likely not be happy about a mandatory subpath were deleted. The comments are still there. https://github.com/advplyr/audiobookshelf/discussions/3535#discussioncomment-10993141 > I haven't upgraded to v2.8.x yet because it felt like a strange choice to add a mandatory subpath rather retain consistency for existing installs via a disabled-by-default optional subpath and I was concerned about interactions with my proxy setup. This change only affects the web client and OIDC, the API is unchanged (apps and custom API scripts wouldn't be affected). You would run into issues if you have middleware intercepting the client requests. Is there something specific with your reverse proxy that wouldn't work?
adam commented 2026-04-25 00:07:55 +02:00
Author
Owner
Copy Link
Copy Source

@mikelococo commented on GitHub (Jan 26, 2025):

The comments are still there. https://github.com/advplyr/audiobookshelf/discussions/3535#discussioncomment-10993141

The final two comments are mikiher asking Why would it matter to you if you don't need to change anything for it to work? Is it just a matter of style? and then replying to their own comment with Thanks for having this disucussion. It gave me food for thought. I inferred additional responses from sapd in between those comments, but perhaps there never were.

This change only affects the web client and OIDC, the API is unchanged (apps and custom API scripts wouldn't be affected). You would run into issues if you have middleware intercepting the client requests. Is there something specific with your reverse proxy that wouldn't work?

As noted, I've deferred the upgrade to at least give it more time to bake and haven't tested. I don't expect there's anything about my proxy setup that absolutely can't be made to work in a post 2.8.x world, but the primary reason I favor reverse-proxy setups without subpaths is that once the domain-names and certificates are issued... subpathless results the simplest possible proxy config with the fewest moving parts to debug if anything goes wrong. That simplicity is not possible to recreate in a post-2.8.x world.

Instead, subpathing on the reverse proxy is now the simplest setup with the fewest moving parts... except that cleanly adopting this change would require updating all clients and OIDC configs for existing subpathless configs (and would leave a confusing empty root on any site that doesn't already have content there). So backwards compatibility is provided through a complex redirect layer and subpathless 2.7.x setups that were conceptually simple to understand and debug when upgraded to 2.8.x become redirect monstrosities that inherit all the complexity of a subpathing setup plus all the complexity of the redirect shims, and now their behavior depends on what client and entrypoint you use.

For anyone who cares about routing simplicity, 2.8.x is a major design regression with no opt-out. A traditional approach with a configurable subpath parameter (or one dynamically inferred from proxy headers) which defaults to empty would make the migration path for existing subpathless deployments a noop, shield existing deployments from almost all the bugs and growing pains associated with the new feature, and retain routing simplicity for subpathless deployments.

@mikelococo commented on GitHub (Jan 26, 2025): > The comments are still there. https://github.com/advplyr/audiobookshelf/discussions/3535#discussioncomment-10993141 The final two comments are mikiher asking _Why would it matter to you if you don't need to change anything for it to work? Is it just a matter of style?_ and then replying to their own comment with _Thanks for having this disucussion. It gave me food for thought._ I inferred additional responses from sapd in between those comments, but perhaps there never were. > This change only affects the web client and OIDC, the API is unchanged (apps and custom API scripts wouldn't be affected). You would run into issues if you have middleware intercepting the client requests. Is there something specific with your reverse proxy that wouldn't work? As noted, I've deferred the upgrade to at least give it more time to bake and haven't tested. I don't expect there's anything about my proxy setup that absolutely can't be made to work in a post 2.8.x world, but the primary reason I favor reverse-proxy setups without subpaths is that once the domain-names and certificates are issued... subpathless results the simplest possible proxy config with the fewest moving parts to debug if anything goes wrong. That simplicity is not possible to recreate in a post-2.8.x world. Instead, subpathing on the reverse proxy is now the simplest setup with the fewest moving parts... except that cleanly adopting this change would require updating all clients and OIDC configs for existing subpathless configs (and would leave a confusing empty root on any site that doesn't already have content there). So backwards compatibility is provided through a complex redirect layer and subpathless 2.7.x setups that were conceptually simple to understand and debug when upgraded to 2.8.x become redirect monstrosities that inherit all the complexity of a subpathing setup plus all the complexity of the redirect shims, and now their behavior depends on what client and entrypoint you use. For anyone who cares about routing simplicity, 2.8.x is a major design regression with no opt-out. A traditional approach with a configurable subpath parameter (or one dynamically inferred from proxy headers) which defaults to empty would make the migration path for existing subpathless deployments a noop, shield existing deployments from almost all the bugs and growing pains associated with the new feature, and retain routing simplicity for subpathless deployments.
adam commented 2026-04-25 00:07:56 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jan 27, 2025):

Is there something specific with your reverse proxy that wouldn't work?

As noted, I've deferred the upgrade to at least give it more time to bake and haven't tested. I don't expect there's anything about my proxy setup that absolutely can't be made to work in a post 2.18.x world, but the primary reason I favor reverse-proxy setups without subpaths is that once the domain-names and certificates are issued... subpathless results the simplest possible proxy config with the fewest moving parts to debug if anything goes wrong. That simplicity is not possible to recreate in a post-2.18.x world.

(Corrected to 2.18.x, not 2.8.x)

If you have set up your server to work with a subdomain, you should not need to change anything for the 2.18.x update (may depend on specific reverse proxy). You can still access the API and web client through the subdomain, the web client just redirects to the audiobookshelf/ subdirectory if you entered the subdomain into the address bar.

This is done by prepending subdirectory of audiobookshelf/ for the web client if it doesn't exist in the original request, it is still accessed through the subdomain. All existing links/bookmarks from 2.17.7 and before would still work. As has been stated in other discussions, this would only affect you if you are doing complicated routing or intercepting the web client traffic to do something with it.

@nichwall commented on GitHub (Jan 27, 2025): > > Is there something specific with your reverse proxy that wouldn't work? > > As noted, I've deferred the upgrade to at least give it more time to bake and haven't tested. I don't expect there's anything about my proxy setup that absolutely can't be made to work in a post 2.18.x world, but the primary reason I favor reverse-proxy setups without subpaths is that once the domain-names and certificates are issued... subpathless results the simplest possible proxy config with the fewest moving parts to debug if anything goes wrong. That simplicity is not possible to recreate in a post-2.18.x world. (Corrected to 2.18.x, not 2.8.x) If you have set up your server to work with a subdomain, you should not need to change anything for the `2.18.x` update (may depend on specific reverse proxy). You can still access the API and web client through the subdomain, the web client just redirects to the `audiobookshelf/` subdirectory if you entered the subdomain into the address bar. This is done by prepending subdirectory of `audiobookshelf/` for the web client if it doesn't exist in the original request, it is still accessed through the subdomain. All existing links/bookmarks from `2.17.7` and before would still work. As has been stated in other discussions, this would only affect you if you are doing complicated routing or intercepting the web client traffic to do something with it.
adam commented 2026-04-25 00:07:56 +02:00
Author
Owner
Copy Link
Copy Source

@laxandrea commented on GitHub (Jan 31, 2025):

I add this here because may be it could be considered a related bug:

Using the default audiobookshelf subfolder and forcing the client to use HLS, the output.m3u8 multimedia playlist file cannot be reached without a proxy edit, because the server side encoded absolute path in Stream.js

get clientPlaylistUri() {
    return `/hls/${this.id}/output.m3u8`
  }
@laxandrea commented on GitHub (Jan 31, 2025): I add this here because may be it could be considered a related bug: Using the default audiobookshelf subfolder and forcing the client to use HLS, the `output.m3u8` multimedia playlist file cannot be reached without a proxy edit, because the server side encoded absolute path in `Stream.js` ``` get clientPlaylistUri() { return `/hls/${this.id}/output.m3u8` } ```
adam commented 2026-04-25 00:07:56 +02:00
Author
Owner
Copy Link
Copy Source

@hillmanov commented on GitHub (Sep 14, 2025):

This change has also caused me issues with Google - having "audiobookshelf" in the URL gets my entire domain flagged as "Dangerous" and I have had to appeal to Google 4 times in the last 2 months to get my domain cleared.

Image

The Google Search Console states:

"These pages attempt to trick users into doing something dangerous, such as installing unwanted software or revealing personal information":

https:.//<mydomain>.com/audiobookshelf/login

Is there an easier way to set the ROUTER_BASE_PATH for docker installations?

@hillmanov commented on GitHub (Sep 14, 2025): This change has also caused me issues with Google - having "audiobookshelf" in the URL gets my entire domain flagged as "Dangerous" and I have had to appeal to Google 4 times in the last 2 months to get my domain cleared. <img width="829" height="554" alt="Image" src="https://github.com/user-attachments/assets/d66a78d8-907d-411a-9e5d-2e88d26404e8" /> The Google Search Console states: "These pages attempt to trick users into doing something dangerous, such as installing unwanted software or revealing personal information": `https:.//<mydomain>.com/audiobookshelf/login` Is there an easier way to set the `ROUTER_BASE_PATH` for docker installations?
adam commented 2026-04-25 00:07:56 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Sep 14, 2025):

Is there an easier way to set the ROUTER_BASE_PATH for docker installations?

You would need to build it manually. That's the only way. It's somewhat simple, just not that convenient

@Vito0912 commented on GitHub (Sep 14, 2025): > Is there an easier way to set the `ROUTER_BASE_PATH` for docker installations? You would need to build it manually. That's the only way. It's somewhat simple, just not that convenient
adam commented 2026-04-25 00:07:57 +02:00
Author
Owner
Copy Link
Copy Source

@dashohoxha commented on GitHub (Nov 2, 2025):

You would need to build it manually. That's the only way. It's somewhat simple, just not that convenient

How does one build it manually? (Sorry if this is a stupid question.)
I have installed it with docker compose.

@dashohoxha commented on GitHub (Nov 2, 2025): > You would need to build it manually. That's the only way. It's somewhat simple, just not that convenient How does one build it manually? (Sorry if this is a stupid question.) I have installed it with docker compose.
adam commented 2026-04-25 00:07:57 +02:00
Author
Owner
Copy Link
Copy Source

@dscso commented on GitHub (Dec 25, 2025):

I have an ugly workaround, maybe it is helpful for someone:

services:
  audiobookshelf:
    container_name: audiobookshelf
    image: audiobookshelf
    build:
      context: https://github.com/advplyr/audiobookshelf.git#v2.32.1
      dockerfile_inline: |
        FROM node:20-alpine AS build-client
        ENV ROUTER_BASE_PATH=${AUDIO_BASE_DIR}
        WORKDIR /client
        COPY /client /client
        RUN npm ci && npm cache clean --force
        RUN npm run generate

        FROM ghcr.io/advplyr/audiobookshelf:2.32.1
        ENV ROUTER_BASE_PATH=${AUDIO_BASE_DIR}
        COPY --from=build-client /client/dist /app/client/dist
    ports:
      - 13378:80
    networks:
      - proxy
    volumes:
      - ${DATA_LOCATION}:/audio
      - ./vol/audiobookshelf/metadata:/metadata
      - ./vol/audiobookshelf/config:/config
    restart: unless-stopped
    user: 1000:1000

in the .env file you can set the base path of audio book shelf:

AUDIO_BASE_DIR=/myaudiobookshelf
DATA_LOCATION=/mnt/mynicedrive/audio
@dscso commented on GitHub (Dec 25, 2025): I have an ugly workaround, maybe it is helpful for someone: ```yaml services: audiobookshelf: container_name: audiobookshelf image: audiobookshelf build: context: https://github.com/advplyr/audiobookshelf.git#v2.32.1 dockerfile_inline: | FROM node:20-alpine AS build-client ENV ROUTER_BASE_PATH=${AUDIO_BASE_DIR} WORKDIR /client COPY /client /client RUN npm ci && npm cache clean --force RUN npm run generate FROM ghcr.io/advplyr/audiobookshelf:2.32.1 ENV ROUTER_BASE_PATH=${AUDIO_BASE_DIR} COPY --from=build-client /client/dist /app/client/dist ports: - 13378:80 networks: - proxy volumes: - ${DATA_LOCATION}:/audio - ./vol/audiobookshelf/metadata:/metadata - ./vol/audiobookshelf/config:/config restart: unless-stopped user: 1000:1000 ``` in the .env file you can set the base path of audio book shelf: ```env AUDIO_BASE_DIR=/myaudiobookshelf DATA_LOCATION=/mnt/mynicedrive/audio ```
adam commented 2026-04-25 00:07:57 +02:00
Author
Owner
Copy Link
Copy Source

@AndrolGenhald commented on GitHub (Mar 3, 2026):

Just to add a bit more to this, I very strongly prefer to proxy different web applications with subdomains rather than subfolders since the same origin policy creates a much stronger security separation between different applications. Since I have a subdomain anyway, having URLs like https://audiobookshelf.example.com/audiobookshelf looks messy and redundant.

The ROUTER_BASE_PATH env var can be used to change the base path, but unfortunately it seems that changing it to be different from the value it had when packaged breaks everything (I'm using the Debian apt repository and I can see in the binary that it hard-codes references like <script src="/audiobookshelf/_nuxt/710117f.js">).

@AndrolGenhald commented on GitHub (Mar 3, 2026): Just to add a bit more to this, I **very** strongly prefer to proxy different web applications with subdomains rather than subfolders since the same origin policy creates a much stronger security separation between different applications. Since I have a subdomain anyway, having URLs like `https://audiobookshelf.example.com/audiobookshelf` looks messy and redundant. The `ROUTER_BASE_PATH` env var can be used to change the base path, but unfortunately it seems that changing it to be different from the value it had when packaged breaks everything (I'm using the Debian apt repository and I can see in the binary that it hard-codes references like `<script src="/audiobookshelf/_nuxt/710117f.js">`).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2513
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?