Squid

Don't know why this is (assuming you're running AD), but every minute on the minute, the system is changing the permissions on your downloads share. It appears that you started the check @ 2:04pm on the 12th. It got through the first 4 TB 12:39 am. At that point, CA Auto Turbo Mode kicked in and started to enable / disable turbo mode depending upon your drives spun up. At 8:38 am on the 13th the parity drive decided to drop offline, but it recovered and came back no problems right way. Problem being with this is that the permissions being changed every minute *may* cause a drive to spin up for unRaid to find the /mnt/user/Downloads share. I'm surmising this because auto turbo keeps enabling / disabling turbo mode, which means that a drive is spinning up/down. Its possible the spin ups that are giving you the problems, as very often with controllers all transfers to/from other drives attached will pause until the drive being spun up is up to speed. (which takes a couple of seconds). Turbo mode being enabled / disabled shouldn't account for any significant slowdown itself.

I actually thought it was after due to all the "Too Many Files Open". But, since the syslog has been rotated too many times and is now truncated a reboot, wait for the problem to reoccur then immediately posting a new set of diagnostics would help because we'd be able to see what happens prior to all those errors occuring

Nothing on my end.

The "CAUGHT" thing is because "screen" isn't running. Don't worry about it. At the end of the day, you're going to be better off with a simple powerdown -r Because It almost everything listed in the script. (Notable exception is killing screen, but you can have the Tips&Tweaks plugin do that for you at shutdown / restart) Does it correctly, in the correct order, and is not tied to the setup of the script creator (IE: its not stopping VMs, unmounting the docker image (problem if it exists on an array drive)) There's probably a ton more that it does that this script doesn't do (eg: stops mover if its running prior to umounting the drives) Is updated accordingly as unRaid changes / evolves Won't affect anything. Its just UD not deleting the folder it creates for its mounts Create a separate thread for this. Include your diagnostics. People that are most capable of helping you are not going to see this in a thread subject of Stopping The Array from the CLI Certainly looks that way (but could simply be cabling). But, see the line above. Other Comment: The very rare times that I get the webUI stuck on unmounting drives, its usually because I've got an SSH session open to /mnt/user/... which will definitely prevent a umount. Closing the session fixes that. Even rarer, when for whatever reason an application has crashed and left a file open preventing a umount via GUI / CLI powerdown I simply reset the server. (And then cancel the parity check. - All the applicable services have already been stopped, No apps should be left running, the file systems have already been synced. IE: No parity Check errors should result)

You're better off switching to DJoss' version as that seems to be the solution to the black screen issue from reading here. See the post above yours

The execution order is Button (JavaScript) -> Wrapper (PHP) -> Actual Script (whatever interpreter you choose) or via a scheduled script, Wrapper (PHP) -> Actual Script The actual scripts are scripts as in something you would run from the command line (ie: bash, PHP, python, etc) Nothing is stopping you from using curl in bash or in PHP. You could probably do it via JavaScript by installing nodejs via the NerdPack This is all for background tasks. You can however run JavaScript & any HTML via a foreground script. See that PacMan additional script

