tnorman

Perhaps I'm wrong. I know i looked at each drive's settings. Maybe I just putting apply/done before moving to the next drive didn't do anything. Or maybe I just forgot to do it.

Very possible. The funny thing is I went in to every disk and checked the value to see what it was set at and then set it. I didn't even think about going into the default value.

Yep. That solved it. Setting a value other than the default in the settings->disk settings for disk warning to something other than 45. I'm running a parity check. It paused at 11% when a disk reached 44. Figured I'd reply here in case someone else sees this thread. Thank you.

I sent you the files via a direct message since they appear to contain some private info.

I'm now on version 2021.06.04 I just ran a test and it paused again when the disks were at about 30- 32 degrees Celsius. I stopped the parity check... well actually stopped the array by accident. Meant to stop the parity check. But restarted the array and the parity check was stopped. I started a debug written to the flash drive. I then started a new parity check. It paused again at about 0.3% "Following drives overheated: parity(31C) disk1(32C) disk2(31C) disk3(32C) disk4(32C) disk5(30C) disk6(33C) disk7(29C) disk8(32C) Correcting Parity Check (0.3%% completed)" Attached is the debug log

I'll look into that. I have the plugin in to auto update the plugins running, It's saying I'm up to date. Hmmmm.....

It was intentional. It's set to -1. Only reason was because I was trying to trick it into running longer since it was cutting off while the drives were still temperature wise just fine. The negative value didn't seem to help much though. Think I'll reset it back to 2 which I think was the default.

I'm using Unraid version 6.9.1 2021-03-08 with the Parity Check Timing version 2021.05.14 I turned on the logging. I then started a parity check. It ran for a few minutes and then it was paused by the plugin. About 20 minutes passed by and it did not restart. I ended up cancelling the parity check and turning off logging. The end file is what I've attached. I

Issues with the temperature pausing/restart. It's pausing when disks are still in normal temp range. I started using this plugin because I had a case that I had neglected and needed to finish a parity check before cleaning it out. I don't have AC in the room the computer normally runs, so I figured this would also help with those upcoming hot summer days/nights. Run it at night to do parity checks and pause in case there is a heat issue. Anyway, I replaced a drive and I'm trying to a do a rebuild on the drive. But it keeps pausing the rebuild even though temps are no where near the warning state. (I have a warning temp on all drives of 113 Fahrenheit or 45 Celsius.) It was also doing the same when it was running the parity check. It would pause when temps were still well below, though now it seems even more sensitive when running the rebuild. The plugin is set to pause at -1 (so 114 Fahrenheit or 46 Celsius) and restart at 8 degrees below the warning temp. (105 Fahrenheit or 37 Celsius). Assuming I have those numbers accurate in what I understand from this forum and the help info, then it's pausing when the disks are well below those temps. I had my system set to Fahrenheit. I changed it to Celsius to see if that would affect the problem since I saw a few posts back that you suggested it incase the default wasn't set. But it doesn't seem to matter. (Though with Celsius and now doing a rebuild, it seems almost more touchy than it was when it was set to Farenheit during the parity check.) The latest pause pushed out this notification: Parity Check Tuning: 2021-06-01 13:35 [TOWER] Pause Following drives overheated: parity(31C) disk1(31C) disk2(32C) disk3(28C) disk4(29C) disk5(31C) disk6(31C) disk7(26C) disk8(31C) Parity Sync/Data Rebuild (2.0%% completed)" I cleaned out the case and removed the dead fan that was the primary culprit of the heat issue I was having. I'm not sure why it's stopping as you can see none of the drives are overheating. I would think it would just tell which drive was overheating and not push out info for all 9 drives, but it's saying all 9. If I can help provide anything else, please let me know. I've actually disabled the temp pause feature for the time being so the rebuild can continue, and it's been running with the temperature of the drives staying pretty consistently well below 32 Celsius. But I've got more changes to the system coming. (Replacing another fan, replacing another drive, maybe adding a second parity drive, assuming I can find a way to power an extra drive... honestly I'm running out of room in my current case, so I'm not sure yet... but I know I need some more space coming up. But I'm rambling now... lol. ) Thanks for the plugin, and I appreciate your continued work on it.

