mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-03-02 22:46:55 -05:00
[Bug]: Audiobookshelf doesn't work after reboot until manually shutting down and starting up container again #2781
Labels
No labels
authentication
awaiting release
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/audiobookshelf-advplyr#2781
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @syriaz on GitHub (May 18, 2025).
What happened?
Installed audiobookshelf via docker compose. Then visited the URL at localhost:13378/audiobookshelf and set up the user and libraries. It worked fine.
Now after I reboot the raspberry pi 4b+ (arm64) with headless ubuntu 24.04, the container shows to be running. but for some reason the web UI loads endlessly and is not accessible.
The files are on an attached hard drive. Only if I do "docker compose down; docker compose up -d" it starts working again.
What did you expect to happen?
I expected audiobookshelf to actually work even after I reboot the raspberry pi 4b+ running headless ubuntu 24.04.
Steps to reproduce the issue
Audiobookshelf version
2.23.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?
Chrome
Logs
Additional Notes
I have tried delaying the docker containers start up in multiple ways, because I thought my attached hard drive wasn't ready when the container starts but that didn't fix the problem.
@Vito0912 commented on GitHub (May 18, 2025):
Does it load in your browser, or do you see a spinning indicator?
@syriaz commented on GitHub (May 18, 2025):
No, it tries to load the address for 30 seconds and then says the MYIP doesnt support a secure connection and "You are seeing this warning because this site does not support HTTPS and you are in Private mode." All of which is fine by me. I click "Continue to Site" and then it says "This site can’t be reached: MYIP took too long to respond".
@nichwall commented on GitHub (May 18, 2025):
Is that the log from after booting or restarting the docker container? Are you trying to access it over https without a reverse proxy?
@syriaz commented on GitHub (May 18, 2025):
It's from after rebooting the raspberry pi. I just type in my IP without https and yes, I dont have a reverse proxy (which I want to keep that way).
@Vito0912 commented on GitHub (May 18, 2025):
As nichwall said, you have to use http if you don't use a reverse proxy.
If you use a proxy make sure you add the certificate
@syriaz commented on GitHub (May 18, 2025):
I am using http://MYIP:13378/audiobookshelf.
Within 10 seconds of visiting the URL it still shows me:
This site can’t be reached. MYIP took too long to respond.
Try:
Checking the connection
ERR_CONNECTION_TIMED_OUT
@nichwall commented on GitHub (May 18, 2025):
This means you are trying to connect over https.
Is this your local IP or your public IP?
@syriaz commented on GitHub (May 18, 2025):
Before I just typed in MYIP without the http:// part. And then I tried it with http:// as well. Both are not working.
Its my public ip.
@frauhottelmann commented on GitHub (Jul 3, 2025):
I have the same problem.
I am on a AMD 5600G with docker compose.
After a reboot the container is started:
But the container is stopped at that point. I have to restart the compose stack. Then it's working indefinately.
Any way to debug this further?
@nichwall commented on GitHub (Jul 3, 2025):
Can you enable Debug logs? What happens when it stops responding, like were you actively using it or just letting it sit? If you were using ABS when it froze, what were you doing?
@frauhottelmann commented on GitHub (Jul 4, 2025):
I wasn't using it actively at the time of reboot.
Of course now it's not happening when I reboot. I have one suspicion: I usually only reboot after updates and at least last time it happens there was a docker engine update before the reboot. I'll try to capture logs next time I update docker.
@advplyr commented on GitHub (Jul 8, 2025):
Is this issue resolved?
@syriaz commented on GitHub (Jul 9, 2025):
No, this is still happening as described
@frauhottelmann commented on GitHub (Jul 9, 2025):
If it's still happening to you: can you enable debug logs?
@syriaz commented on GitHub (Jul 9, 2025):
Yes. As you can see there's an error the first time a book is being requested. And then I run "docker compose down" and "docker compose up -d" and then it works.
@nichwall commented on GitHub (Jul 9, 2025):
Your file system may not be available/mounted before the docker container starts when booting the raspberry pi. The file system needs to be ready before the docker container starts, or else the files don't exist in the container. This can happen with external drives.
This also explains why manually restarting the container after booting fixes the problem.
@syriaz commented on GitHub (Jul 9, 2025):
Do you know how to set this up with an external hdd so the mounted hdd is available before the docker container starts?
@nichwall commented on GitHub (Jul 9, 2025):
You can look at systemd rules to prevent docker from starting before all filesystems are mounted.
@syriaz commented on GitHub (Jul 10, 2025):
I tried multiple ways of systemd solutions with the help of chatgpt but it still does not work.
@nichwall commented on GitHub (Jul 10, 2025):
What have you tried?
@syriaz commented on GitHub (Jul 10, 2025):
Lots of systemd stuff to delay the docker container at reboot and even etc/fstab edits. Does it matter if the hdd is formatted as exfat?
@advplyr commented on GitHub (Jul 21, 2025):
Did you resolve this?
@syriaz commented on GitHub (Jul 21, 2025):
No since I dont know the exact steps to delay the container
@mhofer2011 commented on GitHub (Feb 15, 2026):
I had the same problem: Pi 4B, mounted partition of a SSD (exfat) besides the system file system.
I found the solution here:
https://davejansen.com/systemctl-delay-start-docker-service-until-mounts-available/
By adding the mount point after the next reboot everything worked as expected!