[Support] binhex - Sonarr


Recommended Posts

I restarted my server and since then, Sonarr wont start. When I try to start it, I get the following popup message:

 

"Execution error. Server error."

 

The logs have nothing in them. All the other containers were fine after the restart, so I'm not sure what has happened. I've tried reinstalling it from previous apps with no luck.

 

Can anyone help or advise?

Link to comment
1 hour ago, Squid said:

The docker run command will show exactly what is wrong

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-sonarr' --net='bridge' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '9897:9897/tcp' -p '8989:8989/tcp' -v '/mnt/user/Downloads/':'/data':'rw' -v '/mnt/user/Media/TV/':'/media':'rw' -v '/mnt/user/appdata/binhex-sonarr':'/config':'rw' 'binhex/arch-sonarr'
ac4acd4da0a9ffb00b7bb06a7327d16a7a0e15d11ee716eac0230a3a9d9badab
docker: Error response from daemon: driver failed programming external connectivity on endpoint binhex-sonarr (708ec04199f30905cdcdfdf7fb7cba2293aef50da4f9ebc405c4691e0ed73e74): Bind for 0.0.0.0:8989 failed: port is already allocated.

The command failed.

Link to comment

Couldnt see if this has already been stated but after updating to the new Unraid RC (6.10 RC5) from stable I have got permission errors on several Binhex containers here is the error for Sonarr  

 

System.Data.SQLite.SQLiteException (0x80004005): attempt to write a read-only database

 

updating the permissions or reinstalling the App fresh and restore of backup works (i went with the restore as wasnt sure what other files may have permission issues)

Link to comment
2 hours ago, JonathanM said:

One of your currently running containers is already using port 8989

 

Ah, I had it running through binhex-deluge for the vpn. I've now removed the port from the setup, but getting the following error now:

 

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='binhex-sonarr' --net='container:binhex-delugevpn' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -p '9897:9897/tcp' -v '/mnt/user/Downloads/':'/data':'rw' -v '/mnt/user/Media/TV/':'/media':'rw' -v '/mnt/user/appdata/binhex-sonarr':'/config':'rw' 'binhex/arch-sonarr'
Error response from daemon: conflicting options: port publishing and the container type network mode

The command failed.

 

 

I'm not sure why all this is happening. I had to replace the USB as the previous one failed, would that cause these issues? I thought the containers were separate from the USB flash drive?

 

Edited by takkischitt
Link to comment
10 minutes ago, takkischitt said:

-p '9897:9897/tcp

remove that one too.

10 minutes ago, takkischitt said:

I thought the containers were separate from the USB flash drive?

The containers are, the templates are stored on the flash. If you reinstall the container with an old template, or pull a new template and don't modify it for your layout that would explain things.

Link to comment
43 minutes ago, JonathanM said:

remove that one too.

The containers are, the templates are stored on the flash. If you reinstall the container with an old template, or pull a new template and don't modify it for your layout that would explain things.

 

Argh, the USB flash drive backup was from a while ago, so I must've made changes to things since that backup. Will that have messed things up badly? Or if I can get the templates back to the way they were, should everything work again? Sorry for the noob questions, not long with unraid and this pen drive failing has been a pain!

Link to comment

Hello, 

I'm not sure what is going on here....I've had Sonarr for years on Deluge without any issues, and sabnzbd for about a year without any issue....and all of a sudden about a month or so again it sends the file to be downloaded, but then it fails to transfer the file.

It gives this error...2022-04-29 11:46:17.5|Error|DownloadedEpisodesImportService|Import failed, path does not exist or is not accessible by Sonarr: /Downloads/Complete/Moon.Knight.S01E05.Asylum.2160p.WEB-DL.x265.10bit.HDR.DDP5.1.Atmos-NOSiViD/. Ensure the path exists and the user running Sonarr has the correct permissions to access this file/folder

Now what is weird, is it doesn't happen all the time, like I just downloaded new episodes on two different shows.  One show it worked fine, and moved everything over like it is supposed to and moved into plex just fine.  Then I did Ozark and it did not work....strangely that error is not even listed in the log....but there are plenty of other errors there for you to see what I am talking about.