I must have unplugged the cache drive from power as I was trying to locate wires for the fans. Plugged it back in and it is running an extended self check right now on it.

I didn't even look at the cache drive. I'll take a look. Thank you!

The Unraid system ran a Parity check which passed. I had turned off all normal running dockers. So I restarted them about 12 hours after the system had finished the parity check. As the the dockers started back up I got 12 read errors on one my oldest hard drives. The array stopped. And then I got a notification that everything returned to normal from Unraid. I've left the array stopped as my disk 4 has a red X for disabled and is being emulated. I checked the disk status and ran a extended status on it. Everything looks fine to me. I'm not seeing a red flag besides the age of the drive in the diagnostics, but I may be missing something. I'm wonder if it might have just been a cable connection problem. I've been trying to solve a heat issue that has suddenly come up over the past month where the machine shuts down for some reason. I currently have the case open with a large fan blowing straight on it, so I figure wires might have been jiggling a bit? I'm not sure. I found it odd that Unraid reported the problem and then said everything was okay, but I assume that was because it was now emulating the disabled disk. Could someone take a look at the diagnostics and see if I'm missing something. I actually saw some read errors on another drive that is the same make and just as old, but it isn't giving issues. I'm planning on replacing a couple drives, possibly 3 of the oldest drives, just because they are running pretty high in hours usage. Or I might just add a parity disk so I have 2 instead of one in case 2 drives fail. Haven't decided yet. It depends on if I need to replace the current disabled drive. Thank you for your help! Edited: Removed diagnostic files.

Thank you. This info might be good to add to the initial post in this topic so it is easier for people to find. I was considering doing that already because I found that docker as the only listed one in CA for Resilio Sync. Thank you again.

Question on Resiio sync. Has the docker been updated recently? I noticed when I go into the WebUI that it is telling me to update to the latest version. The docker running shows it is using version 2.6.3 (1340). I don't see an update when I check the unraid docker page. Just wanted to verify that it hasn't been updated yet. I think the newest version is 2.7.2 (at least that is what it running on my windows machine). Thank you.

K. I didn't check the change log. Thank you for the info. So just got told by the Fix Common Problems plugin that newransomware.bait.plg is deprecated. "This plugin has been deprecate and should no longer be used due to the following reason(s): While this plugin should still be functional, it is no recommended to continue to use it."

Wondering if someone can help me out. Fix Common Problems fired off and told me I had an unclean shutdown as well as hardware error. I've attached a diagnostics of the server. Perhaps you can point me to where to start looking. So much information. I've attached the anonymized version here. I thought I heard the server reboot yesterday and then I got a parity check started notice (which ran and found no errors). When I went to check the server today Fix Common Problems recommended I seek help for a hardware error issue. I'm not sure what would have caused the restart as nothing was going on with the system that I know of at that time of day. I'm assuming this restart was the unclear shutdown the Fix Common Problems plug in was referring to. And as far as hardware error, so far I've only found a reference to "mcelog: ERROR: AMD Processor family 21: mcelog does not support this processor. Please use the edac_mce_amd module instead." But I don't know of a way to use that module on unraid. I'm not seeing a plugin for it or a way to easily add it. Thanks for your help in advance! tower-diagnostics-20180710-1146.zip

So just got told by the Fix Common Problems plugin that newransomware.bait.plg is deprecated. "This plugin has been deprecate and should no longer be used due to the following reason(s): While this plugin should still be functional, it is no recommended to continue to use it."

