[Bug]: Not possible to upgrade to latest version #2771

@Vito0912 commented on GitHub (May 15, 2025):

Duplicate of https://github.com/advplyr/audiobookshelf/issues/4289

@Vito0912 commented on GitHub (May 15, 2025): Duplicate of https://github.com/advplyr/audiobookshelf/issues/4289

adam commented

@Kapot commented on GitHub (May 15, 2025):

This is marked as a duplicate, but i'd like to add that the suggested solutions there dont seem to work for me.

Using '2.20.0' instead of 'latest' didnt work.
Using another image service didnt work.

Only using advplyr/audiobookshelf:2.21.0 as image (so a downgrade) makes me able to run it again.

@Kapot commented on GitHub (May 15, 2025): This is marked as a duplicate, but i'd like to add that the suggested solutions there dont seem to work for me. - Using '2.20.0' instead of 'latest' didnt work. - Using another image service didnt work. Only using advplyr/audiobookshelf:2.21.0 as image (so a downgrade) makes me able to run it again.

adam commented

@Cotignac commented on GitHub (May 15, 2025):

I'm not familiar with how to downgrade. Never been forced to do that. Please let me know how to do it.

@Cotignac commented on GitHub (May 15, 2025): I'm not familiar with how to downgrade. Never been forced to do that. Please let me know how to do it.

adam commented

@Kapot commented on GitHub (May 15, 2025):

I'm not familiar with how to downgrade. Never been forced to do that. Please let me know how to do it.

Duplicate/Edit the container, but edit the image to advplyr/audiobookshelf:2.21.0. Deploy the container.

@Kapot commented on GitHub (May 15, 2025): > I'm not familiar with how to downgrade. Never been forced to do that. Please let me know how to do it. Duplicate/Edit the container, but edit the image to advplyr/audiobookshelf:2.21.0. Deploy the container.

adam commented

@Vito0912 commented on GitHub (May 15, 2025):

This is marked as a duplicate, but i'd like to add that the suggested solutions there dont seem to work for me.

I also think that the original issue should be reopened because the solutions listed there do not work for everyone (but I am just a contributor, not a maintainer, so it's any opinion anyways). It would be better to collect logs and solutions in one issue instead of having several, which is why I made a notice about duplicates.

@Vito0912 commented on GitHub (May 15, 2025): > This is marked as a duplicate, but i'd like to add that the suggested solutions there dont seem to work for me. I also think that the original issue should be reopened because the solutions listed there do not work for everyone (but I am just a contributor, not a maintainer, so it's any opinion anyways). It would be better to collect logs and solutions in one issue instead of having several, which is why I made a notice about duplicates.

adam commented

@Cotignac commented on GitHub (May 15, 2025):

I have to agree.
I've tried to downgrade to version 2.21.0 and to 2.20.0 and none of them works.

@Cotignac commented on GitHub (May 15, 2025): I have to agree. I've tried to downgrade to version 2.21.0 and to 2.20.0 and none of them works.

adam commented

@Vito0912 commented on GitHub (May 15, 2025):

One idea I have is to completely delete the container by running docker compose down and then docker compose up -d. Keep in mind that this will remove all data and volumes that are not properly bound.
I don't see how this should help, but I also don't see why this issue is there in the first place and then only for a few people

@Vito0912 commented on GitHub (May 15, 2025): One idea I have is to completely delete the container by running `docker compose down` and then `docker compose up -d`. Keep in mind that this will remove all data and volumes that are not properly bound. I don't see how this should help, but I also don't see why this issue is there in the first place and then only for a few people

adam commented

@ykarus117 commented on GitHub (May 15, 2025):

Same error with portainer after re-creating the container with latest image from 2.21.0

@ykarus117 commented on GitHub (May 15, 2025): Same error with portainer after re-creating the container with latest image from 2.21.0

adam commented

@mkstephenson commented on GitHub (May 15, 2025):

On Synology I was able to get it running after cleaning the project and rebuilding (I am running it using docker compose in the container manager).

@mkstephenson commented on GitHub (May 15, 2025): On Synology I was able to get it running after cleaning the project and rebuilding (I am running it using docker compose in the container manager).

adam commented

@advplyr commented on GitHub (May 15, 2025):

Last time this came up with Synology someone broke down exactly why this happens. It is a Synology bug with container caching or something like that, idk I don't have a Synology to test with.

@advplyr commented on GitHub (May 15, 2025): Last time this came up with Synology someone broke down exactly why this happens. It is a Synology bug with container caching or something like that, idk I don't have a Synology to test with.

adam commented

@advplyr commented on GitHub (May 15, 2025):

Here is some info. https://github.com/advplyr/audiobookshelf/issues/3868#issuecomment-2605327783

@advplyr commented on GitHub (May 15, 2025): Here is some info. https://github.com/advplyr/audiobookshelf/issues/3868#issuecomment-2605327783

adam commented

@Vito0912 commented on GitHub (May 15, 2025):

For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone:

Add these lines to your Docker Compose file (using the same indentation as image):

    entrypoint: ["/bin/sh", "-c"]
    command: ["ls && tail -f /dev/null"]

Recreate the container, then remove these lines and recreate the container again.
If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together.

Just note that these lines do should not actually solve the problem. I only add thes to stop the Docker container from restarting over and over to get a look at the file system.
These just prevent the node command from running and won't start ABS

Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often).

