After restarting host server - content appears to be gone?

[BaiMaKe]

Attempted Debugging

• I have read the debugging page

Searched GitHub Issues

• I have searched GitHub for the issue.

Describe the Scenario

Problem: After rebooting the NAS that hosts this, all data and configuration appears to have disappeared. E.g. the user accounts that I had created are gone and I am back to default login of admin@admin.com and password. After logging in all my books are gone. I am not receiving any errors from bookstack.

Troubleshooting:
Following steps at https://www.bookstackapp.com/docs/admin/debugging/

laravel.log appears when use ls in bash. Attempting to use nano to open it has nano believe it is creating a new file. Laravel.log shows up at /app/www/storage/logs and the use of ls -la indicates a ?symlink? to /config/log/bookstack/laravel.log

Permissions on this laravel.log are lrwxrwxrwx (I was logged into the docker container as root)

Traversing to the linked location shows it as being empty.

I did not find error logs for apache or nginx.

I have tried restarting the entire stack as well as independently restarting the container for mariadb and bookstack. When independently restarting I've tried ensuring the mariadb is up first and then launching bookstack. The issue persists.

Here is the docker compose file I'm using

# These containers are maintained by the linuxserver.io
# team, not the official BookStack project.

# For non-commented options, refer to the linuxserver documentation: 
# https://docs.linuxserver.io/images/docker-bookstack/#environment-variables-e

services:

  # The container for BookStack itself
  bookstack:
    # You should update the version here to match the latest
    # release of BookStack: https://github.com/BookStackApp/BookStack/releases
    # You'll change this when wanting to update the version of BookStack used.
    image: lscr.io/linuxserver/bookstack:version-v25.07.2
    container_name: bookstack
    environment:
      - PUID=999
      - PGID=999
      - TZ=Etc/UTC
      # APP_URL must be set as the base URL you'd expect to access BookStack
      # on via the browser. The default shown here is what you might use if accessing
      # direct from the browser on the docker host, hence the use of the port as configured below.
      - APP_URL=http://portainer.redacteddomain.space:6875
      # APP_KEY must be a unique key. Generate your own by running
      # docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkey
      # You should keep the "base64:" part for the option value.
      - APP_KEY=base64:redacted

      # The below database details are purposefully aligned with those
      # configuted for the "mariadb" service below:
      - DB_HOST=mariadb
      - DB_PORT=3306
      - DB_DATABASE=bookstack
      - DB_USERNAME=bookstackredacteduser
      - DB_PASSWORD=redactedpassword
    volumes:
      # You generally only ever need to map this one volume.
      # This maps it to a "bookstack_app_data" folder in the same
      # directory as this compose config file.
      - ./bookstack_app_data:/config
    ports:
      # This exposes port 6875 for general web access.
      # Commonly you'd have a reverse proxy in front of this,
      # redirecting incoming requests to this port.
      - 6875:80
    restart: unless-stopped

  # The container for the database which BookStack will use to store
  # most of its core data/content.
  mariadb:
    # You should update the version here to match the latest
    # main version of the linuxserver mariadb container version:
    # https://github.com/linuxserver/docker-mariadb/pkgs/container/mariadb/versions?filters%5Bversion_type%5D=tagged
    image: lscr.io/linuxserver/mariadb:11.4.4
    container_name: mariadb
    environment:
      - PUID=999
      - PGID=999
      - TZ=MST7MDT
      # You may want to change the credentials used below,
      # but be aware the latter three options need to align
      # with the DB_* options for the BookStack container.
      - MYSQL_ROOT_PASSWORD=redacted
      - MYSQL_DATABASE=bookstack
      - MYSQL_USER=bookstackredacteduser
      - MYSQL_PASSWORD=redactedpassword
    volumes:
      # You generally only ever need to map this one volume.
      # This maps it to a "bookstack_db_data" folder in the same
      # directory as this compose config file.
      - ./bookstack_db_data:/config

    # These ports are commented out as you don't really need this port
    # exposed for normal use, mainly only if connecting direct the the
    # database externally. Otherwise, this risks exposing access to the
    # database when not needed.
    # ports:
    #   - 3306:3306
    restart: unless-stopped

I'm unsure as to where to go from here. My next step will be trying to load the database and see if any data is inside or if there may have been a permissions error that was blocking use. I feel that would be odd as both my wife and I were using bookstacks quite successfully up until this issue hit.

I'll update if I can get the above checked, I'm not a database guru so have a fair amount of searching ahead of me.

Appreciate any help/guidance folks have and am hoping this is a PEBKAC issue rather than a lost database.

Exact BookStack Version

v25.07.02

Log Content

Unable to find existent logs.

Hosting Environment

Asustor NAS (ADM version 5.0.1.RKD2), using NGINX-proxy-manager to enable SSL connections across to bookstack which is reachable on my LAN via subdomain (books.mydomain.tld). Bookstack deployed via docker compose file as cited above.

[ssddanbrown]

Hi @BaiMaKe,
Just to confirm, are you using portainer? (I see it referenced in one of the URLs)
If so, can you check if you have any volumes are shown for this stack (or the containers in use) within portainer?

The compose stack above shows relative path volumes used, but I'm not familiar enough with portainer to know how these are translated.

As with anything docker container based, any data within containers can be (and is intended to be) destroyed at any time so we just need to check specifically how volumes were configured in this scenario since that's where any persistent data would be stored.

[BaiMaKe]

@ssddanbrown Thank you so much. You are correct in that I am using portainer. While my other containers I've deployed through it created persistant storage locations the compose file I'm using here did not. Based on your feedback I confirmed that just a moment ago by rebooting the NAS and seeing the database get wiped again.

It's a slow start on my self hosting journey but now I know what the problem is and can research the correct changes to the compose file. Thank you very much!