March 23, 201610 yr First thing, is you want to make sure that the /data mapping matches on all containers (and it doesn't on CP) Secondly, Sab is putting everything into Downloads/complete (and if you look above, you'll see that relative folders are based upon /Config) (and sonarr does not have access to that particular folder) You want to tell Sab to put everything into /Data Once Sab stores its completed downloads in /Data (and all three containers have the same mappings for /Data), then everything should work perfectly (if the API keys match correctly too). You won't even need to use the Black Hole on CP either
March 24, 201610 yr Then either you've messed up the path's in the docker, or you've got drone factory enabled in sonarr.
March 25, 201610 yr How do you figure? The /data doesn't match in sonarr as to the other two. The way that you've got it set up is that presumably sab is saving its downloads into its /config folder (appdata/sabnzbd/downloads/complete) Here's what happens when the docker containers try and communicate to each other. Sonarr / CP tells sab to download something. Scenario #1: If sab downloads into its /config/Downloads/complete/CATEGORY folder: Sab downloads it and stores it into its /config/Downloads/complete/CATEGORY folder Sab then tells Sonarr / CP that the download is completed and passes the path of the file back to sonarr / CP. This path is going to be /config/Downloads/complete/CATEGORY/whatever filename (Note that this maps out to the host as /mnt/user/appdata/sabnzbd/Downloads....) Sonarr / CP look in /config for that file and can't find it (because they are looking for the download in /mnt/user/appdata/sonarr/Downloads/completed/....) Net result: failure Scenario #2: Sab is downloading into /data Sonarr tells sab to download. Sab does and passes the path back to sonarr. Sab in this case tells sonarr that the file is stored in /data/downloads/Complete/TV/whatever file name (This maps out to /mnt/user/downloads/complete/tv/.....) Sonarr looks at that path and tries to process the file and it fails. Because according to the /data mount your passing to sonarr, it is actually looking for the file in: /mnt/cache/sabnzbd/Downloads/Complete/TV/downloads/Complete/TV/whatever filename Net result: failure The Fix set sab to download to /data set the mount points for all the apps that have to deal with the downloads (ie: CP, Sonarr, Sab) to be identical Net result: success First thing, is you want to make sure that the /data mapping matches on all containers (and it doesn't on CP) Secondly, Sab is putting everything into Downloads/complete (and if you look above, you'll see that relative folders are based upon /Config) (and sonarr does not have access to that particular folder) You want to tell Sab to put everything into /Data Once Sab stores its completed downloads in /Data (and all three containers have the same mappings for /Data), then everything should work perfectly (if the API keys match correctly too). You won't even need to use the Black Hole on CP either The logs from Sonarr when it fails to move will tell the complete story
March 25, 201610 yr Ah ok: CP Error: Import failed, path does not exist or is not accessible by Sonarr: /data/appdata/sabnzbd/Downloads/incomplete/tv/ So you advise this instead: /data/appdata//Downloads/incomplete/tv/
March 25, 201610 yr Ah ok: CP Error: Import failed, path does not exist or is not accessible by Sonarr: /data/appdata/sabnzbd/Downloads/incomplete/tv/ So you advise this instead: /data/appdata//Downloads/incomplete/tv/ I'd personally advise setting a separate downloads folder /downloads = /mnt/cache/downloads or /mnt/appdata/downloads then just map that to SABnzbd, Couch, Sonarr. I think it will conceptually make it all a lot easier to manage, as the paths will be transferrable between containers as they will all start with /downloads
March 25, 201610 yr But the net result is the same. Presumably since its /data OP was migrated from binhex apps or is still using them
March 25, 201610 yr But the net result is the same. Presumably since its /data OP was migrated from binhex apps or is still using them Just seems a messy way of doing things having the downloads location within an appdata/sabnzbd subfolder.
March 25, 201610 yr But the net result is the same. Presumably since its /data OP was migrated from binhex apps or is still using them Just seems a messy way of doing things having the downloads location within an appdata/sabnzbd subfolder. i think the only way to settle this is a fight to the death.... my money is on squid.
March 27, 201610 yr Hi, I always have a lot of trouble to get those mappings right. I tried for hour now and it's not working... Some screenshots: Please some help...
March 27, 201610 yr Post some screenshot from unraid too, the docker section. Thanks for the heads up Bjonness406!!! Never thought about to checkout the main Docker page. It's solved now.
March 27, 201610 yr Post some screenshot from unraid too, the docker section. Thanks for the heads up Bjonness406!!! Never thought about to checkout the main Docker page. It's solved now. Good You changed all the mappings inside nzbget?
March 28, 201610 yr Anyone having issues with the Sonarr container after the latest docker update? Updated the docker and it installed as an orphan docker. Have had no luck fixing it so far. Have tried the following: Deleted orphan docker. Container reinstall Deleted orphan docker and appdata folder. Container reinstall Delete and created a new docker image. Container reinstall In the last couple of days I also upgraded plugin Unraid OS 6.1.9 I have had no issues with any other container. While watching the containers install progress there is a warning: "Warning: mkdir(): File exists in /usr/local/emhttp/plugins/dynamix.docker.manager/include/CreateDocker.php on line 23" EDIT: I'm back in. Hope this helps someone in the future Noticed a Dynamix webGui update. After updating the reinstall of Sonarr worked ok. Still get the above warning but everything appears to be working ok
April 10, 201610 yr I am in the process of moving my previous dockers from needo to these and I was able to get sabnzbd to install fine but with Sonarr I am unable to get the webUI to come up. This is all the log shows. Thanks for any help. ------------------------------------- _ _ _ | |___| (_) ___ | / __| | |/ _ \ | \__ \ | | (_) | |_|___/ |_|\___/ |_| Brought to you by linuxserver.io We do accept donations at: https://www.linuxserver.io/donations ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- finding fastest mirror 1. www.gtlib.gatech.edu Latency: 15 ms Org: Georgia Tech. Software Library Status: Up to date Speed: 1 Gbps 2. mirror.atlantic.net Latency: 24 ms Org: Atlantic.Net Status: Up to date Speed: 2 Gbps 3. mirror.symnds.com Latency: 28 ms Org: SymNDS Status: Up to date Speed: 1 Gbps New config file saved to /defaults/sources.list We are now refreshing packages from apt repositories, this *may* take a while Get:1 http://apt.sonarr.tv master InRelease [6,889 B] Ign http://www.gtlib.gatech.edu trusty InRelease Get:2 http://apt.sonarr.tv master/main amd64 Packages [57.3 kB] Get:3 http://www.gtlib.gatech.edu trusty-updates InRelease [65.9 kB] Get:4 http://www.gtlib.gatech.edu trusty-security InRelease [65.9 kB] Get:5 http://www.gtlib.gatech.edu trusty Release.gpg [933 B] Get:6 http://www.gtlib.gatech.edu trusty-updates/main Sources [340 kB] Get:7 http://www.gtlib.gatech.edu trusty-updates/restricted Sources [5,217 B] Get:8 http://www.gtlib.gatech.edu trusty-updates/universe Sources [192 kB] Get:9 http://www.gtlib.gatech.edu trusty-updates/multiverse Sources [5,946 B] Get:10 http://www.gtlib.gatech.edu trusty-updates/main amd64 Packages [942 kB] Get:11 http://www.gtlib.gatech.edu trusty-updates/restricted amd64 Packages [23.5 kB] Get:12 http://www.gtlib.gatech.edu trusty-updates/universe amd64 Packages [462 kB] Get:13 http://www.gtlib.gatech.edu trusty-updates/multiverse amd64 Packages [14.3 kB] Get:14 http://www.gtlib.gatech.edu trusty-security/main Sources [139 kB] Get:15 http://www.gtlib.gatech.edu trusty-security/restricted Sources [3,920 B] Get:16 http://www.gtlib.gatech.edu trusty-security/universe Sources [40.5 kB] Get:17 http://www.gtlib.gatech.edu trusty-security/multiverse Sources [2,549 B] Get:18 http://www.gtlib.gatech.edu trusty-security/main amd64 Packages [564 kB] Get:19 http://www.gtlib.gatech.edu trusty-security/restricted amd64 Packages [20.2 kB] Get:20 http://www.gtlib.gatech.edu trusty-security/universe amd64 Packages [164 kB] Get:21 http://www.gtlib.gatech.edu trusty-security/multiverse amd64 Packages [4,855 B] Get:22 http://www.gtlib.gatech.edu trusty Release [58.5 kB] Get:23 http://www.gtlib.gatech.edu trusty/main Sources [1,335 kB] Get:24 http://www.gtlib.gatech.edu trusty/restricted Sources [5,335 B] Get:25 http://www.gtlib.gatech.edu trusty/universe Sources [7,926 kB] Get:26 http://www.gtlib.gatech.edu trusty/multiverse Sources [211 kB] Get:27 http://www.gtlib.gatech.edu trusty/main amd64 Packages [1,743 kB] Get:28 http://www.gtlib.gatech.edu trusty/restricted amd64 Packages [16.0 kB] Get:29 http://www.gtlib.gatech.edu trusty/universe amd64 Packages [7,589 kB] Get:30 http://www.gtlib.gatech.edu trusty/multiverse amd64 Packages [169 kB] Fetched 22.2 MB in 14s (1,576 kB/s) Reading package lists... Apr 10 12:18:44 176fcfa8215b syslog-ng[68]: syslog-ng starting up; version='3.5.3' [info] Bootstrap: Starting Sonarr - /opt/NzbDrone/NzbDrone.exe - Version 2.0.0.3953 [info] AppFolderInfo: Data directory is being overridden to [/config] [Debug] ProcessProvider: Found 0 processes with the name: NzbDrone.Console [Debug] ProcessProvider: Found 1 processes with the name: NzbDrone [Debug] ProcessProvider: - [69] NzbDrone [info] MigrationLogger: *** Migrating data source=/config/nzbdrone.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 *** [Debug] MigrationLogger: Took: 00:00:00.1244450 [info] MigrationLogger: *** Migrating data source=/config/logs.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 *** [Debug] MigrationLogger: Took: 00:00:00.0110639 [info] Router: Application mode: Interactive [Debug] Router: Console selected [info] OwinHostController: Listening on the following URLs: [info] OwinHostController: http://*:8083/ [Debug] OwinAppFactory: Attaching NzbDroneVersionMiddleWare to host [Debug] OwinAppFactory: Attaching SignalRMiddleWare to host [Debug] OwinAppFactory: Attaching NancyMiddleWare to host [info] NancyBootstrapper: Starting NzbDrone API [Trace] EventAggregator: Publishing ApplicationStartedEvent [Trace] EventAggregator: ApplicationStartedEvent -> UserService [Trace] EventAggregator: ApplicationStartedEvent <- UserService [Trace] EventAggregator: ApplicationStartedEvent -> DownloadClientFactory [Debug] DownloadClientFactory: Initializing Providers. Count 11 [Trace] EventAggregator: ApplicationStartedEvent <- DownloadClientFactory [Trace] EventAggregator: ApplicationStartedEvent -> IndexerFactory [Debug] IndexerFactory: Initializing Providers. Count 14 [Trace] EventAggregator: ApplicationStartedEvent <- IndexerFactory [Trace] EventAggregator: ApplicationStartedEvent -> ReconfigureLogging
April 10, 201610 yr Bill, is this a clean install into a completely new appdata folder or are you using the needo appdata folder from your previous install? Sent from my LG-H815 using Tapatalk
April 10, 201610 yr It is using the config from the old needo one. I was able to do this with couchpotato and sabnzbd just fine.
April 10, 201610 yr It is using the config from the old needo one. I was able to do this with couchpotato and sabnzbd just fine. Try using a new one. The version from needo's app might be completely incompatible with the new versions of Sonarr (or the internal organization chosen within appdata might be signifantly different)
April 10, 201610 yr That seems to work, was hoping to avoid resetting it all back up but ah well. Thanks
April 16, 201610 yr I thought I had the same issue as Bill when transitioning from the needo docker, but it turns out it worked eventually. I started the docker and noticed I couldn't connect on the mapped port. After previously doing the same with sabnzbd and couchpotato I remembered there was some long-ish delay between starting the docker and the webui becoming available. After 5 minutes or so Sonarr came up. Looking at Sonarr's interface, it seems I have a version from March 16th. At the same time, it appears the docker hasn't been updated since January. Putting that all together, does it mean that when we start this docker it's pulling the lastest Sonarr code from git? That would explain all the behavior I've seen.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.