@Vito0912 commented on GitHub (May 15, 2025): For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone: Add these lines to your Docker Compose file (using the same indentation as `image`): ``` entrypoint: ["/bin/sh", "-c"] command: ["ls && tail -f /dev/null"] ``` Recreate the container, then remove these lines and recreate the container again. If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together. Just note that these lines ~~do~~ *should* not actually solve the problem. I only add thes to stop the Docker container from restarting over and over to get a look at the file system. These just prevent the node command from running and won't start ABS Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often).

adam commented

@ykarus117 commented on GitHub (May 15, 2025):

Last time this came up with Synology someone broke down exactly why this happens. It is a Synology bug with container caching or something like that, idk I don't have a Synology to test with.

I'm not using Synology (I'm on a default Ubuntu server 24.04.2 LTS installation), apologies I should have specified it beforehand.

@ykarus117 commented on GitHub (May 15, 2025): > Last time this came up with Synology someone broke down exactly why this happens. It is a Synology bug with container caching or something like that, idk I don't have a Synology to test with. I'm not using Synology (I'm on a default Ubuntu server 24.04.2 LTS installation), apologies I should have specified it beforehand.

adam commented

@nathang21 commented on GitHub (May 15, 2025):

For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone:

Add these lines to your Docker Compose file (using the same indentation as image):
    entrypoint: ["/bin/sh", "-c"]
    command: ["ls && tail -f /dev/null"]
Recreate the container, then remove these lines and recreate the container again. If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together. (Just note that these lines have nothing actually that should solve this, that I tried only to get the docker container out of a restart loop)

Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often).

I confirmed this worked for me, without changing anything else. Super weird, not sure how to explain this.
docker compose down --> add those 2 lines to compose file --> docker compose up --> wait a min --> docker compose down --> remove those 2 lines from compose file --> docker compose up again.

Edit I spoke too soon, it started crash looping again but it might be due to my healthcheck, which I have since disabled.

    # healthcheck:
    #   # test: ["CMD", "curl", "-f", "http://localhost:80"]
    #   test: curl -sf https://www.google.com || exit 1
    #   interval: 1m
    #   timeout: 10s
    #   retries: 3
    #   start_period: 30s

@nathang21 commented on GitHub (May 15, 2025): > For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone: > > Add these lines to your Docker Compose file (using the same indentation as `image`): > > ``` > entrypoint: ["/bin/sh", "-c"] > command: ["ls && tail -f /dev/null"] > ``` > > Recreate the container, then remove these lines and recreate the container again. If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together. (Just note that these lines have nothing actually that should solve this, that I tried only to get the docker container out of a restart loop) > > Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often). I confirmed this worked for me, without changing anything else. Super weird, not sure how to explain this. docker compose down --> add those 2 lines to compose file --> docker compose up --> wait a min --> docker compose down --> remove those 2 lines from compose file --> docker compose up again. Edit I spoke too soon, it started crash looping again but it might be due to my healthcheck, which I have since disabled. ``` # healthcheck: # # test: ["CMD", "curl", "-f", "http://localhost:80"] # test: curl -sf https://www.google.com || exit 1 # interval: 1m # timeout: 10s # retries: 3 # start_period: 30s ```

adam commented

@DieselTech commented on GitHub (May 15, 2025):

Edit I spoke too soon, it started crash looping again but it might be due to my healthcheck, which I have since disabled.
    # healthcheck:
    #   # test: ["CMD", "curl", "-f", "http://localhost:80"]
    #   test: curl -sf https://www.google.com || exit 1
    #   interval: 1m
    #   timeout: 10s
    #   retries: 3
    #   start_period: 30s

Yes, ABS does not use curl at all and it was removed from the container image. The project also never included healthchecks in any of the documentation. Unless your actively monitoring your healthchecks using another program / outside service you are likely just causing more headache than your solving with them. If you really must run a healthcheck, wget is installed in the container you can use. Otherwise I would just recommend disabling the check.

@DieselTech commented on GitHub (May 15, 2025): > > Edit I spoke too soon, it started crash looping again but it might be due to my healthcheck, which I have since disabled. > > ``` > # healthcheck: > # # test: ["CMD", "curl", "-f", "http://localhost:80"] > # test: curl -sf https://www.google.com || exit 1 > # interval: 1m > # timeout: 10s > # retries: 3 > # start_period: 30s > ``` Yes, ABS does not use `curl` at all and it was removed from the container image. The project also never included healthchecks in any of the documentation. Unless your actively monitoring your healthchecks using another program / outside service you are likely just causing more headache than your solving with them. If you really must run a healthcheck, `wget` is installed in the container you can use. Otherwise I would just recommend disabling the check.

adam commented

ghcr.io/advplyr/audiobookshelf:2.20.0

@postnick commented on GitHub (May 15, 2025):

Using this image worked for me for now. I thought I broke my permissions because I was having issues with a few containers as well.

@postnick commented on GitHub (May 15, 2025): Using this image worked for me for now. I thought I broke my permissions because I was having issues with a few containers as well. [ghcr.io/advplyr/audiobookshelf:2.20.0](ghcr.io/advplyr/audiobookshelf:2.20.0)

adam commented

@waschinski commented on GitHub (May 15, 2025):

I am using Cosmos Cloud for my docker stuff and got it working by removing all NUSQLITE related env vars as well as changing the working_dir path in its compose file from / to /app.

