Sonarr lost its config and database and the service won't start anymore (DSM 7) #4895
Comments
|
You're looking in the wrong place. During the upgrade from DSM 6 to DSM 7 for all installed packages those @appdata folders are created but with root as owner. If that folder is not owned by sc-nzbdrone, you should change the ownership of that folder to sc-nzbdrone with this command:
And of course after you start Sonarr, restore form within Sonarr the config and database from the backup you made before upgrading to DSM 7 if is needed. |
|
Ah, you're completely right. My settings are indeed in the @appdata folder now. Is this a per-package thing? Radarr is still running and reports it's still using the @appstore folder, and because Sonarr's Wiki also points to @appstore that's where I looked. I just updated their Wiki to point DSM 7 users in the right direction though. As for my problem, it looks like Sonarr may have updated itself and that caused the crash. My permissions on that folder seem fine, I was just haunting ghosts by looking into the wrong folder. |
|
@NMe84 So the latter stays on @appstore/nzbdrone and whate Sonars calls the "home" folder is located at @appdata/nzbdrone. |
|
@BenjV Oh, I understood that part. My confusion comes from the fact that Radarr still reports the old the old folder as being its appdata folder even in the DSM 7 package. But perhaps that's down to them rather than the package. Thanks for your help! And sorry for making a ticket for something that wasn't a package issue. |
|
The package does not report anything it just sets the home location on the startup commandline to @appdata/nzbdrone |
|
Oh definitely. I solved my issue after I dreaded having to rebuild my database with over 800 shows. I can't begin to express how happy I am that you helped me avoid having to do that. 😛 And just to be sure that you understand what I mean: Sonarr and Radarr both report where the app thinks its appdata folder is on their respective "System" pages in the menu. Sonarr says this:
Radarr says this:
Note how Sonarr refers to @appdata for its config and @appstore for its startup folder while Radar reports @appstore for both. |
|
I looked in the Radarr package and that one is not changed to DSM 7 standaards and the home folder still points to @appstore/radarr So I understand your confusion. @th0ma7 , @publicarray |
|
@BenjV reading the thread I first thought this refereed to
That is odd... @BenjV are you saying that DSM7 packages of |
|
@th0ma7
The Sonarr package(nzbdrone) has this:
So I think you're right and that Radar package should be rebuild. |
|
Sorry, I thought I did change it but maybe i never pushed it github.
…On Tue, Oct 5, 2021 at 7:09 pm, BenjV ***@***.***> wrote:
***@***.***(https://github.com/th0ma7)
I downloaded the packages from "SynoCommunity packages" website and found this in the Radarr package:
> HOME_DIR="${SYNOPKG_PKGDEST}/var"
> CONFIG_DIR="${SYNOPKG_PKGDEST}/var/.config"
The Sonarr package(nzbdrone) has this:
> HOME_DIR="${SYNOPKG_PKGVAR}"
> CONFIG_DIR="${SYNOPKG_PKGVAR}/.config"
So I think you're right and that Radar package should be rebuild.
—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](#4895 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABJ6JDWAOUKXJQQ7ZKVKH3TUFKXDVANCNFSM5FIIIRFQ).
|
|
This is a really interesting point that @BenjV noticed, there are indeed a lot of I gave it a shot at bulk-changing that accordingly under my @publicarray while |
|
Can I be a pain and ask to have a seperate PR for those? FYI: While this would fix the paths it doesn't guarantee that the packages are now DSM7 compatible. |
|
As for why there are still so many. It's because mostly @hgy59 and a little myself have updated them to DSM7 one by one. All (except one) have not been ported to DSM7 yet. |
radar was already updated in #4757 that was still pending, but now I have merged. |
Setup
Package Name: Sonarr
Package Version: 20210717-19
NAS Model: DS1819+
NAS Architecture: Atom C3538 (Denverton)
DSM version: 7.0-41890
Expected behavior
Sonarr should run and maintain its config.
Actual behavior
Sonarr lost its entire config folder (and probably more that I can't really tell).
Steps to reproduce
I have no idea, it just happened. I'll include the relevant logging I could find below but none of it seems very helpful.
Package log
Other logs
E.g.
/var/log/messagesor/var/log/synopkg.logWhat happened
I upgraded to DSM7 earlier this week and upgraded my SynoCommunity packages as well. SABnzbd and Radarr immediately lost their config and needed to be set up from scratch but thankfully Sonarr and Transmission worked fine, until just now. Sonarr suddenly crashed about 20 minutes ago and want start again when I tried to run it, neither from the package center nor from the command line using
sudo synopkg start nzbdrone. With the latter I get the following message and then nothing else happens:I attempted to look up what was happening in the package's own log file which should be located in /volume1/@appstore/nzbdrone/.config/Sonarr but I was shocked to find that the entire /volume1/@appstore/nzbdrone/.config/ folder is gone. /volume1/@appstore/nzbdrone/ does exist, but it seems to be lacking a lot of data. I'll put a listing of the entire folder structure below so maybe you can determine what went missing. As far as I can tell my entire config is gone, as well as my entire database of series and episodes. I'm not sure if anything else is missing.
I was not actively using the NAS or Sonarr itself as this was happening. The NAS didn't reboot either, nor do I have anything scheduled around this time that would explain the package shutting down. Additionally the software had been running without issue for 5-6 days around the time it stopped functioning.
At this point I think I'm pretty much screwed when it comes to recovering my data but I would like for whatever caused this to not happen again after I set everything up again, so hopefully this helps you track down what happened.
The text was updated successfully, but these errors were encountered: