I had three Seagate model ST10000NM0016 HDDs in an array on a TrueNAS server. I did not set up SED. After a power failure I couldn't access two of them. I just get an input/output error. Ran smart test on them and no issues were found. Started to do some more digging and when using openSeaChest_Security I found out two of the three were ATA locked. The other I'm having no issues with. I have no idea why a power failure triggered this since I never set up ATA security or SED but here I am none the less. I do not know the password and I've tried all of the default passwords I can find on the internet. Mainly the "SeaGate" one and variations of it along with 25 spaces or periods. I am having no luck at all. I tried contacting Seagate but their support chat staff couldn't help me. The drives are out of warranty since I bought them refurbished from an Amazon seller back in August of 2023.

I'll attach one of the openSeaChest results for anyone wanting to look over it that can give me some ideas. At this point I'm ok with losing the data so if there is a way I can reset and format the drive I'm up for it. They have a PSID number on the front but from what I've looked up that doesn't help with an ATA lock, only SED. The drives were manufactured in March of 2017. The only possibility I've found is cobbling a serial reader together from an Arduino and hooking it up to the serial jumper pins on the back of the hard drive. I'd rather not lose the drives since they are around $200+ right now. I bought all three for $270 back in 2023. Damn chip shortage and AI!

Thanks in advance for any help!

Have you tried a PSID Revert or RevertSP? This only works with SEDs, but I can't understand why your non-SED model would have a PSID.

_________________
A backup a day keeps DR away.

Can you access the SMART attributes?

_________________
A backup a day keeps DR away.

I have not tried a PSID revert because I never set SED up on them and also when I do the sedutil-cli command on TrueNAS it notes that none of my drives have SED set up. This is the first time I've had to deal with this issue and from what I've learned the ATA security can work in tandem with SED or alone I guess.

I can access the SMART attributes. I'll attach the output from smartctl -x below. That's how I stumbled upon the fact that they were locked. I compared the working drive output to the two that didn't work and noted that it wasn't locked and they were. I also did long test on both and that returned no errors.

Edit: I reached out to the seller on Amazon and they offered to RMA the drives and give me a refund which is weird considering I bought the drives two and a half years ago. I'm assuming they have the ability to unlock the drives which they will do and then turn around and resell them since I only paid $80 a piece for them but the price has gone up to over $200 now for the same drives. If they resold just one of the drives they would be in the net positive money wise.

If master password revision = 0xFFFE... Security erase command witch master password... All data will be lost!
Google:

Master password: .(without quotes)

https://www.seagate.com/www-content/pro ... 91104e.pdf

I forgot the most important thing: the Security status shouldn't be Frozen. The OS freezes it when mounting.

The drive is NOT frozen and the Master Password Revision is 65534. I'm going to try and use hdparm to do a secure erase.

So update time. I ran hdparm with the --security-erase argument and it actually worked! I have no idea how long it took because I started it before going to bed and worked the next day so it was like almost 34 hours before I checked it. One down and one to go. I'm running the command again on the second hard drive. Hopefully it works with no issues. I'll check back in when it's over.

On a side note I believe this is normal behavior but for anyone that comes after me the command will lock your terminal up until it's over. Make sure you do it with SSH instead of the CLI shell in the webGUI. I ended up losing connection because of the built in time out. However the command did complete successfully anyways so I guess I got lucky or maybe because the process was already running so it didn't immediately terminate it, I'm not sure. From what I've read and I'm sure someone here can correct me if I'm wrong but the command actually runs on hard drive controller itself and hdparm is just waiting to get a reply back from the controller that it completed so maybe killing the process doesn't matter. I'm not sure, I'm just glad it worked and I have my drive back.

The exact command used is "sudo hdparm --user-master u --security-erase p /dev/sdX". Sudo and hdparm are self explanatory. "--user-master u" tells it to use the user account and not the master. "--security-erase p" tells it to start the secure erase using "p" as the password. This password can be anything you want. If something like a disconnect or power failure occurs you would use this password to restart the process. "/dev/sdX" is the drive as listed in lsblk. For me it was "sdp" but it will probably be different for you.

So that's the long and short of it. If I've made any mistakes I'm sure someone will let me know. Hopefully this reply will be followed another saying I was successful with the second drive also.

The process is performed by the disk controller. It's convenient to monitor it using the "Busy" signal in the HDD status register. However, very few people know how to do this today...
If the power is accidentally turned off, you need to restart the process and, preferably, remember the password.

Success! I lost the data on the disk but I have it backed up various other places. I just need to track everything down and copy it back over.