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.