@waschinski commented on GitHub (May 15, 2025): I am using Cosmos Cloud for my docker stuff and got it working by removing all `NUSQLITE` related env vars as well as changing the working_dir path in its compose file from `/` to `/app`.

adam commented

@nichwall commented on GitHub (May 15, 2025):

I am using Cosmos Cloud for my docker stuff and got it working by removing all NUSQLITE related env vars as well as changing the working_dir path in its compose file from / to /app.

~~You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering.~~ Edit, I misunderstood, you can safely remove these variables from your compose. I thought you meant manually changing the Dockerfile that builds the image to get rid of them.

@nichwall commented on GitHub (May 15, 2025): > I am using Cosmos Cloud for my docker stuff and got it working by removing all `NUSQLITE` related env vars as well as changing the working_dir path in its compose file from `/` to `/app`. ~~You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering.~~ Edit, I misunderstood, you can safely remove these variables from your compose. I thought you meant manually changing the Dockerfile that builds the image to get rid of them.

adam commented

@waschinski commented on GitHub (May 15, 2025):

You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering.

I think those have been NUSQLITE3_DIR and NUSQLITE3_PATH. But I can't tell for sure.

Anyway, I didn't explicitly set those env vars and they must have been set to a(n old, outdated?) default value anyway when I set up the container right before the new version released.

@waschinski commented on GitHub (May 15, 2025): > You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering. I think those have been NUSQLITE3_DIR and NUSQLITE3_PATH. But I can't tell for sure. Anyway, I didn't explicitly set those env vars and they must have been set to a(n old, outdated?) default value anyway when I set up the container right before the new version released.

adam commented

@friral commented on GitHub (May 15, 2025):

I have a Synology and encountered the same error.
To rollback to Version 2.21.0 - which ran fine right before the update - I did the following:

Register -> download Image of ABS with label "2.21.0" (careful when selecting the right version, the sorting here is bogus in the UI)
Click the container -> export to json (local computer) - open with notepad and find the line "image" : "advplyr/audiobookshelf" and replace with "image" : "advplyr/audiobookshelf:2.21.0"
save the json file and import it again in Container -> Action -> import from JSON file

Since Synology UI doesnt let you edit things like that this solved the problem for me because I could rollback to the previous version

@friral commented on GitHub (May 15, 2025): I have a Synology and encountered the same error. To rollback to Version 2.21.0 - which ran fine right before the update - I did the following: 1. Register -> download Image of ABS with label "2.21.0" (careful when selecting the right version, the sorting here is bogus in the UI) 2. Click the container -> export to json (local computer) - open with notepad and find the line "image" : "advplyr/audiobookshelf" and replace with "image" : "advplyr/audiobookshelf:2.21.0" 3. save the json file and import it again in Container -> Action -> import from JSON file Since Synology UI doesnt let you edit things like that this solved the problem for me because I could rollback to the previous version

adam commented

@nichwall commented on GitHub (May 15, 2025):

Using this image worked for me for now. I thought I broke my permissions because I was having issues with a few containers as well.

ghcr.io/advplyr/audiobookshelf:2.20.0

Using the latest gave me the error, using this worked for me. Ironically, it still gives me a little "update" icon.

The latest version is 2.22.0, not 2.20.0

@nichwall commented on GitHub (May 15, 2025): > > Using this image worked for me for now. I thought I broke my permissions because I was having issues with a few containers as well. > > > > [ghcr.io/advplyr/audiobookshelf:2.20.0](ghcr.io/advplyr/audiobookshelf:2.20.0) > > Using the latest gave me the error, using this worked for me. Ironically, it still gives me a little "update" icon. > > ![Image](https://github.com/user-attachments/assets/28d30be5-bf31-46ec-a6dd-1322b0ad70fd) The latest version is `2.22.0`, not `2.20.0`

adam commented

@sbsaylors commented on GitHub (May 16, 2025):

I should've given more info. On ubuntu, coming from 2.21.0

Tried and the result...
ghcr.io/advplyr/audiobookshelf::latest -> Got the error.
ghcr.io/advplyr/audiobookshelf:2.22.0 -> Got the error.
ghcr.io/advplyr/audiobookshelf:2.20.0 -> Was good
ghcr.io/advplyr/audiobookshelf:2.21.0 -> Was good
ghcr.io/advplyr/audiobookshelf:2.22.0 -> Again got the error. Went back to 2.21.0 with success.

@sbsaylors commented on GitHub (May 16, 2025): I should've given more info. On ubuntu, coming from 2.21.0 Tried and the result... ghcr.io/advplyr/audiobookshelf::latest -> Got the error. ghcr.io/advplyr/audiobookshelf:2.22.0 -> Got the error. ghcr.io/advplyr/audiobookshelf:2.20.0 -> Was good ghcr.io/advplyr/audiobookshelf:2.21.0 -> Was good ghcr.io/advplyr/audiobookshelf:2.22.0 -> Again got the error. Went back to 2.21.0 with success.

adam commented

@decaba commented on GitHub (May 16, 2025):

For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone:

Add these lines to your Docker Compose file (using the same indentation as image):
    entrypoint: ["/bin/sh", "-c"]
    command: ["ls && tail -f /dev/null"]
Recreate the container, then remove these lines and recreate the container again. If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together.

Just note that these lines do should not actually solve the problem. I only add thes to stop the Docker container from restarting over and over to get a look at the file system. These just prevent the node command from running and won't start ABS

Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often).

