After years of working fine, Sonarr now intermittantly loses my NAS

Describe the bug
Sonarr no longer seeing NAS mount when it was before

System Information

  • Sonarr Version: 2.0.0.5338
  • Operating System: Windows 10
  • .net Framework (Windows) or mono (macOS/Linux) Version: No idea

Additional context
I have had Sonarr (and Radarr) setup and running perfectly on a Windows 10 machine for… well for quite a long time. All my media is stored on a Drobo and both Sonarr and Radarr access the media through a UNC path like \\Drobo5N\Drobo\Media\ and the NzbDrone service is setup to logon as my user account. Everything has been working fine for, well years really, with this setup.

Until this week. Now Sonarr (and Radarr alike) appears to not be able to see the path anymore. The Drobo is still there, and I can still access it in Windows Explorer by the same method.

Missing root folder: \\Drobo5N\Drobo\Media\TV Shows

My first guess here is that a recent Window’s update broke something as the last update I see on Sonarr itself is about a month old and it only broke more recently than that. However anything is possible. Maybe it broke earlier and I didn’t notice.

I can post logs if desired but they are large and I didn’t see anything helpful in them other than many entries saying it can’t access the Drobo which I already know :slight_smile:

To be clear, because I know its a common mistake:

  1. I am using UNC paths not drive letter mapping
  2. The NzbDrone service is set to logon as my user account

Restarting Windows will often fix it for a bit then it just stops working again. It used to be rock solid. This runs on a headless machine that isn’t really monitored, so I pretty much don’t even realize there is a problem until my shows aren’t appearing.

Does not running it as a service work? (Run via startup folder instead)

Services can be a little odd with UNC paths depending on when it starts versus other services on the system.

I don’t think “when it starts” has anything to do with it, otherwise restarting the service alone after the machine is up and running would clear the problem and it doesn’t.

As for “Run via startup folder instead” I don’t know what that means.

Its just frustrating that it has been rock solid for years now until recently.

Not necessarily, services have different behaviours with shares.

It’s a way for Windows to start applications automatically when the user logs in.

My point is that when the NzbDrone service starts vs other services is irrelevant to this problem. I know that is often a problem but it is not in this case.

Everything will be up and running just fine for days, until randomly, the service just no longer sees the UNC path anymore. With no hanges to the system, no restart, nothing. At that point restarting NZBDrone will have no effect. The entire system must be restarted to fix it.

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