Thank you for explaining the ‘hosts’ for the drop-down list for Remote Path Mappings are pulled from the list of clients that are used to Download. I clearly see the problem, I hope to help you see it too! I feel like a complete failure because I fail to have ya see the logic error.
Any user with INCOMING/READY TO IMPORT stored on NAS or alternate server will fail. Why would you force them to only be able to pull from machines running the download client? I am sure it seemed like a good idea at the time, but for folks like myself with STORAGE LIMITATIONS vs. speed would store their incoming remotely. I could also solve this problem by moving my incoming to the local VM, but that limits me to the 60gig drive the VM runs on.
To prove I am correct: I installed bittorrent on my host machine and create a link to is so that that hostname/IP is available. that makes it work!
Ok for my clarification, the HOST listed in the Remote Path Mappings, it needs to be the SERVER that physically stores the files (YES/NO).
This can be a drive on the machine where SONARR is running, OR a Another Machine, OR a NAS/SAN/DAS drive OR a Cloud drive.
The whole point is to know how to access these files, and since we need to use Services in windows, it requires a UNC path (\servername\shareName) and NOT a mapped drive since the service accounts have no “logged on user with mapped drives” so we need a mapping. Great!!! Remote path mapping to save the day!!
*stored files will ALWAYS be on server that is listed in the Download Clients - WRONG *
examples: NAS storage for the incoming directory!!
An IRK of mine is “it works for me and everyone else” is not justification! It doesn’t mean “the only jerk who reported this is wrong.”
I bet you $100 every single person with the following setup (most specifically incoming directory on NAS or remote server has this issue. )
Reach out to or better yet, TEST this scenario (i am giving you every step I can so show what I am doing…)
- Use NAS box or a share on another completer shared on the network - meaning the download client (SAB) downloads TO NAS.
- Has v3.0.3.938. or newer and ideally is using hydra2 with USENET with a WINDOWS SERVICE account starting the service.
- Have them clear their logs, restart the service
- Have them download a show manually
- Once the download competes I guarantee, based on everything you have told me thus far, they HAVE ERRORS and the downloads are NOT importing automatically.
- Get a copy of the logs and review
You asked why “everyone else is working?” it is because the setup above is not likely used by the majority of users, especially once you factor what percent of users are:
- Windows
- using v3 test
- have a service account set up with an NT userID that MUST be created on BOTH the Sonarr Machine AND the NAS/computer hosting the files. (note: if there is an easier way that bypasses all these issues but still stores INCOMING/FINISHED/Plex share on NAS/another PC - I am all ears)
we are already probably down to .5% of users - Trace Logs are ON (0.000000001%) or Debug Logs are ON (0.000001%) (regular logs do not say WARNING or ERROR)
- The UI does NOT FLAG this error in any way. they only get imports that they have to manually import. .001%? This is the icing on the cake.
please please please test this yourself!
Here is my proof:
so I was getting these errors this morning (full log):
“20-9-18 19:56:24.0|Error|DownloadedEpisodesImportService|Import failed, path does not exist or is not accessible by Sonarr: Z:\2Finished\Galactica.80.S01E06.1080p.BluRay.x264-PSYCHD. Unable to find a volume mounted for the path. If you’re using a mapped network drive see the FAQ for more info”
During the time of this log, I added a FAKE Download Client that is disabled.
Now I can select 192.168.1.171. And you can see in the log that towards the end it works again.
I went ahead and stoped Sonarr, cleared all logs, restarted and here is the result:
I can’t imagine how to explain it further. If there is something that I could do differently that will work with my requirements, I am all ears!