This totally worked for me. I am not using Synology.

@decaba commented on GitHub (May 16, 2025): > For anyone using Portainer (or ofc docker compose), this was resolved by accident when I tried the following with someone: > > Add these lines to your Docker Compose file (using the same indentation as `image`): > > ``` > entrypoint: ["/bin/sh", "-c"] > command: ["ls && tail -f /dev/null"] > ``` > > Recreate the container, then remove these lines and recreate the container again. If you still have the issue after this, please contact me. Hopefully, we can figure out the problem together. > > Just note that these lines ~do~ _should_ not actually solve the problem. I only add thes to stop the Docker container from restarting over and over to get a look at the file system. These just prevent the node command from running and won't start ABS > > Unfortunately, this is not just a Synology issue (although Synology does seem to be affected more often). This totally worked for me. I am not using Synology.

adam commented

@Cotignac commented on GitHub (May 16, 2025):

I'm sorry but I'm not technical enough to find the Docker Compose file.
Can anyone tell me where to find it and be able to add the lines proposed?

@Cotignac commented on GitHub (May 16, 2025): I'm sorry but I'm not technical enough to find the Docker Compose file. Can anyone tell me where to find it and be able to add the lines proposed?

adam commented

@nichwall commented on GitHub (May 16, 2025):

I am using Cosmos Cloud for my docker stuff and got it working by removing all NUSQLITE related env vars as well as changing the working_dir path in its compose file from / to /app.

You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering.

@waschinski sorry I think I misunderstood. Were you saying you removed those paths from your docker compose, or the Dockerfile (which builds the image)? I was thinking the Dockerfile, you would be fine to remove from the compose, my bad.

@nichwall commented on GitHub (May 16, 2025): > > I am using Cosmos Cloud for my docker stuff and got it working by removing all `NUSQLITE` related env vars as well as changing the working_dir path in its compose file from `/` to `/app`. > > You'll want to keep the NUSQLITE variables, that is used for SQLite extensions for sorting and filtering. @waschinski sorry I think I misunderstood. Were you saying you removed those paths from your docker compose, or the Dockerfile (which builds the image)? I was thinking the Dockerfile, you would be fine to remove from the compose, my bad.

adam commented

@waschinski commented on GitHub (May 16, 2025):

@waschinski sorry I think I misunderstood. Were you saying you removed those paths from your docker compose, or the Dockerfile (which builds the image)? I was thinking the Dockerfile, you would be fine to remove from the compose, my bad.

Yeah, just from the compose file.

Cosmos Cloud is basically using an enhanced docker compose file internally (called cosmos compose). I just removed it from there in order to reset it to any defaults. I think it's caching those values in there and it can be one reason to break images with significant changes, similar to Synology etc

Thanks for clearing this up as I was a little confused about the comment to be honest. :)

@waschinski commented on GitHub (May 16, 2025): > @waschinski sorry I think I misunderstood. Were you saying you removed those paths from your docker compose, or the Dockerfile (which builds the image)? I was thinking the Dockerfile, you would be fine to remove from the compose, my bad. Yeah, just from the compose file. Cosmos Cloud is basically using an enhanced docker compose file internally (called cosmos compose). I just removed it from there in order to reset it to any defaults. I think it's caching those values in there and it can be one reason to break images with significant changes, similar to Synology etc Thanks for clearing this up as I was a little confused about the comment to be honest. :)

adam commented

@Vito0912 commented on GitHub (May 16, 2025):

Before adding any new comments, please check if the following descriptions help resolve your issue.

Note

It is important to keep your setup updated. Please do not stay on v2.21.0 because of these issues. If you still experience issues after following these steps, please join the Discord or add a new comment so we can help troubleshoot.

Before trying any of the steps below, make sure you have already recreated or reset your container.

In Portainer, this is called "recreate."
In Synology Container Manager, this is called "reset."

Next, check your Docker Compose file.
It should include the following volumes:

volumes:
  - /any/path:/library
  - /any/path:/config
  - /any/path:/metadata

Here, /any/path can be any path on your system, and /library should be the path defined as your library in ABS. Each path you add should have its own line under volumes.
Note: /config and /metadata are required regardless of how many libraries you have or where they are located.

A library with /audiobooks and /ebooks as library paths should look somewhat like this:

volumes:
  - /any/path:/audiobooks
  - /any/path:/ebooks
  - /any/path:/config
  - /any/path:/metadata

Environment Variables

Important

You can find all supported environment variables here: https://www.audiobookshelf.org/docs/#env-configuration.
Any variable in your Docker Compose file that is not listed there should be removed, as it could cause problems. For example, GUID and UID are not used by ABS and have no effect. Please remove any unnecessary variables and try again. If the issue persists, continue with the next steps.

Curl and Health Checks

If your logs mention issues with curl, you have likely added a custom health check.
If you’re unsure what this means, you may have copied a tutorial. The simple solution:
Remove the healthcheck section from your Compose file. It might look like this:

healthcheck:
  test: ["CMD", "curl", "http://127.0.0.1/healthcheck"]
  interval: 1m
  timeout: 10s
  start_period: 30s

Remove everything including healthcheck until the next same indentation level. The whole section above would be needed to be removed.
If you really need health checks (only necessary if you actively use them), see: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888360553

