Root folders missing - when they are correct and valid

v3 Testing
#1

Sonarr version (exact version): 3.0.0.348
Mono version (if Sonarr is not running on Windows):
OS: win 7
Debug logs: https://pastebin.com/fCpqUWvk (note, logs and 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:
When first starting the app and system, I get an error for my inbound and main destination folder paths that the root folder is missing. After a period of time, this message will self-correct/ disappear. I am not sure what causes this, or why it happens. I thought I would report it.

#2

19-1-4 15:08:26.9|Warn|DiskScanService|Series' root folder (\\liquiddozen\Media\1TV) doesn't exist. Repeated for multiple series (209 times total).

Sonarr can’t access the network share for some reason, could be several reasons why, but at the same time Sonarr is also unable to connect to qBittorrent, though that appears to be running on localhost.

#3

how are you starting sonarr? service, scheduled task, manually?

#4

I changed the sonarr service to delayed start, but I doubt it will be enough to wait for the torrent client and network to be established on the VM, which has some VPN dependencies etc. I didn’t have an issue previously with v2. I am able to access it fine after a few minutes, but the message remains on the client.

the client is running locally, the files are on a network share, but should be immediately accessible, although I see now I had a VPN kill switch enabled so they were not. I changed this as I have firewall rules setup. The paths exist and are the correct paths… and are accessible… the system has been working fine.
…
—> Ok, found the issue… this must have happened during the upgrade. The service account reset the 'logon as" account to local service account instead of the user account I had added. You should

  1. Update the install doc to have users verify/update the logon as account if they set this different when using external/NAS storage to store content
  2. Update the resolve button / document wiki to check the Remote Path Mappings. It was quite clear there was a problem when I went to check the paths to see if something changed in v3 when I received an error trying to access paths that previously worked.

I was mistaken that things were working. Strangely, SOME things were working, not others. Or I really was duped into thinking it was working when it was NOT. I didn’t see problems where new shows were able to to download… But apparently, there was SOME sort of problem. how could it copy ANYTHING with this set wrong?

thoughts?

1 Like
#5

The upgrade from v2 to v3 removes the old (nzbdrone) service and installs the sonarr server.

If it was able to copy, not sure how changing the user account would make a difference.

#6

Either way, my suggestions stand unless I missed it was already there.

I’m not clear if it was able to copy… I manually moved some files during the week, so it isn’t clear it s working…
Let me stare it another way. B I received NO OTHER error message, no warnings, no failures. That my friend, v is certainly a problem. I would have expected the system to complain about access!

Shouldn’t I get an error from:
19-1-4 16:00:36.9|Error|DownloadedEpisodesImportService|Import failed, path does not exist or is not accessible by Sonarr: \liquiddozen\media\2Finished\Street.Outlaws.S12E01.1080p.WEB.x264-TBS[rarbg]

or shouldn’t there be some sort of error since Sonarr does not have access to the shares at all?

There seems to be less feedback than I’m used to, but a lot more smarts overall.

#7

Am I missing something, shouldn’t this be an enhancement?

#8

Not sure what you’re expecting to be changed. The error was logged, and Sonarr complained that the root folder was inaccessible. Sonarr doesn’t know why it can’t access the downloaded episode or the root folder, it either doesn’t exist or it’s permissions.

v2 did the exact same thing.

#9

I think you are missing my point Markus101…

The system was reinstalled, and the service account lost the configuration I added that allowed Sonarr to connect to network shares.

The only “error” or warning I saw was this root folder error. See why this is a problem?

In the logs, I could see other errors indicating it could not access the files, but no message was displayed.

Some things you could add:

  1. For installations using service account, add a check if mappings are set indicating files are not stored locally. Perhaps a warning message at least alerting the user know to check/update the service account log on user account if accessing resources remotely. (or check for files that are marked as on disk that are no longer accessible upon first run of v3. Perhaps add an error message telling the user to update their service account…
  2. perhaps you already have this, but build upon idea behind #1, and check for ?: in paths, if this exists, make sure you add an error stating the user needs to add remote mappings using UNC path, point to the wiki, and remind them they may need to update the service account to be a user/computer account with access to remote storage.

does that make more sense?

#10

I may be totally on the wrong track here but here goes.
Although the docs ( and UI) clearly state that network paths are not supported when running as a service. they are and always have been if you run the service as your local user account.

Is that what u you are doing when you say this?

If so then this broke for me too recently. It’s nothing to do with v3 at all as far as I’m aware. I have been running v3 alpha since it was initially released. This actually broke with a Windows update in the last couple of weeks and I haven’t had chance to troubleshoot yet. The same thing happened with Radarr at the exact same time.

The bottom line though is the docs/wiki say network paths are NOT supported when running as a service. Whether Markus knows that isn’t… or at least wasn’t…100% correct is by the by.
The key thing is it isn’t “supported”. So in fairness that doesn’t make it a Sonarr issue or something that Sonarr fails to report. I tend to feel that it’s something we need to troubleshoot ourselves.

I am off or a few days now and it’s on my to do list.

The other possibility is I have had too much Jim Beam tonight and I as well as Markus are missing what you’re saying?

#11

And that error was valid, your original concern was Sonarr was wrong but it wasn’t.

Sonarr doesn’t know why it can’t access the root folder, it just can’t we expose that.

Files failing to import also bubbles up to the UI in Activity: Queue.

  1. Perhaps we can include some more information in the wiki page, or in a “migration guide” which is very much not a thing in the alpha.

  2. I’m not really sure what you’re asking to expand on or what you mean by ?: in paths or remote mappings

Network paths are supported. Mapped network drives are not. LocalService has limited share access as it uses anonymous logins.

1 Like
#12

Hitsville… It is working fine for me…

Again, the original problem was an error message about root folders and how to troubleshoot them.

In my case, there was nothing wrong with the root folders. The problem was the service account was reset. I’m asking if perhaps you might want to fix this so that others aren’t confused by the erroneous error message, and I suggested a way to detect how to display a proper error message.

How much clearer can I be than that?

Try it yourself. Install v2 with a service account using a local user account, with storage on another computer, use mapping to convert maps drive letters to unc paths. Then upgrade to v3 without changing the service account See the results.

Thanks

#13

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