Storage Manager rejects new healthy disks as "Critical" because of "reset commands"?

[esbenvb]

I am trying to install a new HDD in my DS1515+. The hard drives are brand new Seagate Exos X.

I have bought 3 of these drives, and 1 of them works fine and is now part of my storage pool, but the other 2 gives me an error when I install them in the DS. The error is "Multiple reset command errors have occurred...".

From the Storage Manager, I cannot continue and the system won't let me intialize the disk to make it part of a storage pool. I've tried secure erasing one of the disks, with no luck.

I've looked in the dmesg output from the linux terminal of the DS, with no errors for the disks that cause me trouble.

But I can see in all the extended views that no errors regarding reset/reidentification/reconnection etc have occurred. So why is Storage Manager stuck on the Critical status?

Both disks work completely fine when connected to another computer, so I believe they are physically 100% OK.

I suspect that the disks are rejected by the DS because of some historic data. First, I tried connecting the two problematic disks using the 2 ESATA ports of the DS1515+, but the disks did never appear in the storage manager, and I saw some reset/connection errors in the dmesg log (using the linux terminal). This was probably because of older unstable ESATA cables. But my theory is that these events when the disks were connected by ESATA, has caused the DS to "blacklist" these disks, as they have once caused "reset commands" due to flaky cables.

How can I force the DS to accept these disk and let me use them? Is there a way to reset any historic knowledge about these disks, and let the DS re-evaluate them?

 

[esbenvb]

I managed to fix this myself. I was right about the assumption that the unstable ESATA connection a few days ago, made my NAS believe that the drive was faulty.

What I did to fix it:

root@diskstation:/# grep -r ZR52AGQE /var/*
...
Binary file /var/log/synolog/.SYNODISKDB matches
Binary file /var/log/synolog/.SYNODISKHEALTHDB matches
Binary file /var/log/synolog/.SYNODISKTESTDB matches
...

I dumped these databases to SQL files using the `sqlite3` commmand line tool, and imported the dumps in a DB on my laptop, and inspected the content.

Then I could see the events of the connections resets from the ESATA connection a few days ago int the logs table

Then I did this

root@diskstation:/var/log/synolog# sqlite3 .SYNODISKDB

DELETE FROM logs WHERE serial = 'ZR51TPNF';
DELETE FROM logs WHERE serial ='ZR52AGQE';

And rebooted the NAS - now it's rebuilding my storage pool to the new disk

 

[Robbie]

Excellent!

It has given me a few pointers too.

️

 

[neversc0t]

I managed to fix this myself. I was right about the assumption that the unstable ESATA connection a few days ago, made my NAS believe that the drive was faulty.

What I did to fix it:

root@diskstation:/# grep -r ZR52AGQE /var/*
...
Binary file /var/log/synolog/.SYNODISKDB matches
Binary file /var/log/synolog/.SYNODISKHEALTHDB matches
Binary file /var/log/synolog/.SYNODISKTESTDB matches
...

I dumped these databases to SQL files using the `sqlite3` commmand line tool, and imported the dumps in a DB on my laptop, and inspected the content.

Then I could see the events of the connections resets from the ESATA connection a few days ago int the logs table

View attachment 5514


Then I did this

root@diskstation:/var/log/synolog# sqlite3 .SYNODISKDB

DELETE FROM logs WHERE serial = 'ZR51TPNF';
DELETE FROM logs WHERE serial ='ZR52AGQE';

And rebooted the NAS - now it's rebuilding my storage pool to the new disk

Hello.
I'm also having this problem
The SMART test of my drive is OK, whether it's a quick test or a normal test, but Synology just won't let me create a storage pool for the drive. The brand of the drive is Seagate. I have followed the method you described and connected to the Synology host via PUTTY and showed the contents via grep file. And entered the command sqlite3 .SYNODISKDB
DELETE FROM logs WHERE serial ='S/N';
But the problem is still the same, I really didn't do the step of exporting the data from Synology to, is this a necessary step? Is there a step I'm missing?
Thanks!

 

[Telos]

Maybe change disk ID (if blacklisted by your NAS)
https://www.wintips.org/how-to-change-hard-disks-volume-serial-number-volume-id/

 

[esbenvb]

Maybe change disk ID (if blacklisted by your NAS)
https://www.wintips.org/how-to-change-hard-disks-volume-serial-number-volume-id/

Why do such things which probably voids warranty, when you can just remove the disk from the blacklist like I did in #2?