Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Jahf

  • Rank
  • Birthday 06/17/1972


  • Gender
  • Location
    near Seattle, WA
  1. Problem: Deluge plugin selection preferences not saving state between startup/shutdown Background: Setting up Deluge + Sonarr + Radarr for the first time (new to Unraid and Dockers, but not completely new to Linux ... console is familiar to me). I've got things running. Sonarr's happily plugging away, Deluge is downloading on command, Radarr will be next. Detail: Problem I'm seeing is that the setup I'm following needs the "label" plugin. That works fine when enabled and Sonarr is sending the labels. But whenever I restart the Deluge docker ... it comes up with the Label (and Extractor) plugins disabled again to where I have to manually set them back on. SOME preference states are saved fine between sessions. My Queue settings are definitely at the values I set rather than the defaults. It seems to just be the plugins that aren't staying enabled. Any hints as to what I need to do? PS. I found a post on a non-unraid forum where the user was recommended to use the "Connection Manager" "Stop Daemon" to stop the docker (in the case of Unraid this would be instead of using the "Stop" command on the Docker screen) to save preferences. However this gives an error and ... since other preferences are saving ... doesn't seem to apply here as a need.
  2. Necro. Sorry. I almost posted on the original thread ... https://forums.unraid.net/topic/80192-better-defaults/ but this seems the better place to take the idea forward. Coming from a long history of working on similar projects (not recently ... but as far back as working at Cobalt before they were bought by Sun). I completely agree that running Dockers/VMs as unprivileged users as well as running commands through sudo with an unprivileged admin were things I just sort of expected to find when I started with Unraid recently. There've been a couple of comments from Lime that make me worry. * It's "an Appliance" so lower security than a custom built server is expected. Yes. But Internet appliances have been around a long time and there are appliances going back to the late 90s that did more in regards to user privileges (Cobalt Qube and Raqs were actually built to fulfill the place a modern Unraid system fits a user today). Dockers didn't exist back then but the concepts aren't that much different than breaking out of a virtual web site and gaining access. VMs existed back then but weren't used in the same ways they are now. * 'It shouldn't be possible to "break out" of a container and as far as I know this isn't possible. Otherwise it will be a security vulnerability of Docker itself.' Sure. Same can be said of running a web service as root. If the service is vulnerable and broken, the vulnerability is the fault of the service. It's the job of the host to use sane defaults to proactively limit the damage done if it happens. Not to the point of making the system arcane to work on ... but 'sudo' and wheel groups aren't arcane, they're well documented for decades and these days it's actually weird to not need to use them. And as pointed out in the original thread, there have been at least proof of concept attacks against Docker. At that point companies have 2 directions to go: "Docker's fault, sorry" or "no worries, even if it happens we've done the work to protect you". I DO know the pain that can be caused to your support group if you change some basic paradigms. Going back to Cobalt for a second, our first generation of appliances were not secured well and we had to make some core changes. That changeover was full of support calls. But ... this was back when things weren't well documented on the Internet and most users had never even heard of Linux. Once that process was done supports' life, as well as the consumers', was much much easier. Because most day to day problems simply didn't occur anymore. In reading a number of replies from Lime it really feels to me like there is an inherent inertia involved because of the hesitance to change a long established product. I get that. I get it well enough that I'm not expecting these changes to be made. But I can still hope for them. I can make some of the changes I feel are needed (disabling Telnet, SMB v1, changing root password) very easily. Other things like making Unraid support a non-privileged user to run specific highly integrated tasks? No way. And ... I'm a brand new user. I bought my Pro license a day ago after configuring everything and knowing what I was getting into. So I'm 100% not saying Unraid isn't a good product. I'm just saying the security could improve. I would never expect these types of core changes in a point patch. I don't expect them in the next major patch. I'm just lending a voice to consider them at the point where the next major release is defined after this point to consider them.
  3. New Unraid system. Just converted my LSI 9211-8i to the IT firmware. In researching how to do that I came across various threads from 2-5 years back that state the newer LSI firmwares aren't working with TRIM and the drivers in Unraid. I'm going with the assumption I'm fine putting the SSD cache on the motherboard controller (Z78 chipset, SATA III 6Gb/s). But if that adds a noticeable load and/or lowers transfer rates I might re-wire and check to see if the LSI TRIM issue has been fixed.
  4. Ouch. That nixes this system for me then until I figure out an alternative card. Ok. Thanks. edit: found a M1015 card and a couple of fan out cables, on the way now. The reason I was originally asking was I wondered if splitting parity across 2 controllers might help with writes. But in looking at my motherboard, the onboard Z68A controller is SATA-2 so if I need to avoid the Marvell I'll be putting everything on the M1015.
  5. I'm gathering up the remaining bits to convert my previous desktop to a first Unraid server. The 2 questions I've got before ordering my last stuff: Dual NIC config: I'm hoping there's no big issue with utilizing the dual NICs on the Unraid box, 1 dedicated to my desktop PC, other going to home router for media? Dedicated link to desktop would be on a different subnet. Upgrade to 2.5Gb: My new desktop has a 2.5Gb/s ethernet port. My main use for connection to this system is going to be storing finished photos and on-going 3D projects. Possibly using a Git server. Is it worth getting a cheapish RT8125 based 2.5Gb PCIE card for the Unraid server for the dedicated connection? I'm keeping costs low for this initial build so not going to be able to buy 2x 10Gb solutions, I'm mostly asking how Unraid performs with the 8125 driver, which seems to be pretty new. I'm guessing I'll be alright with the split 1Gb solution I already have, just curious. Which SATA controller to put the Parity on: The Unraid server (specs listed below) has 2 separate SATA controllers, the built-in chipset controller and a Marvel controller. Is there a recommendation to put both parity on the same controller, or split them between the 2? Similar question for connecting the cache SSD. Unraid server parts: MSI Z768A-GD80 (B3) i7-3770K 32GB RAM LSI SAS9211-8I controller (skipping motherboard controllers based on feedback) 2x HGST He8 8TB 7200 for parity (overkill for 2x data drives, but open for later expansion) 2x WD Red 8TB 5400 for data 1x Samsung EVO 860 1TB for cache/dockers SanDisk Cruzer Micro 8GB USB2.0 drive (other older hard drives not listed since I'm going to test them significantly before re-using) GTX 1060 6GB, no other PCIE currently Obviously the MB and CPU are older, if things go smashingly I may upgrade the Unraid server hardware later on, but right now I want to get familiar before deciding on the cost benefit.