For the past few days I've had problems with my server dropping offline when I'm trying to watch Plex remotely.  At the same time, I'd also lose ability to Chrome Remote Desktop into a Win 10 ComputeStick that I use at the same location.  So whatever's going on it's not just with unRAID, and at first I just thought it was random problems with the ISP.  But when I finally checked the unRAID logs tonight it looks like I might be be being hacked as there are a zillion connection requests and "received disconnect"'s from unknown IPs.  So I've changed my router username and password credentials but is there anything else I should be doing to protect myself from whatever is going on?  Can anyone decipher the attached log file to tell me what to make of this?  Thanks in advance for any help.

jbox-syslog-20160901-2154.zip

For the past few days I've had problems with my server dropping offline when I'm trying to watch Plex remotely.  At the same time, I'd also lose ability to Chrome Remote Desktop into a Win 10 ComputeStick that I use at the same location.  So whatever's going on it's not just with unRAID, and at first I just thought it was random problems with the ISP.  But when I finally checked the unRAID logs tonight it looks like I might be be being hacked as there are a zillion connection requests and "received disconnect"'s from unknown IPs.  So I've changed my router username and password credentials but is there anything else I should be doing to protect myself from whatever is going on?  Can anyone decipher the attached log file to tell me what to make of this?  Thanks in advance for any help.

Is the server in your router's DMZ?

Is the server in your router's DMZ?

 

Hi Squid.  No the ComputeStick was in the router's DMZ but the server wasn't.  For the server there was port forwarding set up for all incoming IPs to port 32400 for Plex and the Firewall Security Level was set to off (something I definitely don't remember doing).  When I changed the router username and login I also turned off the port forwarding and DMZ and set firewall security to high.  If there's anything else I should be let me know.

 

Now I've got another problem though.  I was also running a parity check last night (started before I got clued in to all of this) and this morning when I woke up it had completed with 345966099 errors, all on disks 5&6.  And though it's telling me parity is valid and all drives are green balled, there is no temp read on drives 5&6 from the main page, attributes and capabilities on those drive pages say cannot read and trying to pull smart reports for them also isn't working (see attached).  Also all dockers (Plex, plexWatch, and BTSync) now say not available.  Finally I can't pull a new log either.  Looking at the system log through the UI only shows me 8/28 to 8/30 (prior to the log posted yesterday which starts from 9/1) and ends with the line "Fatal error: Allowed memory size of [16GB] exhausted..."  The only thing I can see for new log info that includes the parity check activity is when I click the log icon in the top right but that's just a snippet.  I've attached it here too FWIW since there's no download icon available on the log page to get anything more than this.

 

So I'm assuming at least drives 5 and 6 are probably borked at this point but I'd really like to get some guidance before I do anything else at this point. Any advice?

Disk5_sdh_9-2-16.txt

Disk6_sdi_9-2-16.txt

syslog_partial_9-2-16.txt

Both disks dropped offline, not very likely to get 2 bad disks at the same time, so powerdown and check cables/enclosure/controller.

Both disks dropped offline, not very likely to get 2 bad disks at the same time, so powerdown and check cables/enclosure/controller.

 

Right.  That explains it.  The SATA controller card must have become unseated.  That would explain why my dockers aren't available either, since the 2 SSDs of the cache pool are attached to the same card as those 2 drives while everything else is attached to a SATA port on the motherboard (and checking since you mentioned it I can't see temps or disk attributes for the SSDs now either while I can for everything else).

 

Question though:  once I fix that and power up again is there anything else I need to do other than to run a new parity check?  I assume the last check completing only after disks 5 & 6 dropped off must have re-written parity across only the drives that were attached, so parity for the entire array won't actually be valid.  So if there's anything I should check first or anything required beyond a regular parity check in order to correct that, I'd appreciate knowing the steps or what to look out for.  Thanks.

Are you sure it actually completed the parity check? Your complete syslog might help.

Are you sure it actually completed the parity check? Your complete syslog might help.

 

Well it says it completed (with 345k+ errors) and that parity was valid after.  Then again it also showed disks 5 & 6 (and the cache drives) as green balled when they were actually disconnected and didn't show up as missing until I stopped the array to power down.  So maybe it wasn't accurate that the check completed either?  Come to think of it, what would be the expected result if 2 data drives disconnected during a parity check?  I assumed that writing corrections to parity would entail that parity for those 2 drives be erased while parity for the remaining drives be rewritten across the remaining drives in the array (ie. parity may be valid but only for the rest of the array minus the 2 missing drives).  If that's not what happened and the parity check & corrections didn't even complete, then would that make any difference as to what to do after I re-seat the SATA card and power up to start the array again?  Either way parity for the entire array can't be valid at this point so I should either be prompted before I start the array that parity is going to have to be re-written in the process, or if there is no prompt then I should still immediately run a new parity check anyway to accomplish the same result.  Is that correct or is there something I'm missing?

 

As for a complete syslog, I would have like to have posted that too but as I mentioned in my previous post, after the parity check the usual link to download the log .txt had disappeared and the log link in the upper right only returned the snippet that I did post.  If there was some other way to pull a complete log it's academic now since I've already powered down.  If it would help though I'd be more than happy to post a new log after I boot up again and before I take any further steps.

If all disks are green and you can start the array run a parity check.

 

If there is one or more disable disk check SMART, if everything looks OK do a new config and parity sync.

If all disks are green and you can start the array run a parity check.

 

If there is one or more disable disk check SMART, if everything looks OK do a new config and parity sync.

 

Thanks, I was wondering if a new config might be the approach instead.  Will follow your advice and let you know how it goes.

If all disks are green and you can start the array run a parity check.

 

If there is one or more disable disk check SMART, if everything looks OK do a new config and parity sync.

 

Alright I re-seated the SATA controller and all disks were present and green so I ran the parity check per your advice.  It completed finding 102 errors but unlike last time no disk errors reported.  So I immediately ran another parity check behind it hoping this time it would find 0 errors and I'd know everything was good.  Nope.  Same 102 errors.  Checking the attached log, the errors are exactly the same sectors (and it's not just 102 either since that's only the point where it says it stops logging them).  So what now?  I see a few error messages in the log but I don't know make of them.  Does it look like there's still a problem w/the controller card, or with the parity or one of the data drives (even though they're all green)?  Should I try a new config to completely re-write parity? Thanks again for your help on this.

jbox-syslog-20160906-2036.zip

That looks like the problems some users have with the SAS2LP, if you don't run VMs try disabling VT-D in the bios, if you can't or it doesn't improve consider getting a different controller, preferably one LSI based.

That looks like the problems some users have with the SAS2LP, if you don't run VMs try disabling VT-D in the bios, if you can't or it doesn't improve consider getting a different controller, preferably one LSI based.

 

I'll try the BIOS thing first but I may not be able to get out to do it for another week or 2.  Should I worry in the meantime that parity isn't actually valid even though it says it is?  All the data is backed up to another remote server but I'd rather not have to deal with a drive failure on this server if it's not clear I'd be able to recover it from parity.