Can a "read-only" µSD card be salvaged?

Question

A µSD card that was in a security camera suddenly stopped recording:

• Much of the data is gone (not a problem).
• The data that is still there is correct and readable.
• The card now always mounts as read-only, (on Chromebook, Windows, and Ubuntu).

I can't reformat it or do much of anything with it:

$ df
/dev/mmcblk0   vfat          117G   15G      102G  13% /media/ray/xxx

$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 116.1 GiB, 124657860608 bytes, 243472384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

$ sudo fsck /dev/mmcblk0
fsck from util-linux 2.34
fsck.fat 4.1 (2017-01-24)
open: Read-only file system

$ sudo hdparm -r0 /dev/mmcblk0
/dev/mmcblk0:
 setting readonly to 0 (off)
 readonly      =  1 (on)
$ sudo hdparm -r0 /dev/mmcblk0
/dev/mmcblk0:
 setting readonly to 0 (off)
 readonly      =  1 (on)

$ sudo fsck /dev/mmcblk0
fsck from util-linux 2.34
fsck.fat 4.1 (2017-01-24)
open: Read-only file system

$ sudo umount /media/ray/xxx
$ sudo mount  -o rw  /dev/mmcblk0  /media/ray/xxx
mount: /media/ray/xxx: WARNING: device write-protected, mounted read-only.

Note that this is not a full-sized SD card; there is no physical write-protection switch.

Is the card salvageable, or garbage?

Answer 1

Your SDcard has reached end of life. It will always be read only from now on. This is a protective mechanism when the controller detects the SDcard is not safe to try to write any more data to the card, Due to checksums mismatch. It does this to preserve your existing data. This is permanent.

You need to buy a new SDcard.

From this Source

Answer 2

Given the cost of a new card, trying to override the EOL lockdown seems like a bad idea. Reusing this card will risk further data loss.

The card went read-only and this allows you to rescue whatever was on the card at the time, which is a great design feature. I had a 16 GB card in a Pi, and I was able to dd the dead card to a new card, which booted up fine after an fsck and the host continued on working.

Additionally, a tool like photorec can scan the disk and potentially read some deleted files too. However video files tend to be large and that decreases the chance of recovery.

Other options might be for you to consider a better way of dealing with this video data. Perhaps stream it off to a NAS or DVR/NVR where it is written to a hard drive? I have network cameras that are read continuously by motion which detects movement via inter-frame differences and saves video where changes are detected.

Depending on the brand of camera, you may have further options about shifting content out of the camera.

Perhaps this camera is solar and has no network, so local storage is your best option. In that case, buy the largest card you can afford so there are more blocks total, and also look at the "industrial" cards which are rated for more resiliency. A "pMLC" card is Pseudo MLC and only uses the top and bottom two cells in a quad cell block, which adds resiliency at the cost of space, and cost.

Answer 3

I'm not sure that what has been answered here is entirely accurate. There's a lot more functions than can be done on an SD card than what can be done through the file system and block device interface, especially the security operations. The SD Association (the club that you must join to access the specifications and use the SD logo) has a tool called "SD memory card formatter" and that can be used (with most SD card slots) to give commands to the SD card that are not part of the normal block device interface.

I used to work in embedded electronics and I've rescued many locked SD cards with the SD formatter tool. It's available at https://www.sdcard.org/downloads/formatter/

Answer 4

Pretty much possible, using the right tools.

A modern flash storage consists (logically) of a raw storage and a translation/wear levelling layer that exposes addressable R/W blocks to the host while doing a lot of algorithmic magic to the raw storage. The important part is, the raw storage is somewhat bigger than the exposed size (10-20-30% are common).

The important part of the magic is that it controls the health of each block and when some block is not usable anymore, you get less space to do the magic. One needs at least one "erase block" (this is multiple of the read/write block size, e.g. the read/write sector is 512 bytes and the erase block is e.g. 64MB) worth of free space in order to be able to write to the flash at all, and a lot more in order to write to the flash with a consistent write speed.

When you are out of free space in the raw storage layer, you cannot write. On the other hand, you are still able to read from the media.

What is pretty much possible in this case is to declare the usable size to be less than the original. E.g. a 32GB SD card that is out of free healthy blocks (and became read-only) can be reprogrammed to be 20GB or 16GB and have a great deal of extra blocks to work in.

On the other hand, there is no standard interface for doing this.

You need the manufacturer's software tools that are in the general case not freely distributed, but can be found at obscure .cn or .ru websites that are not indexed in the common search engines. In some cases, you also need to alter the card reader as well.

Answer 5

Depends on why it's read only.

It may be failing.

Or one of the two designed-in read only bits may have been set. This is a rarely used feature, but with direct access to the card it is possible to set either temporary or irreversible read-only status. There is sample code on GitHub illustrating how to do this. (I've been looking at possibly using it in conjunction with an "immutable" Linux build as a way of getting additional security.)

Note that you can't access these bits through the usual USB card readers/writers

So: if the temporary r/o bit has been set, and if you have suitable hardware, you may be able to reset it. But the odds of that being what happened are pretty darned low.