Health Check for V3


copy and paste from another thread. I see it as a bug, but I didn’t get a reply…

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 ( see part B on thread:
  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 for more information.

something along these lines.

  1. According to the system, the folder does not exist, it’s not that Sonarr couldn’t access it, it’s flat out it was told it does not exist.

  2. Not every error bubbles up to something else, import errors can be tricky because it’s not known which side failed, it just fails. We do not have plans to bubble up every import failure as a health warning/error or a running counter, that information should all be exposed in Activity: Queue or worst case you need to look at the logs to troubleshoot things.

An FAQ entry specific to import failures may be helpful, but permissions issues are vast and most commonly occur on linux systems based on my experience here, that may change with Sonarr running as a different user for the Windows service, we still need to see what we can improve there.


Ok, thanks for the reply.