Force NVME hard drive out of read-only mode, in linux

Question

A recently-purchased NVMe hard drive has put itself into read-only mode after roughly a day of use. It appears to be a bad drive (based on output from smartctl), and I'm happy to replace it and not worry too much about it.

However, while there wasn't anything particularly sensitive on the drive (I can change a couple of passwords), I'd feel better about sending it back to the manufacturer if I could first get it out of "read-only" mode and write some zeroes over it.

Is this a possibility? I don't need the drive to be reliable, and I don't need it to be resilient against sophisticated attacks, I just want to make it so my data isn't sitting one mount command away from whoever next has the device, without physically damaging it.

(note, the very-similar question, Get a drive out of the read only mode, had only non-answers saying not to bother / it's really broken. I accept that the device is really broken, I'd just prefer "one last write" before I exchange it)

$ udisksctl status
MODEL                     REVISION  SERIAL               DEVICE
--------------------------------------------------------------------------
WDC WDS200T2B0C-00PXH0    21705000  2117DP459510         nvme0n1

$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     2117DP459510         WDC WDS200T2B0C-00PXH0                   1           2.00  TB /   2.00  TB    512   B +  0 B   21705000

$ sudo smartctl -a /dev/nvme0
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.8.0-55-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       WDC WDS200T2B0C-00PXH0
Serial Number:                      2117DP459510
Firmware Version:                   21705000
PCI Vendor/Subsystem ID:            0x15b7
IEEE OUI Identifier:                0x001b44
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          2,000,398,934,016 [2.00 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            001b44 4a46f7edaf
Local Time is:                      Fri Jun 11 22:02:14 2021 BST
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size:         128 Pages
Warning  Comp. Temp. Threshold:     80 Celsius
Critical Comp. Temp. Threshold:     85 Celsius
Namespace 1 Features (0x02):        NA_Fields

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     4.10W    2.90W       -    0  0  0  0        0       0
 1 +     2.70W    1.80W       -    0  0  0  0        0       0
 2 +     1.90W    1.50W       -    0  0  0  0        0       0
 3 -   0.0250W       -        -    3  3  3  3     3900   11000
 4 -   0.0050W       -        -    4  4  4  4     5000   39000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
- NVM subsystem reliability has been degraded
- media has been placed in read only mode

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x0c
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    24,177 [12.3 GB]
Data Units Written:                 119,045 [60.9 GB]
Host Read Commands:                 333,086
Host Write Commands:                2,380,870
Controller Busy Time:               3
Power Cycles:                       12
Power On Hours:                     30
Unsafe Shutdowns:                   0
Media and Data Integrity Errors:    1,164
Error Information Log Entries:      1,165
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

Answer 1

I just ran into the exact same situation recently, and did some research on this issue. Hopefully it could help someone came to this thread from the search engine.

Basically there are three things you could try.

1. dd

Yes, this might work even if your disk is reported media has been placed in read only mode. However, chances are that dd won't be able to write through the whole disk. In my case, the dead SSD would always drop offline after a certain amount of write. However, it is sufficient for breaking the partition table and file system metadata, preventing someone else from easily mounting the drive.

In case your drive is so broken that it couldn't even stay up for more than a few KBs of writes, you may also consider locating and wiping the sensitive files only, such as passwords, which is more likely to succeed.

2. Secure Erase (SE)

Depending on whether your drive is SATA or NVMe, you may want to try ATA Secure Erase for your SATA drive and NVMe Secure Erase for your NVMe drive as described in the links. Both of them are easy to follow and worth a try.

3. Drive Sanitization

An alternative to 2. is the ATA Sanitize for SATA drives and NVMe Sanitize for NVMe drives. However, it is not likely to work if 2. already failed. Still worth a try though.

If non of the above worked, there's not much you could do then. If you do feel unsafe about leaving all the data in (or if you are really paranoid), please just give up RMA or returning and go buy a new drive. Your data must worth more than a few hundred bucks, right?

Answer 2

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x0c

The drive's firmware itself switched the drive to read-only mode.

In this case 0C > 00001100 > bits 2 and 3 are set. We can look up their meaning in this table:

Bit 0: If set to ‘1’, then the available spare capacity has fallen below the threshold
Bit 1: If set to ‘1’, then a temperature is (> over temp threshold) or (< below temp threshold)
Bit 2: If set to ‘1’, then the NVM subsystem reliability has been degraded due to significant media related errors or any internal error that degrades NVM subsystemreliability.
Bit 3: If set to ‘1’, then the media has been placed in read only mode
Bit 4: If set to ‘1’, then the volatile memory backup device has failed. This field is only valid if the controller has a volatile memory backup solution.

See: https://media.kingston.com/support/pdf/ssd-smart-attribute.pdf for more info.

According the the NVMe spec the drive is supposed to ignore all write commands.

Source: https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf

So no amount of formatting will solve this. Format implies a new file system is written to the drive, and these writes will simply be discarded. The same goes for zero-filling using dd or whatever tool you prefer to write zeros to the drive.

You can try if Western Digital specific tools (Western Digital SSD Dashboard) will allow you to perform a secure or crypto erase.

In brief erasure options are:

• Wipe mapping tables. This makes data recovery theoretically possible using high-end equipment
• Wipe mapping tables and erase data. This would make data recovery impossible, takes most time out of the 3 options.
• Crypto erase. This would make data recovery impossible and is fastest.

Note that not all drives will offer all three options.

If these options fail to 'erase' the drive then you'd have to decide to hang on to the drive or send the drive as is.