adityachandelgit
Completely broken after updating to 1.13.0
🐛 Bug Report for Booklore
Thank you for taking the time to report this bug. Your feedback helps make Booklore better for everyone!
Let's squash this bug together! 🔨
📝 What happened?
Can't load the application at all; it's just a white screen when visiting the URL
🔄 Steps to Reproduce
Visit my Booklore IP address
Result:
✅ Expected Behavior
The application loads
📸 Screenshots / Error Messages
Blank page
💻 Environment
- Booklore Version: (e.g., v1.1.0)
- OS: (e.g., Windows 11, macOS Sonoma, Ubuntu 22.04)
- Browser: (e.g., Chrome 120, Firefox 121, Safari 17)
- Installation: (e.g., Docker, Unraid, Manual)
- Storage Type: (e.g., Local HDD/SSD, Synology NAS, SMB Share, NFS Mount, S3 Bucket)
📌 Additional Context
✨ Possible Solution (Optional)
Try to delete your cache. Open network tab and check disable cache. Then keep network tab open, refresh your page. And if it doesn't work show what requests goes red.
Just updated from 1.12.0 to 1.13.1. No issues here - so I agree with @Buco7854 in that it sounds a caching issue.
I have this same issue. Can you be more specific on where the network tab is? I am having the issue across multiple browsers
@cdellaro Either F12 or Right click then Inspect Element. Then developer tool will open and just click on "Network" tab.
@subtleslander @cdellaro Are you using the Proxmox script? Booklore was downgraded from Java 25 to 21, but Proxmox is still on Java 25, causing the build to fail. The related Proxmox fix has been merged here: https://github.com/community-scripts/ProxmoxVE/pull/9566.
@adityachandelgit I do not know if I am - I set up the containers using a portainer guide, which was working fine for the last several months until yesterday.
I disabled the network cache but am getting 3 errors under public settings
It can run and is then thrown into a restarting loop. this is the log:
SQL State : 28000
Error Code : 1045
Message : (conn=8) Access denied for user 'Chris'@'172.22.0.3' (using password: YES)
at org.flywaydb.core.internal.jdbc.JdbcUtils.openConnection(JdbcUtils.java:71) ~[flyway-core-11.7.2.jar!/:na]
at org.flywaydb.core.internal.jdbc.JdbcConnectionFactory.
Well here you go. The logs are kind of explicit.
Either its some escaping issue wich I doubt it is. Or you changed password in your config after database was initialised, or you change the password in mysql.
I suppose - it is not very layperson friendly. Just says that there is a password being used. I don't know how that would have changed by updating the image, though.
I just matched the mysql and database usernames and passwords still the same issue.
I suppose - it is not very layperson friendly. Just says that there is a password being used. I don't know how that would have changed by updating the image, though.
It means password was incorrect or that it did not have permissions to connect to the database from the ip it comes from.
Honestly i'm pretty sure thats on your part. Booklore updating would not change database like that and if it did you probably would not be the only one. Maybe you changed something without realizing. Connect to database reset the password for booklore with the correct one.
Or just reinitialize db. But you'll lose your data.
Having the exact same issue, but from a fresh install. Docker on OSX
Do you use docker compose?
Have you tried startiing it with some simple password like "password".
That could be related to escaping. Could you try that?
Once its done if its still not working please send compose and .env. ( with the simplified credentials you just tested)
Do you use docker compose?
Yes
That could be related to escaping.
That crossed my mind as well, so I changed all credentials to simple strings already, but no luck.
# BookLore Application Settings
APP_USER_ID=501
APP_GROUP_ID=20
TZ=Etc/UTC
BOOKLORE_PORT=6060
# Database Connection (BookLore)
DATABASE_URL=jdbc:mariadb://mariadb:3306/booklore
DB_USER=booklore
DB_PASSWORD=booklore
# MariaDB Container Settings
DB_USER_ID=501
DB_GROUP_ID=20
MYSQL_ROOT_PASSWORD=booklore
MYSQL_DATABASE=booklore
services:
booklore:
image: booklore/booklore:latest
# Alternative: Use GitHub Container Registry
# image: ghcr.io/booklore-app/booklore:latest
container_name: booklore
environment:
- USER_ID=${APP_USER_ID}
- GROUP_ID=${APP_GROUP_ID}
- TZ=${TZ}
- DATABASE_URL=${DATABASE_URL}
- DATABASE_USERNAME=${DB_USER}
- DATABASE_PASSWORD=${DB_PASSWORD}
- BOOKLORE_PORT=${BOOKLORE_PORT}
depends_on:
- mariadb
ports:
- "${BOOKLORE_PORT}:${BOOKLORE_PORT}"
volumes:
- ./booklore:/app/data
- ~/Downloads/calibre:/cwa-book-ingest
- /Volumes/Misc/Books/Library:/books
restart: unless-stopped
mariadb:
image: lscr.io/linuxserver/mariadb:11.4.5
container_name: mariadb
environment:
- PUID=${DB_USER_ID}
- PGID=${DB_GROUP_ID}
- TZ=${TZ}
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${DB_USER}
- MYSQL_PASSWORD=${DB_PASSWORD}
volumes:
- ./mariadb/config:/config
restart: unless-stopped
Thanks for that.
Did you delete those directories after changing the password? If its a fresh install i believe you dont care much about the data for now.
./mariadb/config ./booklore
Yep. docker compose down -v and completely removing all data. I get the access denied error in the mariadb logs with root@localhost
Thats weird.
So you just created compose, the .env
Up.
And then the mariadb error?
I'm gonna try to reproduce it on Debian. If I can’t reproduce i'll try and see if I can spin up a vm to try on OS X.
Are you on OS X too @cdellaro ?
Yes, pretty much. Just tried logging in to mysql on the mariadb container with docker exec, it seems the password is an empty string, which makes me believe the .env file isn't picked up (assuming an empty string is the default fallback for the password).
Yes, pretty much. Just tried logging in to mysql on the mariadb container with docker exec, it seems the password is an empty string, which makes me believe the .env file isn't picked up (assuming an empty string is the default fallback for the password).
When you launch it do you have some warning regarding the env. Since the MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD are set in environment if it wasnt picked up it should warn you that the MYSQL_ROOT_PASSWORD or DB_PASSWORD is empty.
If you do ls you see docker-compose.yml and .env (named like this)? or do you have soem others maybe there are dupes and it doesnt launch the proper one?
Scratch that, when I log in through docker exec -it mariadb mysql -uroot -p the password 'booklore' works, empty string doesn't.
Scratch that, when I log in through
docker exec -it mariadb mysql -uroot -pthe password 'booklore' works, empty string doesn't.
Not sure to understand.
The password is an empty string?
If you can access the mysql cli can you try
SELECT User, Host FROM mysql.user;
Regarding empty root password I believe its because you login trough cli as root you dont need to input a password MYSQL_ROOT_PASSWORD is probably for remote connections. I had the same behavior but Booklore still run normaly.
If you can access the mysql cli can you try
SELECT User, Host FROM mysql.user;
MariaDB [(none)]> SELECT User, Host FROM mysql.user;
+-------------+--------------+
| User | Host |
+-------------+--------------+
| booklore | % |
| root | % |
| root | 127.0.0.1 |
| root | 629cd042f6f2 |
| root | ::1 |
| mariadb.sys | localhost |
| root | localhost |
+-------------+--------------+
7 rows in set (0.165 sec)
Log:
251205 15:49:50 mysqld_safe Starting mariadbd daemon with databases from /config/databases
2025-12-05 15:49:58 0 [Warning] Setting lower_case_table_names=2 because file system for /config/databases/ is case insensitive
2025-12-05 15:49:58 0 [Note] Starting MariaDB 11.4.5-MariaDB-log source revision 0771110266ff5c04216af4bf1243c65f8c67ccf4 server_uid XCeBTkKeBJM526UsRWG0+xf81Nk= as process 525
2025-12-05 15:50:03 0 [Note] InnoDB: Compressed tables use zlib 1.3.1
2025-12-05 15:50:04 0 [Note] InnoDB: Number of transaction pools: 1
2025-12-05 15:50:04 0 [Note] InnoDB: Using ARMv8 crc32 + pmull instructions
2025-12-05 15:50:04 0 [Note] InnoDB: Using Linux native AIO
2025-12-05 15:50:04 0 [Note] InnoDB: Initializing buffer pool, total size = 256.000MiB, chunk size = 4.000MiB
2025-12-05 15:50:04 0 [Note] InnoDB: Completed initialization of buffer pool
2025-12-05 15:50:05 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
2025-12-05 15:50:05 0 [Note] InnoDB: End of log at LSN=47629
2025-12-05 15:50:06 0 [Note] InnoDB: Opened 3 undo tablespaces
2025-12-05 15:50:06 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
2025-12-05 15:50:06 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-12-05 15:50:06 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-12-05 15:50:06 0 [Note] InnoDB: log sequence number 47629; transaction id 14
2025-12-05 15:50:06 0 [Note] InnoDB: Loading buffer pool(s) from /config/databases/ib_buffer_pool
2025-12-05 15:50:06 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-12-05 15:50:06 0 [Note] Plugin 'wsrep-provider' is disabled.
2025-12-05 15:50:07 0 [Note] InnoDB: Buffer pool(s) load completed at 251205 15:50:07
2025-12-05 15:50:10 0 [Note] Server socket created on IP: '0.0.0.0'.
2025-12-05 15:50:10 0 [Note] Server socket created on IP: '::'.
2025-12-05 15:50:11 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
2025-12-05 15:50:11 0 [Note] /usr/bin/mariadbd: ready for connections.
Version: '11.4.5-MariaDB-log' socket: '/run/mysqld/mysqld.sock' port: 3306 Alpine Linux
2025-12-05 15:50:11 4 [Warning] Aborted connection 4 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication)
2025-12-05 15:50:13 6 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
Does happens when you launch booklore?
2025-12-05 15:50:13 6 [Warning] Access denied for user 'root'@'localhost' (using password: YES)
Booklore user exist and can log in from any IP so there is definitly an issue with the password/user passed to the database.
The only thing I can think of and is differrent between your compose and mine is a health check and a depends_on service healthy so maybe there is a race condition on your side. Don' t have much hope about it but it cost nothing to try and its actually better practice.
Can you try adding this is your booklore service instead of the simple one:
depends_on:
mariadb:
condition: service_healthy
And this in mariadb service:
healthcheck:
test: [ "CMD", "mariadb-admin", "ping", "-h", "localhost" ]
interval: 5s
timeout: 5s
retries: 10
No difference, it's how I started initially, just removed it to avoid the time waiting on the healthcheck.
Can you: reset everything. Make sure password is 'password' in env. up Now there is error. Log in mysql cli and run:
ALTER USER 'booklore'@'%' IDENTIFIED BY 'password';
Down. Up. See what you get in booklore logs.
Also:
docker compose exec mariadb mysql -u booklore -p
With password. To see which of booklore or mariadb doesnt get the correct one