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]: Backup from Ubuntu install crashes when restored on docker image due to path not existing #2823

New Issue
Closed
opened 2026-04-25 00:10:57 +02:00 by adam · 6 comments
adam commented 2026-04-25 00:10:57 +02:00
Owner
Copy Link
Copy Source

Originally created by @bigcat on GitHub (Jun 4, 2025).

What happened?

When I was migrating my library from my Ubuntu server to my new TrueNas instance, I took a backup, and restored it on the new machine.

The issue is that the backup path on ubuntu - /usr/share/audiobookshelf/backups didn't exist in the docker image.

This caused the server to crash and the docker container to continuously restart.

I fixed it by editing the SQLite backup in the settings table to be the default path in the docker image.

What did you expect to happen?

I'm not sure if this exactly a bug or a feature request - but my suggestion is to make this a non-failure case, and more of an alert/alarm in the UI and allowing someone to fix it instead from the UI.

Steps to reproduce the issue

  1. take a backup from an existing install on a Linux machine (possibly others)
  2. restore on a docker instance
  3. Docker instance crashes

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?

None

Logs

Additional Notes

No response

Originally created by @bigcat on GitHub (Jun 4, 2025). ### What happened? When I was migrating my library from my Ubuntu server to my new TrueNas instance, I took a backup, and restored it on the new machine. The issue is that the backup path on ubuntu - `/usr/share/audiobookshelf/backups` didn't exist in the docker image. This caused the server to crash and the docker container to continuously restart. I fixed it by editing the SQLite backup in the settings table to be the default path in the docker image. ### What did you expect to happen? I'm not sure if this exactly a bug or a feature request - but my suggestion is to make this a non-failure case, and more of an alert/alarm in the UI and allowing someone to fix it instead from the UI. ### Steps to reproduce the issue 1. take a backup from an existing install on a Linux machine (possibly others) 2. restore on a docker instance 3. Docker instance crashes ### 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? None ### Logs ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:10:57 +02:00
adam closed this issue 2026-04-25 00:10:57 +02:00
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jun 4, 2025):

As far as I know, this should be a feature request.
Currently, the backup only creates a copy of the server as it is. Unfortunately, ABS does not support changes to metadata or library paths without manual work.

@Vito0912 commented on GitHub (Jun 4, 2025): As far as I know, this should be a feature request. Currently, the backup only creates a copy of the server as it is. Unfortunately, ABS does not support changes to metadata or library paths without manual work.
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jun 4, 2025):

Yeah, migrating between install methods is not supported. You will need to manually edit the database for the new paths, or set up your docker mounts to mimic the original base path from when you were running on Ubuntu.

@nichwall commented on GitHub (Jun 4, 2025): Yeah, migrating between install methods is not supported. You will need to manually edit the database for the new paths, or set up your docker mounts to mimic the original base path from when you were running on Ubuntu.
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@Timo-1979 commented on GitHub (Jul 7, 2025):

IMHO it’s a bug -> There should be some error handling. System-Crash should always handled as a bug.

The system should not break, just because of wrong data in the database.

Possible solution: Create a error-page displaying a meaningful error-message (show which path doesn’t exist or the permission ist not correct) and do not allow to login to the system.

Maybe it would great to have a manual how to modify the internal database.

@Timo-1979 commented on GitHub (Jul 7, 2025): IMHO it’s a bug -> There should be some error handling. System-Crash should always handled as a bug. The system should not break, just because of wrong data in the database. Possible solution: Create a error-page displaying a meaningful error-message (show which path doesn’t exist or the permission ist not correct) and do not allow to login to the system. Maybe it would great to have a manual how to modify the internal database.
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Jul 7, 2025):

You do something not supported by the software thus there is no support to handle this.

I don't say there shouldn't be an error handler for such cases, but this analogy does not work for things a software is not intended to do. The crash tells you that you did something the software did not encounter for. And that's correct for this case.

Imho ABS shouldn't even let you load a backup if it's from another install method (or at least show many warnings) though

@Vito0912 commented on GitHub (Jul 7, 2025): You do something not supported by the software thus there is no support to handle this. I don't say there shouldn't be an error handler for such cases, but this analogy does not work for things a software is not intended to do. The crash tells you that you did something the software did not encounter for. And that's correct for this case. Imho ABS shouldn't even let you load a backup if it's from another install method (or at least show many warnings) though
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@Timo-1979 commented on GitHub (Jul 7, 2025):

It ABS blocks loading the backup and give you out the warnings/errors in the logs - than you’ve got something like an error-handling.

But what happens, when you restore form a backup (same deployment-model) and you’ve done a bug in the path (permissions and/or typo) than you would like to see a meaning-full error-message and not run into system-crash.

@Timo-1979 commented on GitHub (Jul 7, 2025): It ABS blocks loading the backup and give you out the warnings/errors in the logs - than you’ve got something like an error-handling. But what happens, when you restore form a backup (same deployment-model) and you’ve done a bug in the path (permissions and/or typo) than you would like to see a meaning-full error-message and not run into system-crash.
adam commented 2026-04-25 00:10:58 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jul 7, 2025):

But what happens, when you restore form a backup (same deployment-model) and you’ve done a bug in the path (permissions and/or typo) than you would like to see a meaning-full error-message and not run into system-crash.

The logs include the crash report. If you have restored from a backup and there is a permissions issue (such as in the config or metadata folders), the server should not continue running, similar to a permissions issues during initial setup.

There can be additional error handling before restoring the backup, but if the server cannot function anyway, it is very obvious something is wrong if it crashes and prints out the crash in the log.

@nichwall commented on GitHub (Jul 7, 2025): > But what happens, when you restore form a backup (same deployment-model) and you’ve done a bug in the path (permissions and/or typo) than you would like to see a meaning-full error-message and not run into system-crash. > The logs include the crash report. If you have restored from a backup and there is a permissions issue (such as in the config or metadata folders), the server should not continue running, similar to a permissions issues during initial setup. There can be additional error handling before restoring the backup, but if the server cannot function anyway, it is very obvious something is wrong if it crashes and prints out the crash in the log.
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#2823
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?