V3 multiple issues 1)updates failing from branch=phantom 2) upgrade also overwrites service's logon credentials


Sonarr version (exact version):
Mono version (if Sonarr is not running on Windows):
Debug logs:
(Make sure debug logging is enabled in settings and post the full log to hastebin/pastebin/dropbox/google drive or something similar, do not post them directly here. Post in .txt not .doc, .rtf or some other formatted document)
Description of issue:
Issue #1)
In another thread, I discovered a feature was missing, so I didn’t have the latest v3 installed. I saw the app THOUGHT it had the latest version, but manually checking, sure enough, v3.0.0 is older than v3.0.1 so I downloaded v3.0.1.378, installed. The app proceeded to ‘upgrade’ back to 3.0.0…348!

The branch is set to phantom (not listed in the wiki) so I tried master, but that also upgrades to v 3…348. What should branch be set to and/or what should I do to fix this?

I can bet you there are others with this issue if there is a logic error.

issue #2
I reported this before, and perhaps this is a problem that is only related to the fact that I am stuck in never-land.
upon upgrading, I choose “run as a service” which is what I need since the data files are stored on another server (host VM server.) Upon installation completion, I see this error shown in the app:

This is an erroneous error. the ACTUAL problem is the app does not have ACCESS to the folders. I implore the development team to add an error trap that checks for access denied on any/all file writes/ reads, and depending on where these are found, and how the system is set up you could REALLY help users debug their systems.
The Logon account gets set back to local service account (see screenshot) from a user or computer account manually added which is what you do when using NAS storage.)

In the past, I had BOTH of these problems (NTFS permissions issues, service account was changed.) Adding some error checking logic would have saved me months of digging through files /errors to know the problem was simple NTFS and share permission errors.

The root cause of the NTFS permissions were I had some directories that I moved manually in windows that had copied NTFS permissions over as opposed to inheriting permissions which is normally what happens in windows. Therefore, the service account I created did not have access to the folder, and this caused SOME TV series to not be able to be updated or change the file name structure for these folders that the system could not access. Dispite my blond moments lately (doah!) I have deep knowledge of windows 10 (previous windows Active Directory Architect) and with home edition, to set up a service account for NAS storage is quite complicated ( see https://social.technet.microsoft.com/Forums/en-US/e06a5a26-7b25-467f-acc6-09c215f8071f/windows-10-how-to-create-local-service-accounts-for-iis-sql-btsync-and-other-services?forum=win10itprosecurity to get an idea of what is needed to get this working )

In any case, I digress, but my real #2 issue here is that the install should NOT touch the service account, if configured, when upgrading.


the bleeding edge v3 branch is phantom-develop


Cool I had not seen this listed. If I want to have 3.0.1 and not update until the next more stable update, what should I use - or is that phantom?


yes, that would be phantom

for v3, phantom is equivalent to the v2 master branch and phantom-develop is equivalent to the v2 develop branch

its up to you which one you want to use but phantom is a long way behind phantom-develop now. theres also no reason to upgrade to every new release as it comes out, even if youre using phantom-develop


rhom. Not really, phantom was the alpha. we might add phantom-master later, or repurpose phantom. But right now phantom-develop is the only branch, we redid the debian package format and upped the version to 3.0.1.x and added a proper download section to the website (https://sonarr.tv/#downloads-v3).
There no point in a ‘stable’ branch for alpha/beta software. If someone want stable then they honestly should’ve sticked with v2.

Cocokola, regarding issue 2. The built-in updater does not change windows service settings which is the normal update flow. But if you (re)download the windows installer package and run it, it’s essentially a new installation.

The app proceeded to ‘upgrade’ back to 3.0.0…348!

Can you show some log files for that? C:\ProgramData\Sonarr\UpdateLogs
The log file will contain ‘Updating Sonarr from version’… with both version numbers.

To upgrade you can change the branch in Settings->General from phantom to phantom-develop, but I prefer to see the log file first, because it should never downgrade.


When I manually downloaded and installed I left the branch set to master and so far it hasn’t tried to downgrade.

Maybe I should set it to phantom-develop to prevent a potential downgrade to v2??


V3 will never downgrade to v2.

Health Check for V3

I checked C:\ProgramData\Sonarr\UpdateLogs there is nothing newer than 12/30/2018… the install completed, though …?

One thought though, the account that was running was not an admin, which I just changed and will re-run the upgrade to see if this has an effect.

I only had a moment to check this, I will report tomorrow…


so I changed to phantom-develop, and I am running 3.0.1, but there is NO install log after 12-30-2018 listed at C:\ProgramData\Sonarr\UpdateLogs ??

Ok, that makes sense, perhaps you could at least mention this on the download link?

Part B of #2 is the Health check - am I being too ambitious in your opinion suggesting to enhance the current health check?

  1. on root folder health check it is reporting the wrong problem/solution
  2. Add health check with permission problems that you already log in the log file and/or add a separate check that is a simple flag that is set as part of the Check Health OR Refresh Series. When the root directory is walked, if a file can NOT be either READ or a file UPDATED (date/time, adding a poster etc.) Set a Health Flag called “HealthTestPermissionFaled=True” (set parm to False init), and set a HealthPermissionLastFile={name of last file/folder accessed} and finally a HealthPermissionFileCount=HealthPermissionFileCount+1 and display this flag and Last Folder unable to access and total files/folders count in the System Health summary. Ensure at the beginning of each new scan that the file count gets reset or ‘remembers’ the last count if there is not a new problem so it doesn’t just keep counting up. For the Link to FAQ, I will be happy to help write the Windows summary of this - as this will be system dependent and will grow as we troubleshoot (plus scanning this forum for solutions previously provided.) something like:

Verify from the system running Sonarr you can browse to path indicated in the error message (make sure the link in the health check clickable to make this easier for the user.) For NAS or files shared on a remote system, you may need to check the \server\share\path from the system running Sonarr, and if you have set an account to run Sonarr, make sure this account has permission to the share, folder, and files for this path. Note: permissions are handled differently when copying/moving folders, so if you manually move or restore shows you may need to reset permissions so Sonarr has access. See https://support.microsoft.com/en-za/help/310316/how-permissions-are-handled-when-you-copy-and-move-files-and-folders for more information.

something along these lines.

closed #10

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