Its up and running now. Time for the Shake Your Head Moment. Using @CHBMB unRaid DVB plugin I worked my way backwards through all of the stock RC images, deleting the appdata along the way. None of them worked until I hit RC11 at which point everything as far as I can tell worked perfectly. At that point, I worked my way back up through the RCs testing (and deleting appdata along the way). They all worked including RC15 So, for the hell of it I deleted the docker.img, recreated, reinstalled everything (deleting MKVCleaver's appdata) and it still worked. I know that my upgrade path originally was RC9f to RC12 so perhaps something changed very slightly in the image that caused these problems. Either way, since I'm now at the point that its basically impossible for me to recreate the problems, I'm now at a standstill. Net result is that if anyone has the problem with just a black screen appearing, the solution is to delete the docker.img and reinstall the apps.

HUGE progress. Gimme a bit to narrow this all down further though.

Solution: https://forums.lime-technology.com/topic/57181-real-docker-faq/?page=2&tab=comments#comment-608304

Gimme a bit to finish up something on FCP before I revert and confirm (Taking advantage of this issue with MKVCleaver to add another test to FCP that I never actually thought was going to happen)

No change No change Also ran as privileged. No change

Delete Appdata, Fresh Install, All defaults MKVCleaverLog.txt PID USER TIME COMMAND 1 root 0:00 s6-svscan -s -t0 /var/run/s6/services 32 root 0:00 s6-supervise s6-fdholderd 496 root 0:00 s6-supervise app 501 root 0:00 s6-supervise nginx 502 root 0:00 s6-supervise openbox 503 root 0:00 s6-supervise xvfb 504 root 0:00 s6-supervise x11vnc 505 root 0:00 s6-supervise wineserver 671 daemon 0:00 s6-fdholderd -1 -i rules 713 root 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx 728 root 0:00 /usr/bin/Xvfb :0 -screen 0 1280x768x24 747 root 0:00 [s6-notifyonchec] 751 nginx 0:00 nginx: worker process 752 nginx 0:00 nginx: worker process 753 nginx 0:00 nginx: worker process 754 nginx 0:00 nginx: worker process 758 root 0:00 s6-supervise logmonitor 759 root 0:00 s6-supervise statusmonitor 760 root 0:00 s6-supervise certsmonitor 768 root 0:00 /usr/bin/x11vnc -display :0 -rfbport 5900 -rfbportv6 -1 - 782 app 0:00 /usr/bin/wineserver --foreground --persistent 792 app 0:00 /usr/bin/openbox 808 app 0:59 /opt/mkvcleaver/MKVCleaver.exe 836 app 0:00 {services.exe} C:\windows\system32\services.exe 840 app 0:00 {winedevice.exe} C:\windows\system32\winedevice.exe 852 app 0:00 {plugplay.exe} C:\windows\system32\plugplay.exe 867 root 0:00 ps -A

I'll do what I can. Just let me know Other investigations: Running RC15e it doesn't matter what you enter in for the host path on /storage. It never works cd /storage from docker exec works fine MKVCleaver and wine is running according to top VNC to port 7912 also results in a black screen Other thoughts 6.4 is compiled to allow execution of 32bit binaries within docker containers (I see that you're running wine64, but the lack of 32bit binaries was what previously stopped wine from executing on unRaid

https://forums.lime-technology.com/topic/57181-real-docker-faq/#comment-564345

This is the thread for MKVCleaver

Why are some of my applications randomly stopping and won't restart? (unRaid 6.4+ with Unassigned Devices mounting SMB shares) Several possible reasons for this: Corrupted or full docker.img file -> covered elsewhere in this FAQ Corrupted files in the appdata folder -> may be easiest to simply delete the appdata and start over again But, this FAQ entry will deal with another possibility. You're using the unassigned devices plugin to mount a remote share via SMB hosted on another server or computer and have passed that mount to the docker application in question. (If you're not using UD to mount a remote smb share none of this applies to you You will notice this in a few different ways After attempting to restart the application you will get a rather vague "Server Execution Error" appear You syslog may contain the following entries Nov 11 18:20:14 Test kernel: CIFS VFS: Error -104 sending data on socket to server Nov 11 18:20:14 Test kernel: CIFS VFS: Error -32 sending data on socket to server From the command prompt an "ls" command will return "Stale File Handle" when attempting to list the contents of the remote share Instead of restarting the container you edit it, make a change, revert the change and then apply you will see the docker run command which will fail with an error of Stale NFS file handle The solution is within Unassigned Devices' settings to Force SMB Mounts to use SMBv1 This problem isn't limited to docker containers itself though. It is a consequence that not all systems will properly support SMBv2/3, and those mount points you made in unRaid & Unassigned Devices may become unavailable over the network or to any application.

Any progress on this problem?

If you have Fix Common Problems installed, then Tools - Docker Safe New Permissions If you don't have it installed, then Tools - New Permissions, and make sure to only run it against the share that you're having trouble with Going forward, use a UMASK value of 0 in nzbget's settings (Security, umask) (at least I've never had a problem with a setting of 0) But, assuming that you have the far more common problem of Sonarr / Radarr etc have moved the file into place and then you can't do anything with it, within those apps you set (under show advanced settings) permissions on the moved / written files to be 0777

lol. Now that's A1 support on a commercial product You've got this problem Dec 9 20:04:42 server-pc kernel: ata5.00: disabled followed by a million errors of Dec 11 08:50:44 server-pc kernel: sd 5:0:0:0: [sdf] tag#8 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 11 08:50:44 server-pc kernel: sd 5:0:0:0: [sdf] tag#8 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 The drive dropped offline (possibly due to cabling being loose, etc) Is this an unassigned device or something (ST3000DM001-1CH166_Z1F24MMQ ), as its not assigned to the array so far as I can tell.

IDK Once in a very blue moon I get the same thing. Usually I just manually move the file to the array, and delete the movie from the wanted list. Probably you're going to be best off hitting the support threads on Radarr's site.https://radarr.video/#support

Understand. Why I asked if you were using it.

But what about this aka drone factory

Did Radarr grab the files and send them to the DL client? Or are you manually adding the NZBs to the DL client? Are you using Radarr's Blackhole to import the files?

Close All Notifications only closes the notifications that are posted on the screen. It doesn't close them all if there are multiple pages of them. Could also be corruption on the flash drive. Are you able to save a file onto the flash drive without any errors?

Because this plugin doesn't directly execute any script. It calls a proxy which then executes the script. Net result is that you will never see an email from cron that the return code from your script was non zero. Any notifications you want from your script you will have to do via the notify commabd And via basically adding the cron entry yourself as you were you were getting an email that your script returned a non zero return value (ie that it failed or had an error) return values of zero (success) don't send an email