Epic fail with version 3.0.8.1507-1-01

Sonarr version (exact version): [3.0.8.1507-1-01]
Mono version (if Sonarr is not running on Windows):
OS: unraid
Debug logs:
Description of issue:

Epic fail when attempting to start this version.
Log output-

2022-05-01 14:45:02,874 DEBG 'sonarr' stdout output:
EPIC FAIL! System.Exception: attempt to write a readonly database
attempt to write a readonly database
While Processing:
"INSERT INTO "VersionInfo" ("Version", "AppliedOn", "Description") VALUES (168, '2022-05-01T18:45:02', 'add_additional_info_to_pending_releases')" ---> System.Data.SQLite.SQLiteException: attempt to write a readonly database
attempt to write a readonly database
  at System.Data.SQLite.SQLite3.Reset (System.Data.SQLite.SQLiteStatement stmt) [0x00088] in <cf516e4846354910b3d60749c894b1bf>:0 
  at System.Data.SQLite.SQLite3.Step (System.Data.SQLite.SQLiteStatement stmt) [0x0006e] in <cf516e4846354910b3d60749c894b1bf>:0 
  at System.Data.SQLite.SQLiteDataReader.NextResult () [0x00174] in <cf516e4846354910b3d60749c894b1bf>:0 
  at System.Data.SQLite.SQLiteDataReader..ctor (System.Data.SQLite.SQLiteCommand cmd, System.Data.CommandBehavior behave) [0x0008e] in <cf516e4846354910b3d60749c894b1bf>:0 
  at (wrapper remoting-invoke-with-check) System.Data.SQLite.SQLiteDataReader..ctor(System.Data.SQLite.SQLiteCommand,System.Data.CommandBehavior)
  at System.Data.SQLite.SQLiteCommand.ExecuteReader (System.Data.CommandBehavior behavior) [0x0000c] in <cf516e4846354910b3d60749c894b1bf>:0 
  at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery (System.Data.CommandBehavior behavior) [0x00006] in <cf516e4846354910b3d60749c894b1bf>:0 
  at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery () [0x00006] in <cf516e4846354910b3d60749c894b1bf>:0 
  at FluentMigrator.Runner.Processors.SQLite.SQLiteProcessor.ExecuteNonQuery (System.String sql) [0x00013] in <137fb96feee44f379d6a8fba4e172d1c>:0 
   --- End of inner exception stack trace ---
  at FluentMigrator.Runner.Processors.SQLite.SQLiteProcessor.ExecuteNonQuery (System.String sql) [0x0003e] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at FluentMigrator.Runner.Processors.SQLite.SQLiteProcessor.Process (System.String sql) [0x0003f] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at FluentMigrator.Runner.Processors.ProcessorBase.Process (FluentMigrator.Expressions.InsertDataExpression expression) [0x0000d] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at FluentMigrator.Expressions.InsertDataExpression.ExecuteWith (FluentMigrator.IMigrationProcessor processor) [0x00000] in <c16130ff2bfb4746b4fb36de17115e3e>:0 
  at FluentMigrator.Runner.VersionLoader.UpdateVersionInfo (System.Int64 version, System.String description) [0x00040] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at FluentMigrator.Runner.MigrationRunner.ApplyMigrationUp (FluentMigrator.Infrastructure.IMigrationInfo migrationInfo, System.Boolean useTransaction) [0x0010f] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at FluentMigrator.Runner.MigrationRunner.MigrateUp (System.Boolean useAutomaticTransactionManagement) [0x000af] in <137fb96feee44f379d6a8fba4e172d1c>:0 
  at NzbDrone.Core.Datastore.Migration.Framework.MigrationController.Migrate (System.String connectionString, NzbDrone.Core.Datastore.Migration.Framework.MigrationContext migrationContext) [0x000a2] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Datastore\Migration\Framework\MigrationController.cs:51 
  at NzbDrone.Core.Datastore.DbFactory.CreateLog (System.String connectionString, NzbDrone.Core.Datastore.Migration.Framework.MigrationContext migrationContext) [0x00000] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Datastore\DbFactory.cs:136 
  at NzbDrone.Core.Datastore.DbFactory.Create (NzbDrone.Core.Datastore.Migration.Framework.MigrationContext migrationContext) [0x00047] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Datastore\DbFactory.cs:89 
  at NzbDrone.Core.Datastore.DbFactory.Create (NzbDrone.Core.Datastore.Migration.Framework.MigrationType migrationType) [0x00000] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Datastore\DbFactory.cs:70 
  at NzbDrone.Core.Datastore.DbFactory.RegisterDatabase (NzbDrone.Common.Composition.IContainer container) [0x00019] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Datastore\DbFactory.cs:52 
  at NzbDrone.Host.NzbDroneServiceFactory.Start () [0x00037] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Host\ApplicationServer.cs:60 
  at NzbDrone.Host.Router.Route (NzbDrone.Host.ApplicationModes applicationModes) [0x0007f] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Host\Router.cs:56 
  at NzbDrone.Host.Bootstrap.Start (NzbDrone.Host.ApplicationModes applicationModes, NzbDrone.Common.EnvironmentInfo.StartupContext startupContext) [0x0003d] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Host\Bootstrap.cs:78 
  at NzbDrone.Host.Bootstrap.Start (NzbDrone.Common.EnvironmentInfo.StartupContext startupContext, NzbDrone.Host.IUserAlert userAlert, System.Action`1[T] startCallback) [0x0007f] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Host\Bootstrap.cs:41 
  at NzbDrone.Console.ConsoleApp.Main (System.String[] args) [0x00030] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Console\ConsoleApp.cs:42 

2022-05-01 14:45:02,891 DEBG 'sonarr' stdout output:
Press enter to exit...

Running Sonarr in a docker on unraid.
Reverting to the previous version corrected this problem. Sonarr starts with no issues.

logs.db is not writable by the user sonarr is running as

Thanks. You are completely correct. Permissions for logs.db was owner:read/write group:readonly and others:readonly. Since the owner for logs.db is root and Sonarr is running as nobody it didn’t have write privileges. I’ve changed the permissions so that all have read/write access and that solved the error but I’m wondering why logs.db is owned by root while all the other db files are owned by nobody? Seems to me that that is the real cause of this.

Sounds like your puid and guid configured in your docker compose are not correct and/or your ran sonarr as not those users at one point.

Nobody is the internal docker user

The puid and guid are set correctly (already checked) but perhaps your right about this^^. I’ve been in touch with the docker maintainer and got all the owners set correctly, there were several that were wrong. Not sure why it wasn’t an issue with the previous version of Sonarr but it’s all fixed now. Thanks for your help with this.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.