shiori: Docker image cannot be used with SQLite in a mounted volume

Data

  • Shiori version: latest docker image (1.5.3)
  • Database Engine: SQLite
  • Operating system: N/A
  • CLI/Web interface/Web Extension: N/A

Describe the bug / actual behavior

If you run the Docker image with /shiori as mounted volume the shiori process cannot write the database. It crashes with “out of memory” (see stacktrace below).

Expected behavior

Shiori with SQLite can be used with a mounted volume (running without mounted volume doesn’t make sense for production deployment).

To Reproduce

Create a compose.yaml

services:
  shiori:
    container_name: shiori
    image: "ghcr.io/go-shiori/shiori"
    restart: unless-stopped
    volumes:
      - ./data:/shiori  
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 8080:8080

Running docker compose up results in:

shiori  | panic: unable to open database file: out of memory (14)
shiori  |
shiori  | goroutine 1 [running]:
shiori  | github.com/jmoiron/sqlx.MustConnect(...)
shiori  |       /home/runner/go/pkg/mod/github.com/jmoiron/sqlx@v1.3.5/sqlx.go:654
shiori  | github.com/go-shiori/shiori/internal/database.OpenSQLiteDatabase({0xc0000ca438, 0x15fc350})
shiori  |       /home/runner/work/shiori/shiori/internal/database/sqlite.go:27 +0xaa
shiori  | github.com/go-shiori/shiori/internal/cmd.openSQLiteDatabase()
shiori  |       /home/runner/work/shiori/shiori/internal/cmd/root.go:117 +0x6a
shiori  | github.com/go-shiori/shiori/internal/cmd.openDatabase()
shiori  |       /home/runner/work/shiori/shiori/internal/cmd/root.go:111 +0x79
shiori  | github.com/go-shiori/shiori/internal/cmd.preRunRootHandler(0xc00021cc80, {0xbbd9a8, 0x0, 0x0})
shiori  |       /home/runner/work/shiori/shiori/internal/cmd/root.go:64 +0x116
shiori  | github.com/spf13/cobra.(*Command).execute(0xc00021cc80, {0x15fbd98, 0x0, 0x0})
shiori  |       /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:840 +0x50a
shiori  | github.com/spf13/cobra.(*Command).ExecuteC(0xc0001a3400)
shiori  |       /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:974 +0x3bc
shiori  | github.com/spf13/cobra.(*Command).Execute(...)
shiori  |       /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:902
shiori  | main.main()
shiori  |       /home/runner/work/shiori/shiori/main.go:19 +0x1e

Notes

This is probably a permission issue. I don’t think you should create an extra user in a Docker container to run an application in default use cases (disclaimer: no Docker expert here, I’m just guessing). Just run mkdir /shiori instead of addgroup/adduser probably fixes this issue.

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 7
  • Comments: 21 (4 by maintainers)

Most upvoted comments

I had the same error and I fixed it by creating the local directory and then set the correct permissions expected by shiori.

mkdir ./shiori-data
chown -R 1000:1000 ./shiori-data

Figured out my problem. It is a Synology NAS specific issue. The fix was to create a specific non-root user with access to the mount directory ala https://drfrankenstein.co.uk/step-2-setting-up-a-restricted-docker-user-and-obtaining-ids/ and then use that user with Docker Compose. The Synology “Container Manager” app is basically Synology’s Portainer, and it can run docker compose yaml files.

version: '3.3'
services:
  shiori:
    image: ghcr.io/go-shiori/shiori
    container_name: shiori
    user: UID:GID   // this is the important part; set the user and group that have access to  /volume2/docker/shiori
    ports:
      - 8080:8080
    restart: unless-stopped
    volumes:
      - /volume2/docker/shiori:/shiori           
      // note you have to specify the the "real" path on host not the nice Synology share name

It seemed like most suggestions on the internet were to make user and group that the docker image wants on the host OS, which is easy to do on Linux systems, but not on the Synology.

The catch is that it seems like only compose and the yaml file approach can set the user and group id, not the “docker” command line or simple docker run UIs in the Synology.

The one nice thing that Shiroi could do is take UID and PID to use as environment variables, that way it could be run w/out compose.

A workaround is to create the “data” directory before running docker. It is only broken if the data directory is created by docker / the container.

The documented docker run from Usage.md works because there is no subdirectory involved.

I was using the following tutorial for deploying shiori: https://noted.lol/tutorial-setting-up-shiori. The docker-compose file in this tutorial changes the shiori data dir with an environment variable to SHIORI_DIR=/data and creates a volume for /data. Using the same docker-compose file gave me the Failed to open database: unable to open database file: out of memory (14) error.

version: "3"
services:
  shiori:
    image: ghcr.io/go-shiori/shiori
    container_name: shiori
    environment:
      - PUID=1000
      - PGID=1000
      - SHIORI_DIR=/data
    ports:
      - 8080:8080
    restart: unless-stopped
    volumes:
      - /data/shiori:/data

I removed the environment variable so shiori would write the db to the default location /shiori and also changed the volume path to the same location, now everything is working great.

Nevermind I was mounting the wrong volume…