Cessquill

Because mine's on a spinner drive I'm guessing that may be because I'm on a spinner drive. As such, I've set nzbget not to start subsequent jobs until the current one is finished. The drive activity of an unpack and a new download at the same time would make everything crawl (likely set when I was running WD Green drives at a lower spin rate). The only reason I've watched the file folder was when trying to work out what was going on (has it died)? Like I say, could be my setup - it's quite low spec, and I'm pushing harder than perhaps it wants.

For a sanity check, are we talking about when a process no longer has a time remaining value and watching the file in the unpack folder keeps cycling from zero to full size? I'm not watching the docker, but quite often when I take a look first thing in the morning there's an item unpacking with a couple behind it, and a restart sorts it out straight away.

I'm still getting unpacking issues on latest (haven't updated to the no reminder one yet). I'm also noticing that some files fail, but if I push them through again they come down fine. Finally, files seem to occasionally switch to "queued" before resuming. Could be my setup though - I'm on an old unassigned non SSD drive that used to be part of my array, and I've just migrated firewalls. The unpacking part is better though, since it would sometimes take several restarts to get it going again, now it unpacks straight away. Seemed to happen when there was a bit of other activity on the drive.

Sent you a message

If you need to refer to this post, I've added a section at the bottom of the first post with just the required commands (as I've needed to refer to this several times). I've also added "./" to the start of all commands as that's now needed in the current version.

Well, after flashing the onboard LSI 2308 with the latest IT firmware (it was old and IR), Disabling EPC & Low Current Spinup on all Ironwolf drives (regardless of whether they were the models affected), and waiting, I've had no more drive issues. Everything spins up and down normally again. Thank you for your time and advice.

I have an extra one in my config, but this could be from an outdated template. See below... This points to an unassigned drive since - as @alturismo says - it spins up often, together with the parity drive, so I took it off the array

As a thought, I was searching yesterday and discovered that the onboard LSI 2308 was running old firmware in IR mode... LSI Corporation SAS2 Flash Utility Version 12.00.00.00 (2011.11.08) Copyright (c) 2008-2011 LSI Corporation. All rights reserved Adapter Selected is a LSI SAS: SAS2308_1(Rev 5) Controller Number : 0 Controller : SAS2308_1(Rev 5) PCI Address : 00:02:00:00 SAS Address : 5003048-0-11b9-9100 NVDATA Version (Default) : 0f.00.00.12 NVDATA Version (Persistent) : 0f.00.00.12 Firmware Product ID : 0x2714 Firmware Version : 15.00.00.00 NVDATA Vendor : LSI NVDATA Product ID : SMC2308-IR BIOS Version : 07.29.00.00 UEFI BSD Version : N/A FCODE Version : N/A Board Name : SMC2308-IR Board Assembly : N/A Board Tracer Number : N/A Finished Processing Commands Successfully. Exiting SAS2Flash. The last version I could find was 20.00.07.00. Regardless of whether it fixes my issues, would it be recommended to upgrade to the latest version and switch over to IT mode? The motherboard preceded switching to a SAS backplane, and since it worked I didn't give it a second thought. @JorgeB - in researching I also found your excellent post about flashing firmware, thank you

Thanks, I've set the spin down delay to never. I'm hoping it's not a further LSI/Ironwolf issue, since all drives have the fixes (and the drive that dropped off, and previously disk 19 are ST8000VN0022 which didn't initially suffer from that). That said, if it's not that I'm stuck. The PSU should cope with all drives turning on.

Hi - ongoing issue that I'm trying to diagnose. Once every week or so a drive will randomly drop off the array. Not the same drive - appears to be random (from what I can tell). See first diagnostics taken just after it happened this morning. When it does happen, I can stop VM and all dockers, but I can never stop the docker or VM services (pizza wheels for a long time). Following that, I can not stop the array with the GUI. See second diagnostics taken automatically because I have to give it an unclean shutdown over IPMI. Points to note All data drives (except Parity & SSDs) are connected to a SAS backplane It seems to be an Ironwolf drive that drops off (although I am aware of the LSI issues with them and have set up the drives as per recommendations) Every time it happens I can not stop the array I have no idea what it could be with this, and would really love to solve it - it seems to be running a drive rebuild a lot of the time unraid1-diagnostics-20230919-1021.zip unraid1-diagnostics-20230919-1125.zip

