Docker Issue - Sonarr and Deluge

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • BTW
      Images
      • deluge1.PNG

        34.19 kB, 649×706, viewed 144 times
      • deluge2.PNG

        42.31 kB, 652×702, viewed 150 times
      • deluge3.PNG

        38.45 kB, 654×702, viewed 135 times
      • docker.PNG

        24.05 kB, 1,674×427, viewed 148 times
      • filestructure.PNG

        8.44 kB, 368×335, viewed 133 times
      • sonarr1.PNG

        28.34 kB, 683×655, viewed 132 times
      • sonarr2.PNG

        41.74 kB, 670×655, viewed 143 times
      • sonarr3.PNG

        8.44 kB, 672×266, viewed 118 times
    • majorpayne wrote:

      I've uploaded my file structure in case it helps you help me :)

      I'm going to remake the docker containers in case i missed a step.
      While setting up some hardware and OMV for docker tests, I noticed and installed both sonarr and deluge from OMV plugin's and they work fine.

      Is there any particular reason why you're using Dockers, versus OMV's sonarr and deluge plugins?
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Because every once in a while sonarr doesn't move a show over, I can only assume it's because of this error
      You are running an old and unsupported version of Mono. Please upgrade Mono for improved stability.

      The last time i attempted to update mono i screwed the update management to the point I wasn't able to get new updates and had to resinstall OMV
    • OK @majorpayne. As I mentioned before, all of my path mapping is done in a single storage container, which is then attached to every other container. The paths are s follows:



      I use rutorrent instead of Deluge for torrent downloading. The concept, though, is the same. Here is a screenshot of the downloads directory as specified in the rutorrent web UI itself. Notice that the download directory in rutorrent is a match for one of the paths on the right side of my storage container, both labeled by "1."Your Deluge container has a path mapped as "/downloads" and therefore you should also type "/downloads" into Deluge when it asks for your download directory. My suspicion is that you have the full /srv/... path):




      Display Spoiler

      This pic is stolen from a Deluge setup guide. The label 2 is where you should have typed /downloads.[IMG:https://www.htpcguides.com/wp-content/uploads/2016/05/deluge_download_path-min.png]



      Similarly, I use NZBGet to download shows for Sonarr and movies for Radarr from Usenet. Again, the paths I specify inside the NZBGet interface have to be a perfect match for the paths specified on the RIGHT side of the Docker container, marked with "2," "3," and "4." See below:

      The post was edited 1 time, last by flvinny521 ().

    • @majorpayne and @flvinny521

      What are your image id's for sonarr?

      I have 41feef15f927 loaded
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • flvinny521 wrote:

      OK @majorpayne. As I mentioned before, all of my path mapping is done in a single storage container, which is then attached to every other container. The paths are s follows:



      I use rutorrent instead of Deluge for torrent downloading. The concept, though, is the same. Here is a screenshot of the downloads directory as specified in the rutorrent web UI itself. Notice that the download directory in rutorrent is a match for one of the paths on the right side of my storage container, both labeled by "1."Your Deluge container has a path mapped as "/downloads" and therefore you should also type "/downloads" into Deluge when it asks for your download directory. My suspicion is that you have the full /srv/... path):




      Display Spoiler

      This pic is stolen from a Deluge setup guide. The label 2 is where you should have typed /downloads.[IMG:https://www.htpcguides.com/wp-content/uploads/2016/05/deluge_download_path-min.png]



      Similarly, I use NZBGet to download shows for Sonarr and movies for Radarr from Usenet. Again, the paths I specify inside the NZBGet interface have to be a perfect match for the paths specified on the RIGHT side of the Docker container, marked with "2," "3," and "4." See below:


      What container do you use for storage? Is it safe to assume that you are using a docker container for that?
    • I have working Docker installs for Sonarr and Deluge, with Sonarr connecting to Deluge.

      While it appears that Sonarr requires a few more bits to be fully functional, an indexer, etc. it is connecting to storage locations as indicated below:

      ____________________________________________________


      I've tested Deluge for connectivity to the data disk and pulled a few torrents with it.
      (Debian DVD install Disks, 3 each, all are 3+GB files)

      Deluge - interestingly - doesn't download to "/downloads" , by default, as the the doc's on this Docker seem to suggest.
      It downloaded to /root/Downloads which is internal to the container. (Not good for those using thumbdrives to boot.)
      To "fix it", a change was required in preferences. I set Download to: to /downloads so the containers default Volume and Bind point mapping works correctly. The disk free space, lower right, shows Deluge is connected to the storage disk/directory.



      (On a side note, I was surprised at Deluge's speed. It brought down the ISO's at speeds north of 3MBS.)
      ____________________________________________________________

      On differences in configuration:

      First:
      Where network ports do not interfere with the operation of host, using the HOST mode for networking is the general rule of thumb. Bridged could be used but, in general, it's only needed when container ports must be remapped.
      (And while off topic, Macvlan is used when there's an irreconcilable host/container port conflict, requiring the use of a separate IP address.)

      Second:
      I didn't set up a docker user. Where PUID's and PGID's are needed, as I believe they are in this case with direct data disk access, I use the root account and the users group.

      - While this is speculation on the permissions problem;
      Where I think @majorpayne may has a problem is with the PUID and PGID. I set PUID for my root account "0" and my PGID for "100" my users group.

      From what I've seen in earlier screen shots, @majorpayne should be using PUID 0 and PGID 100 as well.




      The above permissions should work for your containers and give all Samba share users at least read access to /Downloads.

      While I didn't do it in the above; since you're likely to have a number of sub-directories under /Downloads, I'd check the box for Set group, owner and permissions recursively.
      (Leave permissions on /srv and /dev-disk-by-label-* as they are.)

      _______________________________________________________________


      On the Docker configurations - the user added parts

      The following is what I have for Deluge.



      In the above, note the folder icon in Volumes and Bind mounts. Use it to browse to your data storage location, when setting Host paths. If you can browse to the location, and with the right PGID and PUID, deluge should be able to write the location.
      ________________________________________________________________________


      With the exception of the TZ (time zone) variable, there's really nothing new in the Sonarr config following,
      (Really, according to the Docker author, you should add the TZ variable to the deluge docker as well.)

      The correct entry, for your time zone, can be found here-> Time Zones in the TZ column.




      All locations were created and assigned the permissions, noted in the graphic WinSCP above, so I could browse to them. While it's not visible in this screen shot, again, I used the folder icon to "click navigate" to storage locations.
      (When a host path location is actually selected, the background turns a light yellow.)



      Let us know if this helps.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)

      The post was edited 2 times, last by flmaxey ().

    • gderf wrote:

      Why are you running that container as root

      I did notice the line in the deluge config - variables: PS1 : root@openmediavault:/$
      Is that what you're referring to?

      Frankly, I don't know. It's a default ev generated by the image. Since the image was written by linuxserver.io I didn't pay much attention to it.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • gderf wrote:

      I am referring to the container configuration environment variables where I see PUID 0
      While I know defining a "dockeruser" is best practice:

      To navigate to storage paths, external to the container, it's an access control item. The container, internally, has it's own root user.

      What do you suggest?
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • I suggest not running containers as root to get around problems with system storage path permissions and ownerships.

      Fix the permissions and ownerships of the storage files and folders instead so that you can run the container as an ordinary user, one that has the appropriate rights to the files and folders.

      PUID and PGID refer to a system user and a system group, not a user and group within the container.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • gderf wrote:

      I suggest not running containers as root to get around problems with system storage path permissions and ownerships.

      Fix the permissions and ownerships of the storage files and folders instead so that you can run the container as an ordinary user, one that has the appropriate rights to the files and folders.

      PUID and PGID refer to a system user and a system group, not a user and group within the container.
      I know, but I still don't see how setting a PUID turns over control of the container to the OMV root. The container has it's own root.

      Even if that is the case (where setting a PUID puts the OMV root in control of the container- versus the container's root), the assumption would have to be that there's a security gain, somehow, by not running the Docker container as the OMV root.

      While I've seen the recommendation, I can't seem to find anything, anywhere, that explains the "why" of it. Essentially, from a security viewpoint; there would be no difference between running the Deluge plugin, which is controlled by the OMV root, or a Deluge Docker run by the same.

      If I'm off base, can you point me to a reference?
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Update:

      In OMV, under Access Rights Management, User
      I created a user named dockeruser.
      The new user went into the users group by default.

      # id dockeruser , on the command line, shows the UID to be 1000.
      I set the PUID's in both containers to 1000 , rebooted, and tested.

      No permissions changes were required and it seems to work.
      (Edit - It's working fine - I'm pulling 2 big torrents and they're going to the right location.)
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)

      The post was edited 1 time, last by flmaxey: updated ().

    • I am not talking about the container or its root. I am talking about the container being able to have the read/write access to directories and files on the system's data storage drives it needs, outside the container, without having to be run as the system root user.

      You should never, ever run any process as the system root user unless it absolutely required. That includes docker containers. The security gain here is not allowing a container's processes be able to destroy your system.

      OMV's deluge plugin installs deluged and supporting files. It's up to the user to configure it and run it properly. I don't run it as root here. It's not necessary.

      On my OMV, I have myself as a user which is a member of the users group. All my docker containers run as that user and group. So does deluged which was manually installed. None of these things need to run as root, so they aren't.

      All of the data drives that these programs need access to have directories owned by this user and group with appropriate permissions. The folders and files within have the same ownership permissions on them.

      What if you were asking questions in some forum about some docker, and some user pointed you to an image that he claimed would solve your problem or otherwise meet all your needs. Suppose all it really did was format all your hard drives, but you didn't know that. It was cleverly designed to misbehave unless run as root, so you did that................ Now what?
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • majorpayne wrote:

      sigh, now i'm getting 192.168.0.15 refused to connect. when attempting port 8989 or 8112
      Well, this thread is convoluted, but I think it contains what is needed to get your dockers running, while taking care of @gderf 's security precaution. (He's right about giving a container the potential to navigate all of the host's files and folders.)

      First, the file permissions you've already set on your folders (Fileserver and Downloads) will work as they are, but I'd give thought to changing them to those pictured in post 49.

      While noting the need to create a dockeruser and the change of PUID entries, etc., in post 56, - post 49 should get things going.

      Before getting carried away with a lot of container folders;
      I'd do the default required folders first, and add more as needed after getting the containers on line.

      ___________________________________
      ___________________________________

      While it's no longer relevant to getting your configuration up and running - just trivia:
      Using Symlinks does work with both dockers. With Symlinks, Deluge can write files to /Downloads, on the data drive, without PUID and PGID entries (no host permissions at all). However, Sonarr is picky. Sonarr requires PUID and PGID entries, regardless. It crashes without them.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • An easy way to visualize this is to determine what user:group on the system has sufficient rights to access the files and folders that a docker needs to read and write to. Then just run the container as that user:group.

      And no, root does not count :)

      All my data drive directories and files are owned by the only user I created on the system - myfirstname, who belongs to the users group. So, all my dockers run with PUID: myfirstname and PGID:users.

      This isn't something I had to force things into or reconfigure to get dockers working. The directories and files had that ownership and permissions long before I ever got started with dockers.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I have it mostly working now. Sonarr is speaking with Deluge and Jackett. Deluge is saving the file to the proper place. Sonarr is not even attempting to check for the download show. I'm very close now.

      EDIT: Ok found out that a permission was missing and it made the group 911 which i assume means help something is wrong?

      I changed it and now it's able to move/extract the file.

      The post was edited 3 times, last by majorpayne ().