I have a brand new flash drive (one week old) that has become marked as read only, by Windows, Kubuntu and a bootable partitioner. Why did this happen? Is it fixable? If it is, how can I fix this?
The problem
Firstly, this drive is new. It's certainly not been used enough to die from normal wear and tear, though I would not discount defective components.
The drive itself has somehow become locked in a read only state. Windows' Disk management:
Diskpart:
Generic Flash Disk USB Device
Disk ID: 33FA33FA
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : Yes
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
What really confuses me is Current Read-only State : Yes and Read-only : No.
Attempted solutions
So far, I've tried:
Formatting it in Windows (in Disk management, the format options are greyed out when right clicking).
DiskPart Clean (
CLEAN - Clear the configuration information, or all information, off the disk.):DISKPART> clean DiskPart has encountered an error: The media is write protected. See the System Event Log for more information.There was nothing in the event log.
Windows command line format
>format G: Insert new disk for drive G: and press ENTER when ready... The type of the file system is FAT32. Verifying 7740M Cannot format. This volume is write protected.Windows chkdsk: see below for details
Kubuntu fsck (through VirtualBox USB passthrough): see below for details
Acronis True Image to format, to convert to GPT, to destroy and rebuild MBR, basically anything: failed (could not write to MBR)
Details (and a nice story)
Background
This was a brand new, generic, 8GB flash drive I wanted to create a multiboot flash drive with. It came formatted as FAT32, though oddly a little larger than most 8 GIGAbyte flash drives I've come across. Approximately 127MB was listed as "used" by Windows. I never discovered why. The end usable space was about what I normally expect from a 8GB drive (approx 7.4 GIBIbytes).
I had thrown quite a few Linux distros on, along with a copy of Hiren's. They would all boot perfectly. They were put on with YUMI.
When I tried to put the Knoppix DVD on, YUMI added an odd video option to its boot comman which caused Knoppix to boot with a black screen on X. ttys 1 through 6 still worked as text only interfaces.
A few days later, I took some time to take that odd video option off, making the boot command match the one that comes with Knoppix. On the attempt to boot, Knoppix reported some form of LZMA corruption.
Leading up to the current issue
I was thinking the Knoppix files may have been corrupted somehow, so I tried reloading it. The drive was nearly full (45MB free), so I deleted a generic ISO that also was not booting. That went fine. I then went through YUMI to 'uninstall' Knoppix, i.e. delete files and remove from the menus. The files went first, then the menus were cleared successfully. However, the free space was stuck at about 700MB, same as it was before removing Knoppix. In the old Knoppix folder, there was a 0 byte file named KNOPPIX that could not be deleted.
I tried reinserting the drive to delete this file - without safely removing, if that made a difference (hey, first time for everything). Running the standard Windows chkdsk scan without /r or /f reported errors found. Running with /r just got it stuck.
I decided to give fsck a shot, so I loaded up my Kubuntu VM and attached the drive to it with VirtualBox's USB 2.0 passthrough. I umounted it (/dev/sda1) and ran a fsck. There are differences between boot sector and its backup. I chose No action. It told me FATs differ and asked me to select either the first or second FAT. Whichever I selected, I got a notice of Free cluster summary wrong. If I chose Correct, it gave a list of incorrect file names. To try to fix something, at least, I ran it with the -p option. Halfway through fixing the files, the VM froze - I ended its process about ten minutes later.
Cause?
My next attempt was to use YUMI, again, to rebuild the whole drive. I used YUMI's built in reformat (to FAT32) option and installed a Kubuntu ISO (700MB). The format was successful, however, the extract and copy of Kubuntu (which YUMI uses a 7zip binary for) froze at about 60% done. After waiting for about fifteen minutes (longer than the 3.5GB Knoppix ISO took last time), I pulled the drive out. The drive at this point was already formatted, SYSLINUX already installed, just waiting on the unpacking of an ISO and the modifying of the boot menus.
Plugging it back in, it came up as normal - however, any write action would fail. Disk management reported it as read only. On reconnect, it would come up as normal but a write operation would cause it to go read only again. After a few attempts, it started coming up as read only on insertion.
Attempts to fix
This is when I ran through the attempts listed above, to try and reformat it in case of a faulty format. However the inability to do so even on a bootable disk indicated something more serious is wrong. chkdsk now reports nothing is wrong, and fsck still reports MBR inconsistencies, but now always chooses first FAT automatically after telling me FATs differ. It still does the same Free cluster summary wrong afterwards. I cannot run with -p anymore because it is now marked as read only. It also managed to corrupt my VM's disk somehow on the first attempt (yes, I'm sure I chose sda, which is mapped to a 7.4GB drive - I triple checked). Thank god for snapshots?
I'm just about out of ideas. To my inexperienced mind it looks like something in the drive's firmware set it to read only "permanently" somehow - is there any way to reset this? I don't particularly care about keeping data, considering I've reformatted it twice.
Also, fixes that keep me in Windows are better; it reduces the risk of me accidentally nuking my main hard drive.
Update 1:
I pulled apart the drive out of curiosity.
As you can see, there are no obvious write protect switches. There is an IC on the other side, ALCOR branded labelled AU6989HL, if that matters. If there appears to be no way to fix this, I'll probably pull out the (glued down) card and put it in a card reader to check if it's the card or the controller that died.
Update 2:
I've pulled the card off, Windows detects the drive as a card reader now. The contacts on the card don't appear to be used, and there are several rows of holes on the card itself. Putting it into the card reader only detects about 30MB total, RAW. It's probably either the original drive incorrectly reporting the card as faulty (as if a real SD card's write protect was switched on) or a bad contact somewhere.
If nothing else, I have a spare 8GB Micro SD card now... as soon as I figure out how to format it as 8GB. Which does not seem to be possible (Windows, Partedmagic, dd, DBAN... nope, still 30MB). Ah well.
Update 3
I had a few more of these. The second one failed similarly (read only) today. Out of the remaining, two were detected as empty card readers/unformatted drives, depending on shaking (faulty contact?). One was detected as 1/3 full, and had an odd volume name.
H2testw results (on the last fully working one I have!):
Warning: Only 7762 of 7812 MByte tested.
The media is likely to be defective.
7.5 GByte OK (15896472 sectors)
52 KByte DATA LOST (104 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
52 KByte corrupted (104 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000186003000
Expected: 0x0000000186003000
Found: 0x00200800c40c3061
H2testw version 1.3
Writing speed: 3.95 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4
While this is a little worrying, evidently the drives actually do have near-8GB capacity, as verified by a tool often successfully used to detect fake flash drives. The use of a Micro SD card rather than a marked flash memory module makes it near impossible to reflash the drive, since Alcor's drive flashing tools expect the memory model as a parameter. I think I'll just throw the whole lot out.