@Squid - For me at least, I get the following error on page load... (Chrome) ace.js:1 Uncaught TypeError: Cannot set properties of undefined (setting 'packaged') at o (ace.js:1:144) at ace.js:1:1594 at ace.js:1:1612 o @ ace.js:1 (anonymous) @ ace.js:1 (anonymous) @ ace.js:1 dynamix.js?v=1680052794:5 jQuery.Deferred exception: ace.edit is not a function TypeError: ace.edit is not a function at HTMLDocument.<anonymous> (https://192-168-1-10.878757bd53f71ad14272183dbae65d47ceb4439a.myunraid.net/Settings/Userscripts:1218:20) at e (https://192-168-1-10.878757bd53f71ad14272183dbae65d47ceb4439a.myunraid.net/webGui/javascript/dynamix.js?v=1680052794:5:30310) at t (https://192-168-1-10.878757bd53f71ad14272183dbae65d47ceb4439a.myunraid.net/webGui/javascript/dynamix.js?v=1680052794:5:30612) undefined E.Deferred.exceptionHook @ dynamix.js?v=1680052794:5 t @ dynamix.js?v=1680052794:5 setTimeout (async) (anonymous) @ dynamix.js?v=1680052794:5 c @ dynamix.js?v=1680052794:5 fireWith @ dynamix.js?v=1680052794:5 fire @ dynamix.js?v=1680052794:5 c @ dynamix.js?v=1680052794:5 fireWith @ dynamix.js?v=1680052794:5 ready @ dynamix.js?v=1680052794:5 $ @ dynamix.js?v=1680052794:5 dynamix.js?v=1680052794:5 Uncaught TypeError: ace.edit is not a function at HTMLDocument.<anonymous> (Userscripts:1218:20) at e (dynamix.js?v=1680052794:5:30310) at t (dynamix.js?v=1680052794:5:30612) ...and then when clicking on edit script... Userscripts:1491 Uncaught TypeError: ace.edit is not a function at Object.success (Userscripts:1491:24) at c (dynamix.js?v=1680052794:5:28599) at Object.fireWith [as resolveWith] (dynamix.js?v=1680052794:5:29344) at l (dynamix.js?v=1680052794:5:80328) at XMLHttpRequest.<anonymous> (dynamix.js?v=1680052794:5:82782) Hope this helps.

First port of call - change your PiA credentials - you've just posted your username/password. I'm guessing you've upgraded to Unraid 6.12.x? I haven't but the posts directly above yours are reporting issues.

How are you accessing Nextcloud remotely? In my case, I route through NginxProxyManager, and I needed to set the below in the Advanced tab... ...it's mentioned near the bottom of the docs https://docs.nextcloud.com/server/20/admin_manual/configuration_files/big_file_upload_configuration.html?highlight=max upload size#:~:text=The default maximum file,2GB on 32Bit OS-architecture (note, I set this up several years ago, and can't remember whether there was anything else. If you're routing via a different method, I'm not sure but would guess it's something similar)

I have mine set as a single disk cache pool

I may have got this *completely* wrong, but my understanding of Unraid Dockers for this situation is this... All variables/paths, etc. are created when you initially install the docker. Your template is a snapshot of what the author specifies at that time (which you can further edit as you wish). If the author edits, adds or removes options further down the line, your settings are not affected when you update. For example, I manually added a transcode folder at some point., and I'm not sure how an update would handle this. If this is completely bad information, someone let me know and I'll delete it. Don't want bad advice in searches.

Yep, that was the first of two commands in the script, the second one is the one I use. I can't quite remember, but I *think* the rem'd out command was the one to use in general Docker circumstances, and the second one the script actually uses is for Unraid.

If you just mean running the Nextcloud's cron tasks periodically, I have the following in the User Scripts plugin set to run every 5 minutes #!/bin/bash #docker exec -u www-data Nextcloud php -f /var/www/html/cron.php docker exec Nextcloud php -f /var/www/html/cron.php exit 0 Disclaimer: this was set a fair while ago, and aside from updating the docker I haven't been diving too deep into Nextcloud, just using it.

This thread is for the linuxserverio version of the Plex docker. You've got the plexinc version there. Also, it looks like you're transcoding directly to your array, which I would have thought would be a nightmare.

I'm not sure whether this fix applies to your situation, but I hope your system is more stable now. I've not had another issue since this thread was created, but there may be different issues with different LSI cards - not sure.

Yes. I have the former (a script that puts the Nvidia card into power-save mode). It's duplicated so that it runs on array start, and then hourly. (from a SpaceInvaderOne video)

Yes, but on large libraries you're talking about hours every backup where dockers are off while millions of files are backed up (I estimate that due to backing up my entire Plex folder, my dockers are down for around 10 days every year). Additionally, the amount of storage these files take to back up. Touch wood, I've not had to restore Plex before, but I've refreshed all metadata before and it's not the end of the world.

Thanks for this - had the same problem when upgrading, although I'm not sure whether it didn't coincide with Windows updates, as I reverted back to 6.11.1 from a Flash backup and still couldn't access the shares. Adding "ntlm auth = Yes" fixed it for me.

Fair enough. In my circumstance, the specific configuration of a proxy host in NPM required the site it was pointing at to be running before it would start. If you're sure that's not the case I'll butt out.

Check what other dockers NPM relies on (specifically, more complex sites configured). When I was running a site (the Jitsi docker, I think), if it wasn't running then NPM would never start. If Jitsi was running, NPM would start fine. My guess is that CA is correctly starting NPM, but NPM is shutting itself down, as something it relies on is not present. A few notes: I had this a few years ago, but no longer needed Jitsi (if it was that), so didn't find a solution. I don't know whether CA Backup/Restore adheres to the docker system's ordering and delay options when restarting containers. It's easy to test - shut down dockers one at a time that NPM is linked to and restart NPM. If it doesn't restart with a specific docker stopped, it's likely that this docker is not (fully) running when NPM is restarted following a backup.