4 backups every day because "Before update"

Help & Support
#1

Sonarr version (exact version): 3.0.4.1100
Mono version (if Sonarr is not running on Windows): 6.12.0.107
OS: Ubuntu 20.04.1
Debug logs:

Description of issue:
Every day, sonarr makes 4 backups. The reason is “Before update”. My backups folder is spammed with backups, because there are 4 made every day. Looking through the logs, I noticed that every time it’s downloading 3.0.4.1126. It’s updating to 3.0.4.1126 4 times a day.

image
image804×322 15.8 KB

You can ignore the manual backups. Those were made when I was messing around with the sonar api.
image
image854×491 45.1 KB

I thinks that it has to do with the auto update. I have it enabled as you can see in the first picture. My current version (3.0.4.1100) is quite a few versions older than the newest (3.0.4.1126), eventhough I have the option to automatically update on.

I think it has to do with the fact that it isn’t able to automatically install the update, so it stops. Then a few hours later, it checks again and notices that there is still a new version because it failed to update the previous time. So it makes a backup before updating. But because it fails every time to update, it starts trying (and failing) to update every few hours. Leading to the creation of a backup every few hours.

#2

The update interval being 6 hours explains why you’re getting for backups before updating a day, but you need to take a look at the update logs to determine why the update is failing.

#3

Hey @markus101,

Thanks for replying. I went to /home/cas/.config/Sonarr/UpdateLogs and looked into the newest log. I found the following line:

[v3.0.4.1126] System.UnauthorizedAccessException: Access to the path ‘/opt/Sonarr/UI/Content/styles.css.map’ is denied. —> System.IO.IOException: Permission denied

So I’ll just need to change the permissions with chmod and it’ll be fixed.

I’m having problems in general with the permissions for Sonarr. A few examples: (I installed Sonarr using this link - Download v3 Beta section)

  • Sonarr.exe wasn’t executable

  • The folder wasn’t owned by correctly

  • Sometimes after rebooting, Sonarr.exe becomes un-executable again (it was executable before reboot) leading to sonarr not being able to startup.
    At one point I had to write a script that would run instead of /opt/Sonarr/Sonarr.exe that would first chmod Sonarr.exe to 0777 and after that run /opt/Sonarr/Sonarr.exe because everytime after rebooting, it would go back to being un-executable.

  • And the problem of this post; styles.css.map isn’t accesable

Question:
To which chmod “code” do I need to set styles.css.map (e.g. 0777, 0664 etc.)?

What are the permissions in general that I need to set for the files inside /opt/Sonarr (e.g. “Sonarr.exe needs to be 0777, styles.css.map needs to be 0xxx, [this] complete folder needs to be 0xxx etc. etc.”)?

Thanks!

#4

Sounds like something is overriding the default permissions, possibly on a schedule as well since they were later re-broken.

They don’t need to be executable, but need read/write access for the user running Sonarr, 0664 should be fine.

If ownership is set correctly it shouldn’t need to be writable by anyone other than the owner/it’s group.

#5

@markus101,
After doing sudo chmod 0664 styles.css.map and sudo chmod a+rw styles.css.map, it still says permissions denied.

ls -n shows

-rw-rw-rw- 1 0 0 222903 feb 4 05:56 styles.css.map

In the update log (newest after doing the chmod and re-running the update, which failed) it says

at System.IO.FileSystem.DeleteFile (System.String fullPath) …

I have a feeling that it has to with permissions for deleting the file but it has read and write, as ls told.

What do you think it is now? Or did I set the permissions wrong?

Edit: sudo chown cas styles.css.map didn’t help. Sonarr is being run by the user cas in the group cas. /opt/Sonarr/ is owned by the user and group cas.

#6

Without know exactly what failed now I don’t have any suggestions (the partial stack trace from an error doesn’t help).

#7

Here is the newest update log:

#8

It’s deleting the file before the update so files no longer in the package aren’t left behind and you’re correct it can’t access the file to do so. File locking isn’t an issue, so permissions are the likely culprit. After you fix the permissions is something else mucking with them? You’ve mentioned that you have already seen that behaviour once, so my best guess is that’s happening and until the reason for those changes it tracked down you’re like to see issues.

Re-installing the package to upgrade is probably your best bet currently, but that won’t fix things long term if permissions are being altered.

#9

@markus101 Hey I finally fixed it.
Someone (on a different forum) suggested using “pathlld” (github link) to find out why the permissions are wrong. After using the tool, I found the following problems (and fixing them made it work):

  1. /opt/Sonarr/UI/Content wasn’t owned by the correct user

  2. /opt/Sonarr/UI wasn’t writable

After changing that, the update worked perfectly!

Thanks

#10

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