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

Critical: Complete database loss/reset - All data wiped during container restart #2991

New Issue
Closed
opened 2026-04-25 00:12:47 +02:00 by adam · 3 comments
adam commented 2026-04-25 00:12:47 +02:00
Owner
Copy Link
Copy Source

Originally created by @YKK741953 on GitHub (Sep 6, 2025).

Critical Database Loss Issue - Complete Data Wipeout

Summary

Audiobookshelf Docker container performed a complete database reset/initialization, resulting in total loss of:

  • All user accounts and authentication
  • All libraries and media items
  • All playlists (60+ season-based playlists with 656 episodes)
  • All settings and configurations

Environment

  • OS: Ubuntu 20.04 (Linux 6.8.0-79-generic)
  • Docker: 28.3.3, build 980b856
  • Audiobookshelf: ghcr.io/advplyr/audiobookshelf:latest
  • Container name: audiobookshelf
  • Mount: Docker Compose with proper volume mounts

Timeline

  • Before: System was working normally with 60+ playlists, full podcast library
  • 11:53 JST 2025-09-06: Container restart occurred
  • After: Complete database reset, "server is not initialized" error in mobile app

Evidence

1. Log Messages Indicating Fresh Database

[2025-09-06 11:53:47.838] INFO: [MigrationManager] Database is new. Skipping migrations.
[2025-09-06 11:53:50.396] INFO: [TokenManager] JWT secret key not found, generating one

2. Database File Information

$ ls -la config/absdatabase.sqlite
-rw-r--r-- 1 root root 356352 Sep  6 11:53 config/absdatabase.sqlite
  • File timestamp matches container restart time
  • Root ownership (potentially problematic)

3. Empty Backup Directory

$ ls -la metadata/backups/
total 8
drwxr-xr-x 2 root   root   4096 Sep  6 11:53 .
drwxr-xr-x 7 yuki02 yuki02 4096 Sep  6 11:53 ..

4. Docker Configuration

services:
  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    container_name: audiobookshelf
    ports:
      - "13378:80"
    environment:
      - TZ=Asia/Tokyo
    volumes:
      - ./config:/config
      - ./metadata:/metadata
      - ./audiobooks:/audiobooks
      - ./podcasts:/podcasts
    restart: unless-stopped

5. Container Mount Verification

All mounts are correctly configured and accessible.

Impact

This is a critical data loss affecting production usage:

  • Loss of 656 podcast episodes organized into season-based playlists
  • Loss of all user authentication and settings
  • Complete service disruption requiring full re-setup

Potential Causes

  1. Permission Issues: Database file created as root:root instead of proper user
  2. Database Corruption: SQLite file became unreadable
  3. Container Initialization Bug: Improper database detection during startup
  4. Volume Mount Issues: Database file not properly preserved

Questions

  1. What conditions cause Audiobookshelf to skip database migration and initialize fresh?
  2. Why was existing database not detected/used?
  3. Are there better backup strategies to prevent this?
  4. Should database files be created with different ownership/permissions?

Request

  • Investigation into what triggers fresh database initialization
  • Guidance on preventing similar data loss
  • Recommendations for backup/recovery strategies
  • Fix for permission handling if relevant

System Details

  • Container uptime: 19 hours ago created, restarted recently
  • File system: Standard Linux ext4
  • Docker storage: Default storage driver
  • Logs: Available for further analysis

This represents a catastrophic failure for a production system with significant organized content.