BTW the attack history shows this: (i've removed part of the ip address which actually corresponds to my main computer. And I changed the username to tempuser. Not sure why it is reporting this user but it is the only one I regularly use for transfering via Samba.) Time Of Attack:Sat, 07 Jul 2018 06:01:32 -0600Attacked File: /mnt/user/BackupbyCABackup_usb/.SquidBanking-DO_NOT_DELETE.xlsxSamba version 4.6.12PID Username Group Machine Protocol Version Encryption Signing----------------------------------------------------------------------------------------------------------------------------------------2997 tempuser users 192.168.*.*(ipv4:192.*.*:56861) SMB3_11 - partial(AES-128-CMAC)Service pid Machine Connected at Encryption Signing---------------------------------------------------------------------------------------------IPC$ 2997 192.168.*.* Fri Jul 6 17:13:32 2018 MDT - -No locked files

Got hit with what I think was a false positive this morning at about 06:01:32. I think a bait file suddenly disappeared while unraid was running Community Applications appData Backup. It reported a possible attack on /mnt/user/BackupbyCABackup_usb/.SquidBanking-DO_NOT_DELETE.xlsx When I look at the log, I noticed Community Applications appData Backup started running at about 0600 at this was in the log. The only line in the system log around that time referencing that folder is this: Jul 7 06:01:31 Tower CA Backup/Restore: Using command: /usr/bin/rsync -avXHq --delete --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" /boot/ "/mnt/user/BackupbyCABackup_usb/" > /dev/null 2>&1 I'm not 100% familiar what it being done on this line, but after looking up the options for rsync it appears the destination folder has any extraneous files removed by the --delete option. So I assume what happened is the backup was removing the bait files in the folder when it backed up to that share, causing a report of ransomware. Odd that this action hasn't happened before though the backup is set to run at 0600 on the 7th day of every month... so the program is expected to run. I just never had a ransomware attack notice before. Wondering if one of the programs was recently changed and caused the new notice with a change in something I'm adding the folder to the exclude from placing a bait file in the folders. Thought that was already set, but I guess I didn't. Am I correct in what looks to be the cause of this notice?

Thank you. I was getting the same error for the Krusader docker. I was staring at the information for the past 2 days trying to figure out what it wanted me to change. Changed /mnt/disks/ to RW Slave (it was RW prior) and the error went away. Sometimes things are as intuitive as some people think they are and we just need a slap on the back of th head. Tim

The extended test finished with no real other information to provide. No more read errors so far. I did notice the sata cable was at a slight (very slight) angle, so I pushed it firmly on.

You are right. I was totally reading it wrong. I saw the 140 under Thresh and somehow thought that was the count. I have no idea how I did that. Slap my forehead moment. I was able to get the system log out. Long weekend and I'm dead tired today. Sort of freaked out when I initially found there was an error during parity check. I forgot I could download the log or telnet in and get part of it off. I think the log is so huge that http sort of barfed and assumed nothing was happened after X seconds passed. In Chrome and MS Edge it kept wanting to kill the process going on. I'm just guessing at that since I reopened Opera browser which was my last attempt to get the log and there it was when I opened the browser. I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or didn't like me putting the case back together last week. I think the slow down for the parity check was just because of dockers running. One is Crashplan and it is uploading a ton so it is constantly running. Probably the extra disk access from that just slowed down the parity check. Thanks for the help. I'll do the diskspeed.sp once I finish the extended test. I've attached the syslog.txt which has the errors for the disk in it. there are 2 other sys log files if desired. Let me know if those will help. But I agree I'm not overly concerned with read errors. My initial thought was that there were sector errors, but it doesn't look like it was the issue. syslog.txt

I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or something. I think the slow down for the parity check was just because of dockers running. One is Crashplan and it is uploading a ton so it is constantly running right now. Probably the extra disk access from that just slowed down the parity check. Just guessing tho. My concern is a fairly new drive with reallocated sector count. I know some will happen, but 140 reallocated sectors seems large to me. The extended test should give it a thorough run thru if it is checking every sector all over again. Thanks for the help. I'll do the diskspeed.sp once I finish the extended test.

Wow the extended self test is taking a long time. The short test is attached here at least. Overall health test passed. but it did have those errors. WDC_WD30EFRX.txt

It's pumping along now since I stopped the 2 dockers. At 93.8. I'll run a diagnostic once it finishes and post it.