How I Fixed My Corrupted Radarr Database and Authentication Loop

The Problem

It started with a simple issue – I couldn’t access my Radarr instance. Even though my config.xml clearly showed AuthenticationMethod>none</AuthenticationMethod>, Radarr kept asking for login credentials that I never set up.

After checking the logs, I discovered the real culprit:

[v5.28.0.10274] code = Corrupt (11), message = System.Data.SQLite.SQLiteException (0x800007EF): database disk image is malformed
database disk image is malformed

[v5.28.0.10274] code = Corrupt (11), message = System.Data.SQLite.SQLiteException (0x800007EF): database disk image is malformed
database disk image is malformed

The SQLite database that stores all of Radarr’s configuration, movie data, and settings had become corrupted, creating an authentication loop that made Radarr inaccessible.

The Solution: Database Recovery

Step 1: Stop Radarr

First, I stopped the Radarr service to prevent further corruption:

docker stop radarr

docker stop radarr

Step 2: Backup Corrupted Files

Before attempting any recovery, I made backups of all database files:

cd /mnt/kubernetes/volume/radarr/data
cp radarr.db radarr.db.corrupted.backup
cp radarr.db-wal radarr.db-wal.backup
cp radarr.db-shm radarr.db-shm.backup

cd /mnt/kubernetes/volume/radarr/data
cp radarr.db radarr.db.corrupted.backup
cp radarr.db-wal radarr.db-wal.backup
cp radarr.db-shm radarr.db-shm.backup

Step 3: Attempt Database Recovery

Using SQLite’s built-in recovery tools:

sqlite3 radarr.db ".recover" | sqlite3 radarr_fixed.db

sqlite3 radarr.db ".recover" | sqlite3 radarr_fixed.db

This command attempts to recover as much data as possible from the corrupted database and write it to a new file. I encountered some constraint errors during recovery, which is normal with corrupted databases:

Error: near line 14651: stepping, UNIQUE constraint failed: Commands.Id (19)

Error: near line 14651: stepping, UNIQUE constraint failed: Commands.Id (19)

Despite these errors, the recovery process created a radarr_fixed.db file with most of my data intact.

Step 4: Replace the Database

I replaced the corrupted database with the recovered version and cleaned up the write-ahead log (WAL) files:

mv radarr.db radarr.db.corrupted.final_backup
mv radarr_fixed.db radarr.db
rm -f radarr.db-wal radarr.db-shm

mv radarr.db radarr.db.corrupted.final_backup
mv radarr_fixed.db radarr.db
rm -f radarr.db-wal radarr.db-shm

Step 5: Restart and Test

After starting Radarr again:

docker start radarr

docker start radarr

I could finally access my Radarr instance without any authentication prompts!

Prevention Measures

Once I regained access, I immediately implemented these preventive measures:

1. Enabled Automatic Backups: Settings > General > Backup > Set to daily
2. Regular Database Maintenance: Planning periodic VACUUM operations on the database
3. Proper Shutdown Procedures: Ensuring clean shutdowns of the Radarr container

Key Takeaways

1. Regular Backups Are Essential: Had I not been able to recover the database, I would have lost all my settings and movie metadata.
2. Check Logs First: The authentication issue was just a symptom – the real problem was database corruption.
3. SQLite Recovery Tools Are Powerful: The .recover command salvaged most of my data despite significant corruption.
4. Remove WAL Files: This is crucial when dealing with database corruption – old WAL files can cause the corruption to persist.

Useful Commands for Future Reference

• Check database integrity: sqlite3 radarr.db "PRAGMA integrity_check;"
• Create backup: sqlite3 radarr.db ".backup radarr.backup.db"
• Compact database: sqlite3 radarr.db "VACUUM;"

This experience taught me the importance of regular maintenance and backups for self-hosted applications. Hopefully, this guide helps others facing similar Radarr database issues!