Hi checked my in on my unraid used for storage and noticed disk2 had 78 errors. Have attached smart log but going on my past experience with seagate drives (thankfully this is the last one in my array) I got a feeling this is failing and I should start pre-clearing a replacement asap.

 

However having said that on the disk2 page it does say "Last SMART test result: Completed without error "

SMART looks OK. If you haven't rebooted go to Tools - Diagnostics and post complete diagnostics zip and maybe we can get a better idea what caused the errors.

There are no pending sectors, but it does look like a disk problem, you can run an extended SMART test to confirm:

 

SMART Attributes Data Structure revision number: 10

Vendor Specific SMART Attributes with Thresholds:

ID# ATTRIBUTE_NAME          FLAG    VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  1 Raw_Read_Error_Rate    0x000f  109  099  006    Pre-fail  Always      -      23322288

  3 Spin_Up_Time            0x0003  095  093  000    Pre-fail  Always      -      0

  4 Start_Stop_Count        0x0032  094  094  020    Old_age  Always      -      6959

  5 Reallocated_Sector_Ct  0x0033  100  100  010    Pre-fail  Always      -      0

  7 Seek_Error_Rate        0x000f  072  060  030    Pre-fail  Always      -      20212771

  9 Power_On_Hours          0x0032  071  071  000    Old_age  Always      -      25811

10 Spin_Retry_Count        0x0013  100  100  097    Pre-fail  Always      -      0

12 Power_Cycle_Count      0x0032  100  100  020    Old_age  Always      -      39

183 Runtime_Bad_Block      0x0032  100  100  000    Old_age  Always      -      0

184 End-to-End_Error        0x0032  100  100  099    Old_age  Always      -      0

187 Reported_Uncorrect      0x0032  096  096  000    Old_age  Always      -      4

188 Command_Timeout        0x0032  100  100  000    Old_age  Always      -      0 0 0

189 High_Fly_Writes        0x003a  099  099  000    Old_age  Always      -      1

190 Airflow_Temperature_Cel 0x0022  068  060  045    Old_age  Always      -      32 (Min/Max 23/37)

191 G-Sense_Error_Rate      0x0032  100  100  000    Old_age  Always      -      0

192 Power-Off_Retract_Count 0x0032  100  100  000    Old_age  Always      -      25

193 Load_Cycle_Count        0x0032  066  066  000    Old_age  Always      -      68584

194 Temperature_Celsius    0x0022  032  040  000    Old_age  Always      -      32 (0 18 0 0 0)

197 Current_Pending_Sector  0x0012  100  100  000    Old_age  Always      -      0

198 Offline_Uncorrectable  0x0010  100  100  000    Old_age  Offline      -      0

199 UDMA_CRC_Error_Count    0x003e  200  200  000    Old_age  Always      -      0

240 Head_Flying_Hours      0x0000  100  253  000    Old_age  Offline      -      3305h+59m+45.854s

241 Total_LBAs_Written      0x0000  100  253  000    Old_age  Offline      -      12983154309

242 Total_LBAs_Read        0x0000  100  253  000    Old_age  Offline      -      258875691197

 

SMART Error Log Version: 1

ATA Error Count: 4

CR = Command Register [HEX]

FR = Features Register [HEX]

SC = Sector Count Register [HEX]

SN = Sector Number Register [HEX]

CL = Cylinder Low Register [HEX]

CH = Cylinder High Register [HEX]

DH = Device/Head Register [HEX]

DC = Device Command Register [HEX]

ER = Error register [HEX]

ST = Status register [HEX]

Powered_Up_Time is measured from power on, and printed as

DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,

SS=sec, and sss=millisec. It "wraps" after 49.710 days.

 

Error 4 occurred at disk power-on lifetime: 25697 hours (1070 days + 17 hours)

  When the command that caused the error occurred, the device was active or idle.

 

  After command completion occurred, registers were:

  ER ST SC SN CL CH DH

  -- -- -- -- -- -- --

  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:

  CR FR SC SN CL CH DH DC  Powered_Up_Time  Command/Feature_Name

  -- -- -- -- -- -- -- --  ----------------  --------------------

  25 00 10 ff ff ff ef 00  29d+12:02:04.252  READ DMA EXT

  25 00 18 ff ff ff ef 00  29d+12:02:04.236  READ DMA EXT

  25 00 00 ff ff ff ef 00  29d+12:02:04.214  READ DMA EXT

  25 00 00 ff ff ff ef 00  29d+12:02:04.208  READ DMA EXT

  25 00 00 ff ff ff ef 00  29d+12:02:04.205  READ DMA EXT

 

 

PS: Even if it was a disk problem it can now be OK and pass the extended test, just had a similar issue recently with one of my disks, if it passes I would give it a second chance, but not a third.

I saw the hours, but thought it might be useful to get info about his other drives in case a different one is more in need.

 

bally12345, if you post your diagnostics we will have the rest of your drives SMART.

Thanks guys I should know by now to post diagnostics!!

 

I remember having to replace another seagate drive and im thinking to myself is it having the same issue.

 

PFA server-diagnostics

server-diagnostics-20170124-2114.zip

There's a lot of this in your syslog:

 

Jan  9 04:39:54 Server vsftpd[19873]: connect from 113.28.114.210 (113.28.114.210)

Jan  9 04:39:58 Server vsftpd[19914]: connect from 113.28.114.210 (113.28.114.210)

 

Were you expecting incoming connections from Hong Kong?

 

HK!? No WTH, its been up for 34 days, do I have a security issue? I have disabled FTP which but other than that nothing is exposed outside my LAN and when ever I do connect I use VPN and remote desktop to my local machine...

Not just Hong Kong. A lot of other places too. Since this seems to come as a surprise to you, and since they are all connecting to vsftpd, then I think you must be giving the world access to your files.

 

Close your ports!

 

 

Once you have taken care of that.

 

Your other drives look OK, and since the others are 4TB and the seagate is only 3TB, and they are all getting kind of full, I think I would go ahead and replace it with another 4TB.

Removed everything from port forwarding on my router and disabled FTP in unraid.

 

I wonder what they had access to I havent seen much in network traffic...

Here's an example of one that was successful:

 

Dec 21 22:31:21 Server vsftpd[27220]: connect from 86.12.185.69 (86.12.185.69)

Dec 21 22:31:21 Server vsftpd[27220]: [bal] OK LOGIN: Client "86.12.185.69"

Dec 21 22:31:42 Server vsftpd[27223]: [bal] OK DOWNLOAD: Client "86.12.185.69", "/mnt/user/D..o", 5481 bytes, 43.89Kbyte/sec

 

Do you recognise the IP address? It's a Virgin Media one. Was it authorised?

 

That is legit and I authorised. Anything else is concerning.

You shouldn't expose unRAID to the Internet - it isn't ruggedised. Use a VPN if you need access from the outside.

 

How about Russia?

 

Jan 15 10:39:39 Server vsftpd[20038]: connect from 91.226.143.232 (91.226.143.232)

 

113.28.114.210 and 91.226.143.232 are not authorised. Bloody hell nothing to do with TRUMP I hope! All kidding aside looks like something was going on on the 9th and 15th but was succesful connection made?

I haven't spotted any successful connections other than those you say are authorised. Have a look through your syslog and check for yourself. The examples above show what you're looking for.

 

I had a good look and couldnt find anything other than my own connections.

 

Did a extended smart test and no failures found, I have pre cleared another disk so I can make a quick switch if any errors pop up.