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.
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.
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.
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.”)?
@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.
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.
@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):
/opt/Sonarr/UI/Content wasn’t owned by the correct user