GalaxyBird

Members
  • Posts

    9
  • Joined

  • Last visited

Everything posted by GalaxyBird

  1. Thanks again for the reply! With respect to your comment on "disable spin down" - I interpret this to mean going to -> http://tower/Settings/DiskSettings and setting Default spin down delay: to Never - is that what you mean? I'm reading up on the plug in here, and that seems like a better option.
  2. Hello! My unraid set up shut down some time last spring, and wouldn't boot up again. I assumed (and hoped) it was an issue with the power supply. This past weekend, I finally had time to swap it out (550w up to 750w). One small heart attack with the root password later, I as back up and running. I started up the array and initiated a parity check which passed without any issues. My Fix Common Problems plug in was also out of date, so I updated that, and still have a number of items to work through there, but I've had three instances of the system shutting down for no reason that I can tell. I'm in a pretty cool basement, and temperatures of the discs seem to not be an issue at all. I took a look at this post - and this issue has happened when I don't have a terminal session open and implemented the recommendations around shutdown timing there, but the issue is still occurring. (I also don't have VMs running, so I assume that timing change doesn't apply to my situation but I did it anyway. I set up log mirroring and have attached a log file that goes over one of the shutdowns. I tried to look through the logs myself, but I'm not familiar enough yet with the output to draw conclusions. Something that stood out, is that this item occurs 18,195 times ``` Nov 30 10:20:17 Tower emhttpd: error: mdcmd, 2723: Input/output error (5): write Nov 30 10:20:17 Tower kernel: mdcmd (18193): spindown 4 Nov 30 10:20:17 Tower kernel: md: do_drive_cmd: disk4: ATA_OP e0 ioctl error: -5 Nov 30 10:20:18 Tower emhttpd: error: mdcmd, 2723: Input/output error (5): write Nov 30 10:20:18 Tower kernel: mdcmd (18194): spindown 4 Nov 30 10:20:18 Tower kernel: md: do_drive_cmd: disk4: ATA_OP e0 ioctl error: -5 Nov 30 10:20:19 Tower emhttpd: error: mdcmd, 2723: Input/output error (5): write Nov 30 10:20:19 Tower kernel: mdcmd (18195): spindown 4 Nov 30 10:20:19 Tower kernel: md: do_drive_cmd: disk4: ATA_OP e0 ioctl error: -5 ``` before the logs went quiet for ~24 hours, so I think this led up to one of the restarts (not certain about that though). If I'm reading correctly, it might be saying there is an issue with disc 4 of the array? That disc says its passed the SMART health status, but maybe it's still unhealthy I've got logging going, so I'm going to try and keep a closer watch on the time the next shutdown occurs, and upload a log file that's definitely leading up to the restart. Thanks for any input and help! syslog.log
  3. Where's the right place to see when this container image is ready to upgrade to the next version of plex? Or is there is a good place with a "how to" on how to/when to upgrade the container version to get the upgraded plex version?
  4. Does the interval work like A or B? Example, using the default 1800s (30min) A. Executes on everything new in the watch folder, once every 30 minutes B. Executes on one new file in the watch folder, waits 30 minutes, executes on a 2nd new file, continues, until no new files
  5. Hello! I'm struggling with the final 5% of setting up YaRSS2 with my binhex-DelugeVPN docker container. I've followed the steps detailed here: I've been able to successfully set up the client deluge (getting passed all the Python version fun that is posted about everywhere), and the connection to the Server/Container deluge. Then I get a bit confused about what I should be seeing. My understanding is that I'll *never* see YaRSS2 config in the Docker container WebUI. However, when I'm on the non-server "thin" client, and I set up an RSS, with the connection manager pointed to the Docker container server, it just downloads to the client machine... which isn't what I want. This sorta seems obvious when I look at the Download config of the client Deluge installation - it's pointed at the local machine. But my confusion is around how these steps were to set up RSS for the server. Am I missing something? Is it impossible to have RSS driven downloads in the Docker container? or have I just missed the last few steps of config? One step that I wasn't quite sure if I achieved, was that installing YaRSS2 on the windows client is supposed to *also* install it on the server somehow? (See quote below) - https://dev.deluge-torrent.org/wiki/Plugins/YaRSS2#RunningaserverseedboxwithaDelugedaemon I'll keep investigating on my own, but if someone has any guidance or tips, I'd greatly appreciate it! Thanks!
  6. My partner actually just suggested restarting but with only 7 drives active. So a parity + 6, and then adding the 7th later once I've got a working cable (or have assessed the issue is with the NAS case backplane possible?). Is that feasible? Looking around, it seems like re-creating the bootable drive is the key ( ) but I'm not sure if I need to do that or not. I certainly don't need to follow data loss precautions since all of these drives are fresh.
  7. Hello! Just tried setting up unraid for the first time ever, and when I turned it on, the parity drive immediately went into a disabled state. I ran a read-check wondering if maybe the Parity drive just starts in a failed state until you've completed the first check. Unfortunately, that didn't fix it. I turned off the computer and checked all of the power and data connections, rebooted, and still the same issue. I then swapped out the drive for an alternate, and tried to restart the array with the new parity drive and it failed immediately as well. I then swapped the SATA cable with one of the other drives, and that drive that was now on the "bad cable" was then in a failed state. I've ordered a replacement cable, but wanted to post my logs here to see if there was something else I should be trying to do