Originally created by @YKK741953 on GitHub (Sep 6, 2025). # Critical Database Loss Issue - Complete Data Wipeout ## Summary Audiobookshelf Docker container performed a complete database reset/initialization, resulting in total loss of: - All user accounts and authentication - All libraries and media items - All playlists (60+ season-based playlists with 656 episodes) - All settings and configurations ## Environment - **OS**: Ubuntu 20.04 (Linux 6.8.0-79-generic) - **Docker**: 28.3.3, build 980b856 - **Audiobookshelf**: ghcr.io/advplyr/audiobookshelf:latest - **Container name**: audiobookshelf - **Mount**: Docker Compose with proper volume mounts ## Timeline - **Before**: System was working normally with 60+ playlists, full podcast library - **11:53 JST 2025-09-06**: Container restart occurred - **After**: Complete database reset, "server is not initialized" error in mobile app ## Evidence ### 1. Log Messages Indicating Fresh Database ``` [2025-09-06 11:53:47.838] INFO: [MigrationManager] Database is new. Skipping migrations. [2025-09-06 11:53:50.396] INFO: [TokenManager] JWT secret key not found, generating one ``` ### 2. Database File Information ```bash $ ls -la config/absdatabase.sqlite -rw-r--r-- 1 root root 356352 Sep 6 11:53 config/absdatabase.sqlite ``` - File timestamp matches container restart time - Root ownership (potentially problematic) ### 3. Empty Backup Directory ```bash $ ls -la metadata/backups/ total 8 drwxr-xr-x 2 root root 4096 Sep 6 11:53 . drwxr-xr-x 7 yuki02 yuki02 4096 Sep 6 11:53 .. ``` ### 4. Docker Configuration ```yaml services: audiobookshelf: image: ghcr.io/advplyr/audiobookshelf:latest container_name: audiobookshelf ports: - "13378:80" environment: - TZ=Asia/Tokyo volumes: - ./config:/config - ./metadata:/metadata - ./audiobooks:/audiobooks - ./podcasts:/podcasts restart: unless-stopped ``` ### 5. Container Mount Verification All mounts are correctly configured and accessible. ## Impact This is a **critical data loss** affecting production usage: - Loss of 656 podcast episodes organized into season-based playlists - Loss of all user authentication and settings - Complete service disruption requiring full re-setup ## Potential Causes 1. **Permission Issues**: Database file created as root:root instead of proper user 2. **Database Corruption**: SQLite file became unreadable 3. **Container Initialization Bug**: Improper database detection during startup 4. **Volume Mount Issues**: Database file not properly preserved ## Questions 1. What conditions cause Audiobookshelf to skip database migration and initialize fresh? 2. Why was existing database not detected/used? 3. Are there better backup strategies to prevent this? 4. Should database files be created with different ownership/permissions? ## Request - Investigation into what triggers fresh database initialization - Guidance on preventing similar data loss - Recommendations for backup/recovery strategies - Fix for permission handling if relevant ## System Details - **Container uptime**: 19 hours ago created, restarted recently - **File system**: Standard Linux ext4 - **Docker storage**: Default storage driver - **Logs**: Available for further analysis This represents a catastrophic failure for a production system with significant organized content.
adam closed this issue 2026-04-25 00:12:47 +02:00
adam commented 2026-04-25 00:12:47 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Sep 6, 2025):

Are you sure the mount points are correct? Your compose looks correct, but have you checked whether the data exists in your file system? Did you start your container from the same directory?

Edit to add: every time something like this is reported, it is because mount points or container was set up incorrectly. This is usually because the mount points were not set up (so data was not persisted outside of the container) or there is a path issue (such as using the wrong relative directory or a temporary location).

@nichwall commented on GitHub (Sep 6, 2025): Are you sure the mount points are correct? Your compose looks correct, but have you checked whether the data exists in your file system? Did you start your container from the same directory? Edit to add: every time something like this is reported, it is because mount points or container was set up incorrectly. This is usually because the mount points were not set up (so data was not persisted outside of the container) or there is a path issue (such as using the wrong relative directory or a temporary location).
adam commented 2026-04-25 00:12:47 +02:00
Author
Owner
Copy Link
Copy Source

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

Can you please provide more meaningful (non AI generated) information about the state of ABS and how this happens?

  • So which version did you use when this happened?
  • Does this happen on a restarted or recreation (big difference)?
  • Can you reproduce this every time? If yes, can you please provide how you restart/recreate the container
  • Can you see the file in the config directory if you start ABS. The config is folder should be located in the same directory as the docker compose file.

Also a hint. If you changed your docker compose files (and it had the wrong mount points) you need to recreate the container to take effect

@Vito0912 commented on GitHub (Sep 6, 2025): Can you please provide more meaningful (non AI generated) information about the state of ABS and how this happens? - So which version did you use when this happened? - Does this happen on a restarted or recreation (big difference)? - Can you reproduce this every time? If yes, can you please provide how you restart/recreate the container - Can you see the file in the config directory if you start ABS. The config is folder should be located in the same directory as the docker compose file. Also a hint. If you changed your docker compose files (and it had the wrong mount points) you need to recreate the container to take effect
adam commented 2026-04-25 00:12:47 +02:00
Author
Owner
Copy Link
Copy Source

@YKK741953 commented on GitHub (Sep 6, 2025):

Sorry, this issue was opened by mistake.
After reconfiguration everything is working fine now.
Closing this issue.

@YKK741953 commented on GitHub (Sep 6, 2025): Sorry, this issue was opened by mistake. After reconfiguration everything is working fine now. Closing this issue.
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
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#2991
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?