Issue with `index.js`

This issue often occurs when using a container manager like Synology or Portainer. There are three (or two) simple solutions:

Portainer:
See this solution by Juzif: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888299461
(Accuracy not verified, but linked for reference.)
Synology Container Manager:
See this solution by edoubleoo: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888288664
(Accuracy not verified, but linked for reference.)
General Solution:
Go to your stack, copy the content of your Compose file (starting with services:), delete the stack, and create a new one with the pasted content.
Warning: This will delete all volumes that are not bind mounts. (See the explanation about volumes at the start of this comment.)

Safest Option:
Add the following to your Docker Compose file:

entrypoint: ["/bin/sh", "-c"]
command: ["ls && tail -f /dev/null"]

Example:

Example Docker Compose

services:
  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    # ABS runs on port 13378 by default. To change the port,
    # only change the external port, not the internal port.
    ports:
      - 13378:80
    volumes:
      # These volumes keep your library persistent and allow
      # media to be accessed by the ABS server.
      - ./audiobooks:/audiobooks
      - ./podcasts:/podcasts
      - ./metadata:/metadata
      - ./config:/config
    restart: unless-stopped
    # Optionally, run the container as a specific user:
    # user: 1000:1000
    entrypoint: ["/bin/sh", "-c"]
    command: ["ls && tail -f /dev/null"]

!After recreating the container, simply remove these lines and recreate again. You should now be good to go.!

Caution

Some users have suggested setting the working_dir manually as a fix. This is not recommended and should NOT be done. If the working directory changes in the future, you will encounter the same problem again. While unlikely, it is bad practice, as the working_dir is defined by the Dockerfile/image and should not be set by the user.

You can use the same approach with working_dir as described in Option 4, but it is important to remove it afterwards.

@Vito0912 commented on GitHub (May 16, 2025): Before adding any new comments, please check if the following descriptions help resolve your issue. > [!NOTE] > It is important to keep your setup updated. Please do not stay on v2.21.0 because of these issues. If you still experience issues after following these steps, please join the Discord or add a new comment so we can help troubleshoot. **Before trying any of the steps below, make sure you have already recreated or reset your container.** - In Portainer, this is called "recreate." - In Synology Container Manager, this is called "reset." **Next, check your Docker Compose file.** It should include the following volumes: ```yaml volumes: - /any/path:/library - /any/path:/config - /any/path:/metadata ``` Here, `/any/path` can be any path on your system, and `/library` should be the path defined as your library in ABS. Each path you add should have its own line under `volumes`. **Note:** `/config` and `/metadata` are required regardless of how many libraries you have or where they are located. A library with `/audiobooks` and `/ebooks` as library paths should look somewhat like this: ```yaml volumes: - /any/path:/audiobooks - /any/path:/ebooks - /any/path:/config - /any/path:/metadata ``` --- ### Environment Variables > [!IMPORTANT] > You can find all supported environment variables here: https://www.audiobookshelf.org/docs/#env-configuration. > Any variable in your Docker Compose file that is not listed there should be removed, as it could cause problems. For example, `GUID` and `UID` are not used by ABS and have no effect. Please remove any unnecessary variables and try again. If the issue persists, continue with the next steps. --- ### Curl and Health Checks If your logs mention issues with `curl`, you have likely added a custom health check. If you’re unsure what this means, you may have copied a tutorial. The simple solution: **Remove the healthcheck section from your Compose file.** It might look like this: ```yaml healthcheck: test: ["CMD", "curl", "http://127.0.0.1/healthcheck"] interval: 1m timeout: 10s start_period: 30s ``` Remove everything including `healthcheck` until the next same indentation level. The whole section above would be needed to be removed. If you really need health checks (only necessary if you actively use them), see: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888360553 --- ### Issue with `index.js` This issue often occurs when using a container manager like Synology or Portainer. There are three (or two) simple solutions: 1. **Portainer:** See this solution by Juzif: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888299461 *(Accuracy not verified, but linked for reference.)* 2. **Synology Container Manager:** See this solution by edoubleoo: https://github.com/advplyr/audiobookshelf/issues/4292#issuecomment-2888288664 *(Accuracy not verified, but linked for reference.)* 3. **General Solution:** Go to your stack, copy the content of your Compose file (starting with `services:`), delete the stack, and create a new one with the pasted content. **Warning:** This will delete all volumes that are not bind mounts. (See the explanation about volumes at the start of this comment.) 4. **Safest Option:** Add the following to your Docker Compose file: ```yaml entrypoint: ["/bin/sh", "-c"] command: ["ls && tail -f /dev/null"] ``` Example: <details> <summary>Example Docker Compose</summary> ```yaml services: audiobookshelf: image: ghcr.io/advplyr/audiobookshelf:latest # ABS runs on port 13378 by default. To change the port, # only change the external port, not the internal port. ports: - 13378:80 volumes: # These volumes keep your library persistent and allow # media to be accessed by the ABS server. - ./audiobooks:/audiobooks - ./podcasts:/podcasts - ./metadata:/metadata - ./config:/config restart: unless-stopped # Optionally, run the container as a specific user: # user: 1000:1000 entrypoint: ["/bin/sh", "-c"] command: ["ls && tail -f /dev/null"] ``` </details> !**After recreating the container, simply remove these lines and recreate again. You should now be good to go.**! --- > [!CAUTION] > Some users have suggested setting the `working_dir` manually as a fix. This is **not recommended** and should NOT be done. If the working directory changes in the future, you will encounter the same problem again. While unlikely, it is bad practice, as the `working_dir` is defined by the Dockerfile/image and should not be set by the user. You can use the same approach with `working_dir` as described in Option 4, but it is important to remove it afterwards.

