[GH-ISSUE #787] Having Postgres Set up for Other Things Causes Non-Start of Shiori v1.6* with Sqlite. #378

New issue

Closed

opened 2026-02-25 23:34:05 +03:00 by kerem · 1 comment

kerem commented

2026-02-25 23:34:05 +03:00

Owner

Originally created by @oemmerson on GitHub (Nov 26, 2023).
Original GitHub issue: https://github.com/go-shiori/shiori/issues/787

Originally assigned to: @fmartingr on GitHub.

Data

Shiori version: v1.6.0-rc.4 (also tried .3):
Database Engine: SQLite
Operating system: Linux
CLI/Web interface/Web Extension: Web, started from CLI.

Describe the bug / actual behavior

Upgrading from the last v1.5.5 stable to the the v1.6 RCs and having DATABASE_URL set for Postgres (for other services) causes non-start of Shiori when it is used with Sqlite.

FATA[2023-11-26T15:53:13Z] error opening database                        error="unsupported database scheme: postgresql"

The v.1.5.5 either gave higher precedence to SQLite or wasn't parsing DATABASE_URL as this issue was not present.
A workaround is to set SHIORI_DATABASE_URL to the URL of your Shiori SQLite database.

Expected behavior

I would expect Shiori to start with SQLite by default as this is what was happening in the current stable version.
Also configuring Postgres is documented as setting SHIORI_DATABASE_URL on the configuration page in in docs. Parsing of DATABASE_URL is not mentioned that I could see.

To Reproduce

Steps to reproduce the behavior:

$ unset SHIORI_DATABASE_URL # Incase it is set.
Set DATABASE_URL to Postgres url that isn't being used for Shiori.
$ shiori server. # Causes above error message on start.
$ unset DATABASE_URL
$ shiori server # Starts nomally

Steps to reproduce the workaround behavior:

Set DATABASE_URL to Postgres url that isn't being used for Shiori.
$ SHIORI_DATABASE_URL=sqlite:///
$ shiori server # Bypasses Postgres DATABASE_URL and starts normally.

Originally created by @oemmerson on GitHub (Nov 26, 2023). Original GitHub issue: https://github.com/go-shiori/shiori/issues/787 Originally assigned to: @fmartingr on GitHub. ## Data - **Shiori version**: v1.6.0-rc.4 (also tried .3): - **Database Engine**: SQLite - **Operating system**: Linux - **CLI/Web interface/Web Extension**: Web, started from CLI. ## Describe the bug / actual behavior Upgrading from the last v1.5.5 stable to the the v1.6 RCs and having DATABASE_URL set for Postgres (for other services) causes non-start of Shiori when it is used with Sqlite. ``` FATA[2023-11-26T15:53:13Z] error opening database error="unsupported database scheme: postgresql" ``` The v.1.5.5 either gave higher precedence to SQLite or wasn't parsing DATABASE_URL as this issue was not present. A workaround is to set SHIORI_DATABASE_URL to the URL of your Shiori SQLite database. ## Expected behavior I would expect Shiori to start with SQLite by default as this is what was happening in the current stable version. Also configuring Postgres is documented as setting SHIORI_DATABASE_URL on the configuration page in in docs. Parsing of DATABASE_URL is not mentioned that I could see. ## To Reproduce Steps to reproduce the behavior: 1. $ unset SHIORI_DATABASE_URL # Incase it is set. 2. Set DATABASE_URL to Postgres url that isn't being used for Shiori. 3. $ shiori server. # Causes above error message on start. 4. $ unset DATABASE_URL 5. $ shiori server # Starts nomally Steps to reproduce the workaround behavior: 1. Set DATABASE_URL to Postgres url that isn't being used for Shiori. 2. $ SHIORI_DATABASE_URL=sqlite:///<your shiori sqlite db> 3. $ shiori server # Bypasses Postgres DATABASE_URL and starts normally.

kerem

2026-02-25 23:34:05 +03:00

closed this issue
added the
type:bug

priority:high
labels

kerem commented

2026-02-25 23:34:05 +03:00

Author

Owner

@fmartingr commented on GitHub (Dec 9, 2023):

We enabled several lookupers in the configuration for migration and backwards compatibilities purposes, which is causing this unexpected behaviour. I would need to review the configuration environment variables and check if we can safely disable the lookuper that is causing this issue.

@fmartingr commented on GitHub (Dec 9, 2023): We enabled several lookupers in the configuration for migration and backwards compatibilities purposes, which is causing this unexpected behaviour. I would need to review the configuration environment variables and check if we can safely disable the lookuper that is causing this issue.

kerem referenced this issue

2026-02-25 23:34:47 +03:00

[PR #378] [MERGED] fix: trying to mkdir over an incorrect data path #579