Run as a Service (Windows), Permission errors with Network SMB Share

Sonarr version (exact version):

OS: Windows 10 Pro Version 1909
Debug logs:
Description of issue:
I’m having a strange permissions issue when sonarr is switched on (not sure if it is also to do with the Windows 10 v1909 update) where my root folder stops having permission to access the share network-wide (meaning on other PCs and even on the local server via shared path (my file server is separated from Sonarr)). Any ideas? As though the limit of the amount of users has been maxed out? The SMB share actually lives on a Windows Server 2012 R2 server, as i have a Hyper-V setup.
Sonarr then says after a minute or two running, that it cannot find that same root folder.
Then, checking mapped network share, I have no permission to access the folder. It is isolated only to the shared folder that Sonarr needs access to. Other services have their own, accessible shares (Radarr, Lidarr) respectfully.
I have leave Sonarr shut down until it is rectified, as I can access the shared folder while Sonarr is off (so that media services can still access the share in the interim).
I have Sonarr running as a service with a specified user account as per the shared folder recommendations in the Wiki…
The SMB share permissions are set to everyone with full rights and the running as a windows service account is seeing the UNC paths correctly in the Sonarr app. and has been transferring fine previously…
I have mentioned my issue in the Discord Sonarr support channel.
I have updated my Intel l350 LAN drivers from version 21.x.x.x to version as per a suggestion about driver relation on the Discord Support channel.

It seems to occur after some import(s)
As soon as an import completes.
Also corrupts files, terminated mid-transfer by this issue.

I still prefer to use the app as a service method, as it allows for a headless environment.

SMB shares are notorious for corrupting files as well (if you do a quick search on the forums you can read all the horror stories), you might want to move away from them. Recommendation is to use NFS.

Thanks. Ill look into changing, if that’s the default Windoze uses. Not even sure any more!

SMB shares corrupting files occurs when running under mono, I don’t recall an instance of corrupt files with SMB before this.

Which user is the Sonarr service running as?
Have you tried changing it to a different user?
If you don’t run the Windows service do you see the same issue?

There are ways to auto-sign into get around that:

Local user account (./[USERNAME] plus that user’s password etc.)

I will try to change back to the Local System Account now and monitor

I will try running it as an app, if the above change doesn’t fix the issue, and I will follow up

Been there, done that. Thank you for the tip however.

Turns out, NFS doesn’t like ReFS :joy: :man_facepalming:

Of course after trying this, I realised Sonarr doesn’t like mapped network drives :man_facepalming:
Time to set up another user “sonarr service” account

I have tried running it as an app, as the separate “Sonarr Service” user for the service account didn’t seem to want to find the mapped network drive (even though it was set to be a part of the Administrtators group).

Note: No success with reverting back to running as a regular desktop app.
Still causes the mapping to eventually deny permission, after attempting an episode import/move job.


See Debug Log “sonarr.debug 12122019.txt” error occurrence time “19-12-12 02:05:09.8”:

I’m beginning to think this may be a Windows permission issue? Maybe something to do with ReFS? Rubbish-e File System?

I am still keeping Sonarr shut down, as it doesn’t work properly.

Very strange, Sonarr doesn’t do anything special for network shares (or local files for that matter). Are you able to test with a NTFS as well? Even just a test series with a few files to import. Not sure what else to recommend.

Yes, Windows definitely has a rubbish inheritance-based permissions database that easily becomes messed up from my understanding.
Thank you for your assistance in any case!
I have a spare HDD I can format to NTFS and attempt trials there. I’m not sure how to temporarily disable the root folder for my only “T:” for the ReFS-based TV Shows for Sonarr not to meddle with running permissions for Plex?

The easiest would be to move one series to the test drive, leave T:\ alone and have Sonarr import some files.

As predicted

BTW, I moved my “non-imported episodes” in my automatic grab drive (buffer) and deleted the torrents in qbittorrent, so that Sonarr would not attempt to mess up the T:\ while testing this NTFS trial.
Sonarr is still causing the screw up to the T:\ permissions, as new episodes for other tv shows arrive in the “buffer” drive.
What I am implying as a suggesting here, is a toggle to stop monitoring root drives in Sonarr while it is running, to avoid these problems of library corruption.

Checking to see if a folder exists should not cause any sort of corruption. It’d do that when it attempted to import a file as well.

We don’t have plans to disable that health check.

I’m sure you can already imagine this, however: The corruption (i believe) occurs, when the connection to the shared folder is lost due to the apparent permission issue and while the file is therefore being transferred (imported). When Sonarr detects that it no longer cannot transfer this file, it logs this error. Then why cannot Sonarr detect that, when the connection to the root folder is back, fix the truncated files via its “health check”?

I not eagerly await another “you are the PEBKAC user” reply.

This is from Sonarr’s front page:

I would like to be in the “no worrries” marketed statement.

That statement is about fetching files from usenet and retrying when they fail to download. There is no relation with them failing to copy to their final location and that statement :wink:

There is no mechanism in sonarr to keep track of and/or retry failed copy operations. It logs a warning, telling the user something went wrong and they need to fix whatever is causing it, and that’s it.
Usually this either always happens, pointing to an underlying issue that needs to be resolved, or never. So in my humble non-sonarr-dev opinion, it’s not worth trying to track each failed copy operation.

There is a check, but it relies on being able to check that it’s been truncated, which is impossible if the share disappears/fails.

Health checks don’t fix things, they check for errors and report them. The only way this could be fixed would be to check every file, which isn’t practical.

And if the share reappears?

When I started one particular job here in Australia, I was told to “have a can-do attitude”. :wink:

Is the log, or import history not re-evaluated?

Then Sonarr would try to import things it hadn’t processed yet.

Only things that aren’t imported would be, Sonarr doesn’t re-process things it’s already done with because the maybe there might have been an error and if the file was moved there wouldn’t be anything to process, the file was moved.

Given the network/share seems to go on strike when it’s asked to move/copy a file, Soanrr is doing everything it can. If it’s told that file you asked me to move was moved, then it’s considered moved, it’s not going to ask if it’s absolutely sure you moved it. If you can’t trust the network/system it’s running on then that needs to be fixed. Same as if you built your house on top of a swamp, you’re not going to ask the builder to build you a new house when the first one sinks.

I like what you did there :slight_smile:

Well, our network here in Australia has a somewhat familiar aroma, from your words of wisdom ( The greater shame is that the network is monetised.

Looks like I’m gonna have to get in touch with our Aborigines and see how I can go even further back to learn on sending some signals. What do you recommend? Smoke, walk, boomerang or didgeridoo?

So I have tried out Sonarr V3
I think I may have drilled down the issue, however it is a very weird scenario of the ReFS “Windows Storage Pools” hiding a HDD IO error pretty well. I have a feeling that it is “self healing” but in the meantime breaking the share somehow? The strange thing about Storage Pools is that it relies on the physical disk(s) to be switched to the “offline” state in Disk Manager, therefore it is difficult to use a tool such as CrystalDisk to asses the SMART info.
Gah! Now if I say I should have tried FreeNAS or SnapRAID or FlexRAID, I wonder how much easier my life would really be?
Maybe the Coronavirus deals with us swiftly!

A bit late to this party (as I always seem to be) but one note I have is that the share permissions and the security tab permissions work in tandem when enumerating network share permissions.
The most restrictive will apply, so by default the “Users” group will only have read access to your share, even if you gave the Everyone group full control (Not recommended btw, The difference between full control and modify is the ability to take ownership or change permissions)

Check your security tab also and make sure it has appropriate permissions to allow the account you are running as a service with enough access to the folders.