adam commented

@edoubleoo commented on GitHub (May 17, 2025):

For those struggling with this issue within a Synology deployment:

This issue occurs between the previous container and the newly created upgrade container. Once the new container is started, it will not be able to connect to index.js.

To overcome this issue, once the image has been updated within the Synology Container Manager, you will have to STOP and delete the container (DO NOT DELETE ANY LOCAL VOLUMES) and start a new container connected to all local volumes as was previously used.

This issue will be resolved once a new container has been deployed.

@edoubleoo commented on GitHub (May 17, 2025): For those struggling with this issue within a Synology deployment: This issue occurs between the previous container and the newly created upgrade container. Once the new container is started, it will not be able to connect to index.js. To overcome this issue, once the image has been updated within the Synology Container Manager, you will have to **STOP** and delete the container **(*DO NOT DELETE ANY LOCAL VOLUMES*)** and start a new container connected to all local volumes as was previously used. This issue will be resolved once a new container has been deployed.

adam commented

@Juzif commented on GitHub (May 17, 2025):

For those struggling with this issue within a Portainer deployment:

I had this error on Portainer when running Audiobookshelf 2.22.0:

Error: Cannot find module '/index.js'

Following the suggested solution, this issue results from overriding the container’s startup settings. Here’s how to fix it entirely from the Portainer UI—no CLI needed.

1. Revert Command and Entrypoint

Navigate to Advanced container settings → Commands & logging
Click Revert to default on both Command and Entrypoint
Clear Working Dir so it uses the image’s default

2. Verify Volume Mappings

Under Volumes, keep only these binds:

/podcasts → host_path/Podcasts
/audiobooks → host_path/audiobooks
/config → host_path/audiobookshelf/config
/metadata → host_path/Metadata

Remove any mount on /, /app or the container root.

3. Check Environment Variables

In Env, define only:

PORT=80
NODE_ENV=production
CONFIG_PATH=/config
METADATA_PATH=/metadata

Delete extras such as NODE_VERSION or YARN_VERSION.

4. Pull and Redeploy

In Image Configuration, enable Always pull the image
Click Deploy the container

Portainer will fetch a fresh copy and use the built-in index.js. Your Audiobookshelf container should start without errors.

I hope this helps, and thanks. Happy listening! 🎧

@Juzif commented on GitHub (May 17, 2025): For those struggling with this issue within a Portainer deployment: I had this error on Portainer when running Audiobookshelf 2.22.0: Error: Cannot find module '/index.js' Following the suggested solution, this issue results from overriding the container’s startup settings. Here’s how to fix it entirely from the Portainer UI—no CLI needed. ### 1. Revert Command and Entrypoint - Navigate to Advanced container settings → Commands & logging - Click Revert to default on both Command and Entrypoint - Clear Working Dir so it uses the image’s default ### 2. Verify Volume Mappings Under Volumes, keep only these binds: - `/podcasts` → `host_path/Podcasts` - `/audiobooks` → `host_path/audiobooks` - `/config` → `host_path/audiobookshelf/config` - `/metadata` → `host_path/Metadata` Remove any mount on `/`, `/app` or the container root. ### 3. Check Environment Variables In Env, define only: - `PORT=80` - `NODE_ENV=production` - `CONFIG_PATH=/config` - `METADATA_PATH=/metadata` Delete extras such as `NODE_VERSION` or `YARN_VERSION`. ### 4. Pull and Redeploy - In Image Configuration, enable Always pull the image - Click Deploy the container Portainer will fetch a fresh copy and use the built-in `index.js`. Your Audiobookshelf container should start without errors. I hope this helps, and thanks. Happy listening! 🎧

adam commented

@noticons commented on GitHub (May 17, 2025):

For anyone who is unsure how to get wget properly setup, since it uses different flags from curl, here is what I use in my docker-compose for audiobookshelf:

    healthcheck:
        test: ["CMD", "wget", "-qO-", "http://127.0.0.1/healthcheck"]
        interval: 1m
        timeout: 10s
        start_period: 30s

Of course, you may prefer (or need) to have localhost instead of 127.0.0.1. But there you go!

@noticons commented on GitHub (May 17, 2025): For anyone who is unsure how to get `wget` properly setup, since it uses different flags from curl, here is what I use in my docker-compose for audiobookshelf: ``` healthcheck: test: ["CMD", "wget", "-qO-", "http://127.0.0.1/healthcheck"] interval: 1m timeout: 10s start_period: 30s ``` Of course, you may prefer (or need) to have `localhost` instead of `127.0.0.1`. But there you go!

adam commented

@designgears commented on GitHub (May 18, 2025):

This change broke something. I had to change CMD from node index.js to node /app/index.js then it works fine.