I don't understand what is happening.  

Any help is appreciated.

sonarr.0.txt

Link to comment

Getting an epic fail with latest sonarr image (3.0.8.1507-1-01)-

  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,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...

 

Reverting to 3.0.7.1477-1-01 corrects the problem.

 

Docker run-

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='binhex-sonarr' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Brunnhilde" -e HOST_CONTAINERNAME="binhex-sonarr" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:8989]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/sonarr-icon.png' -p '8989:8989/tcp' -p '9897:9897/tcp' -v '/mnt/user/qbit/':'/data':'rw' -v '/mnt/user/Media/XBMC/TVTorrents/':'/media':'rw' -v '/mnt/user/Media/XBMC/TVTorrents/.RecycleBin':'/Recycle_Bin':'rw' -v '/mnt/user/appdata/binhex-sonarr-v3':'/config':'rw' 'binhex/arch-sonarr:latest' 
a8757f4762952c381937aae30f3b4fa3ecd0debb93e4de312606409d1aad69bf

The command finished successfully!

 

 

brunnhilde-diagnostics-20220501-1452.zip

Link to comment
On 4/29/2022 at 12:16 PM, coltonc18 said:

Hello, 

I'm not sure what is going on here....I've had Sonarr for years on Deluge without any issues, and sabnzbd for about a year without any issue....and all of a sudden about a month or so again it sends the file to be downloaded, but then it fails to transfer the file.

It gives this error...2022-04-29 11:46:17.5|Error|DownloadedEpisodesImportService|Import failed, path does not exist or is not accessible by Sonarr: /Downloads/Complete/Moon.Knight.S01E05.Asylum.2160p.WEB-DL.x265.10bit.HDR.DDP5.1.Atmos-NOSiViD/. Ensure the path exists and the user running Sonarr has the correct permissions to access this file/folder

Now what is weird, is it doesn't happen all the time, like I just downloaded new episodes on two different shows.  One show it worked fine, and moved everything over like it is supposed to and moved into plex just fine.  Then I did Ozark and it did not work....strangely that error is not even listed in the log....but there are plenty of other errors there for you to see what I am talking about.

I don't understand what is happening.  

Any help is appreciated.

sonarr.0.txt 999.92 kB · 1 download

 

On 4/29/2022 at 1:38 PM, coltonc18 said:

Sorry, here you go.

Thanks!

sonarr.jpg

Deluge.jpg

sab.jpg


Does anyone have any thoughts on this issue?

Link to comment
On 5/1/2022 at 2:53 PM, wgstarks said:
EPIC FAIL! System.Exception: attempt to write a readonly database
attempt to write a readonly database

I'm at a loss for this. I don't understand how the sonarr db could be readonly in one version and readwrite in another???

I've checked all the db's in my appdata folder using dynamix file manager and they all show "Owner: Read/Write". I re-applied the setting just to be sure. Didn't make any difference though. Maybe I'm misunderstanding the error? Tried google but couldn't find any info about this error.

 

I did see a similar issue that was corrected by cd to the folder containing the db and then running .recover but that just results in command not found.

Link to comment
6 hours ago, wgstarks said:

I'm at a loss for this. I don't understand how the sonarr db could be readonly in one version and readwrite in another???

i would assume there is some database corruption going on here, probably the later version has attempted to upgrade the database by inserting objects into the sqlite database and failed leaving your database in a bad state. When you rollback to the previous version its unaware of the corruption as it doesn't reference the new (corrupted) inserted objects and thus works fine, this is all guess work here btw.

 

so i can confirm the latest version does work fine, im using it myself with no issue, so im happy the issue you are seeing is not a sonarr issue. 

 