@designgears commented on GitHub (May 18, 2025): [This change](https://github.com/advplyr/audiobookshelf/commit/fd0af6b2dddce3f951f5a27da8e9568baaaeb59c) broke something. I had to change CMD from `node index.js` to `node /app/index.js` then it works fine.

adam commented

@advplyr commented on GitHub (May 18, 2025):

I responded to your comment https://github.com/advplyr/audiobookshelf/commit/fd0af6b2dddce3f951f5a27da8e9568baaaeb59c#commitcomment-157328322

Both of those CMD's are valid

@advplyr commented on GitHub (May 18, 2025): I responded to your comment https://github.com/advplyr/audiobookshelf/commit/fd0af6b2dddce3f951f5a27da8e9568baaaeb59c#commitcomment-157328322 Both of those CMD's are valid

adam commented

@designgears commented on GitHub (May 19, 2025):

I responded to your comment fd0af6b#commitcomment-157328322

Both of those CMD's are valid

I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on.

audiobookshelf:
image: advplyr/audiobookshelf:latest
container_name: audiobookshelf
hostname: audiobookshelf
stdin_open: true
tty: true
networks:
- web
environment:
- TZ=America/Denver
- UID=1000
- GID=1000
volumes:
- /mnt/podcasts:/podcasts
- /mnt/abooks:/audiobooks
- /opt/audiobookshelf/config:/config
- /opt/audiobookshelf/metadata:/metadata
working_dir: /
ports:
- "13378:80"
restart: unless-stopped
labels:
- "traefik.docker.network=web"
- "traefik.http.services.audiobookshelf.loadbalancer.server.port=80"
- "traefik.enable=true"
- "traefik.http.routers.audiobookshelf.entrypoints=websecure"
- "traefik.http.routers.audiobookshelf.rule=Host(ab.fqdn.tld)"

Normally when you attach to a container from command line it drops into the working dir, but I get dropped into root now instead of /app.

Furthermore, I can symlink /index.js from /app/index.js and it works fine.

@designgears commented on GitHub (May 19, 2025): > I responded to your comment [fd0af6b#commitcomment-157328322](https://github.com/advplyr/audiobookshelf/commit/fd0af6b2dddce3f951f5a27da8e9568baaaeb59c#commitcomment-157328322) > > Both of those CMD's are valid I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on. > audiobookshelf: image: advplyr/audiobookshelf:latest container_name: audiobookshelf hostname: audiobookshelf stdin_open: true tty: true networks: - web environment: - TZ=America/Denver - UID=1000 - GID=1000 volumes: - /mnt/podcasts:/podcasts - /mnt/abooks:/audiobooks - /opt/audiobookshelf/config:/config - /opt/audiobookshelf/metadata:/metadata working_dir: / ports: - "13378:80" restart: unless-stopped labels: - "traefik.docker.network=web" - "traefik.http.services.audiobookshelf.loadbalancer.server.port=80" - "traefik.enable=true" - "traefik.http.routers.audiobookshelf.entrypoints=websecure" - "traefik.http.routers.audiobookshelf.rule=Host(`ab.fqdn.tld`)" Normally when you attach to a container from command line it drops into the working dir, but I get dropped into root now instead of /app. Furthermore, I can symlink /index.js from /app/index.js and it works fine.

adam commented

@nichwall commented on GitHub (May 19, 2025):

I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on.

Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information.

Edit to add because you have added more information:

audiobookshelf:
image: advplyr/audiobookshelf:latest
environment:
- UID=1000
- GID=1000
working_dir: /

Audiobookshelf has never used the UID or GID environment variables. You can use the user: [uid]:[gid] directive. Is there a reason you are manually specifying the working directory?

@nichwall commented on GitHub (May 19, 2025): > I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on. > Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information. Edit to add because you have added more information: > audiobookshelf: > image: advplyr/audiobookshelf:latest > environment: > - UID=1000 > - GID=1000 > working_dir: / Audiobookshelf has never used the UID or GID environment variables. You can use the `user: [uid]:[gid]` directive. Is there a reason you are manually specifying the working directory?

adam commented

@designgears commented on GitHub (May 19, 2025):

I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on.

Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information.

Im testing this on a completely different server.

@designgears commented on GitHub (May 19, 2025): > > I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on. > > Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information. Im testing this on a completely different server.

adam commented

@designgears commented on GitHub (May 19, 2025):

I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on.

Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information.

Edit to add because you have added more information:

audiobookshelf:
image: advplyr/audiobookshelf:latest
environment:

UID=1000

GID=1000
working_dir: /

Audiobookshelf has never used the UID or GID environment variables. You can use the user: [uid]:[gid] directive. Is there a reason you are manually specifying the working directory?

Yes, I was trying to get it to work, setting it outside and pointing directly to the file got it working for me. UID/GID is my copy/paste fail, most of my docker images come from linuxservers.io and that's something they all do.

@designgears commented on GitHub (May 19, 2025): > > I deploy with a docker-compose.yml file from command line. I have been deploying it like this for at least a year now. I can trace the problem back to that commit I commented on. > > Yes, that commit changed how the docker image is built. Make sure you have fully removed any existing Audiobookshelf containers and images, then upgrade to ensure you are pulling a new image. You can read the above comments to get more information. > > Edit to add because you have added more information: > > > audiobookshelf: > > image: advplyr/audiobookshelf:latest > > environment: > > - UID=1000 > > - GID=1000 > > working_dir: / > > Audiobookshelf has never used the UID or GID environment variables. You can use the `user: [uid]:[gid]` directive. Is there a reason you are manually specifying the working directory? Yes, I was trying to get it to work, setting it outside and pointing directly to the file got it working for me. UID/GID is my copy/paste fail, most of my docker images come from linuxservers.io and that's something they all do.

adam commented

@advplyr commented on GitHub (May 19, 2025):

Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

@advplyr commented on GitHub (May 19, 2025): Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

adam commented

@designgears commented on GitHub (May 19, 2025):

Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

I was trying to get it to work, setting it outside and pointing directly to the file got it working for me.

@designgears commented on GitHub (May 19, 2025): > Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app. > I was trying to get it to work, setting it outside and pointing directly to the file got it working for me.

adam commented

@designgears commented on GitHub (May 19, 2025):

Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

I was trying to get it to work, setting it outside and pointing directly to the file got it working for me.

In the end I blew everything away, and setup fresh and it worked as intended without the workarounds. Not sure why it wasn't working before.

@designgears commented on GitHub (May 19, 2025): > > Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app. > > > I was trying to get it to work, setting it outside and pointing directly to the file got it working for me. In the end I blew everything away, and setup fresh and it worked as intended without the workarounds. Not sure why it wasn't working before.

adam commented

@nichwall commented on GitHub (May 19, 2025):

Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

I was trying to get it to work, setting it outside and pointing directly to the file got it working for me.

It still sounds like you are using a cached version of the image or container. Please make sure you have fully removed all of the local Audiobookshelf images and containers. You can also try manually specifying the version number instead of :latest.

@nichwall commented on GitHub (May 19, 2025): > > Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app. > > > I was trying to get it to work, setting it outside and pointing directly to the file got it working for me. It still sounds like you are using a cached version of the image or container. Please make sure you have fully removed all of the local Audiobookshelf images and containers. You can also try manually specifying the version number instead of `:latest`.

adam commented

@designgears commented on GitHub (May 19, 2025):

Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app.

I was trying to get it to work, setting it outside and pointing directly to the file got it working for me.

It still sounds like you are using a cached version of the image or container. Please make sure you have fully removed all of the local Audiobookshelf images and containers. You can also try manually specifying the version number instead of :latest.

I was manually starting the containers while testing with 4 different version, manually specifying the version, the 3 most recent releases and my own compiled version.

@designgears commented on GitHub (May 19, 2025): > > > Ah yeah if you are overriding the working dir like that then the CMD won't work because the CMD is for if the working dir is /app. > > > > > > > I was trying to get it to work, setting it outside and pointing directly to the file got it working for me. > > It still sounds like you are using a cached version of the image or container. Please make sure you have fully removed all of the local Audiobookshelf images and containers. You can also try manually specifying the version number instead of `:latest`. I was manually starting the containers while testing with 4 different version, manually specifying the version, the 3 most recent releases and my own compiled version.

adam commented

@postnick commented on GitHub (May 20, 2025):

I'm on Portioner - I have a Custom Stack - I keep my config in a NFS Drive but you all could just backup your config.

I deleted my whole stack and made a new stack and it is working fine on 2.23.0 now using the :Latest tag.

I do see the image is half the size of before but it seems to be working fine for now.

So Solution - Docker is like Cattle, Kill it and grow a new one.

@postnick commented on GitHub (May 20, 2025): I'm on Portioner - I have a Custom Stack - I keep my config in a NFS Drive but you all could just backup your config. I deleted my whole stack and made a new stack and it is working fine on 2.23.0 now using the :Latest tag. I do see the image is half the size of before but it seems to be working fine for now. So Solution - Docker is like Cattle, Kill it and grow a new one.

adam commented

@advplyr commented on GitHub (May 20, 2025):

I do see the image is half the size of before but it seems to be working fine for now.

That is the improvement that was made to the Dockerfile

@advplyr commented on GitHub (May 20, 2025): > I do see the image is half the size of before but it seems to be working fine for now. That is the improvement that was made to the Dockerfile

adam commented

@designgears commented on GitHub (May 21, 2025):

I'm on Portioner - I have a Custom Stack - I keep my config in a NFS Drive but you all could just backup your config.

I deleted my whole stack and made a new stack and it is working fine on 2.23.0 now using the :Latest tag.

I do see the image is half the size of before but it seems to be working fine for now.

So Solution - Docker is like Cattle, Kill it and grow a new one.

I have my data mounted to another drive as well, it still took blowing away the data directory and pulling the new image to get things working oob like it should. Not sure why that is, but works now.

@designgears commented on GitHub (May 21, 2025): > I'm on Portioner - I have a Custom Stack - I keep my config in a NFS Drive but you all could just backup your config. > > I deleted my whole stack and made a new stack and it is working fine on 2.23.0 now using the :Latest tag. > > I do see the image is half the size of before but it seems to be working fine for now. > > So Solution - Docker is like Cattle, Kill it and grow a new one. I have my data mounted to another drive as well, it still took blowing away the data directory and pulling the new image to get things working oob like it should. Not sure why that is, but works now.

adam commented

@000al000 commented on GitHub (May 21, 2025):

Change the working directory to /app, so node index.js resolves correctly

@000al000 commented on GitHub (May 21, 2025): Change the working directory to /app, so node index.js resolves correctly

adam commented

@designgears commented on GitHub (May 23, 2025):

Change the working directory to /app, so node index.js resolves correctly

another person not reading, nice.

@designgears commented on GitHub (May 23, 2025): > Change the working directory to /app, so node index.js resolves correctly another person not reading, nice.

adam commented