So onto the fix, you can attempt to recover your database (https://wiki.servarr.com/useful-tools#recovering-a-corrupt-db), or simply rename the sqlite database file and then restart the container to force the database to be created from scratch, this will of course result in configuration loss.

 

 

Link to comment
4 hours ago, binhex said:

So onto the fix, you can attempt to recover your database (https://wiki.servarr.com/useful-tools#recovering-a-corrupt-db), or simply rename the sqlite database file and then restart the container to force the database to be created from scratch, this will of course result in configuration loss.

I posted regarding this issue on the Sonarr forum and got a reply back that the Sonarr app was not able to write to logs.db. I changed the permissions for this file and it fixed the issue. The original permissions were owner:read/write group:read only others:read only. New permissions owner:read/write group:read/write and others:read/write. I noticed that logs.db has root as the owner while most of the other files are owned by nobody. This doesn’t seem correct to me and I suspect that that is the real problem since Sonarr is running as nobody.

 

8F6595CA-D575-41E3-A5D4-F46E51E0D3EF.thumb.png.7557e4718e1377764afbd09bdda7ad29.png

 

Shouldn't the owner for logs.db be nobody as well? This is a little outside my experience since I usually avoid making changes to permissions and owners.

Edited by wgstarks
Typo
Link to comment
12 minutes ago, wgstarks said:

I noticed that logs.db has root as the owner while most of the other files are owned by nobody. This doesn’t seem correct to me and I suspect that that is the real problem since Sonarr is running as nobody.

indeed!, all files and folders in the /config folder should be set to owner nobody group users, the ONLY exception to this is the supervisord.log files, which are written as root, as supervisor is running as root user.

 

im quite surprised it was file permissions in the end, as it still doesnt explain why it worked on the rollback to the previous version, that makes NO sense to me whatsoever! as you arent rolling back any files in /config, maybe the previous version doesnt need to write to the db and thus doesnt actually care its read only *shrug*.

Link to comment
3 minutes ago, binhex said:

indeed!, all files and folders in the /config folder should be set to owner nobody group users, the ONLY exception to this is the supervisord.log files, which are written as root, as supervisor is running as root user.

What about perms.txt and nzbdrone.pid? I see that both those files are also currently owned by root.

Link to comment
  • 2 weeks later...

Sonarr is stuck on 'downloaded - waiting to import' it seemed to randomly import 1 episode and then stopped working.. i think i MIGHT have the paths set up correctly but i'm not sure and cant seem to find a solid tutorial. the downloaded icon is blue and not orange so i guess that's good, i'm not getting any errors.. i tried to make qbittorrent add all downloads to their own subfolders and i think that might've helped?? basically i would like some help..

 

BTW, ignore everything related to agents of shield in the log file, i deleted those paths manually.

myip8989_logfile_sonarr.txt.pdf

Edited by emkab
Link to comment
39 minutes ago, emkab said:

Sonarr is stuck on 'downloaded - waiting to import' it seemed to randomly import 1 episode and then stopped working.. i think i MIGHT have the paths set up correctly but i'm not sure and cant seem to find a solid tutorial. the downloaded icon is blue and not orange so i guess that's good, i'm not getting any errors.. i tried to make qbittorrent add all downloads to their own subfolders and i think that might've helped?? basically i would like some help..

 

BTW, ignore everything related to agents of shield in the log file, i deleted those paths manually.

myip8989_logfile_sonarr.txt.pdf 54.32 kB · 1 download

fixed it, i think it was caused by two things:

1. path was stupid, for everyone struggling as well, remember to put your downloads in a share and not in appdata.

2. i THINK (not sure) that qbittorrent was reporting the downloads folder to sonarr as the 'incomplete torrents' path instead of the normal downloads, so i made sure to make them point to the same path

Edited by emkab
Link to comment
  • 2 weeks later...
On 5/3/2022 at 7:49 AM, binhex said:

indeed!, all files and folders in the /config folder should be set to owner nobody group users, the ONLY exception to this is the supervisord.log files, which are written as root, as supervisor is running as root user.

 

im quite surprised it was file permissions in the end, as it still doesnt explain why it worked on the rollback to the previous version, that makes NO sense to me whatsoever! as you arent rolling back any files in /config, maybe the previous version doesnt need to write to the db and thus doesnt actually care its read only *shrug*.

 

  

Just wanted to say thanks because this solved an issue I had after I upgraded to Unraid 6.10.1.  Not sure why all the ownership changed to root for everything in /mnt/user/appdata/binhex-sonarr.  I just chowned nobody:users everything -R and then went in and changed supervisord.log files back to root:root.  Sonarr started right up after that.

 

Thanks again!

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.