I have a USB stick that appears to be write-protected. “fdisk -l” does not recognize it. But when I plug it in the device notifier mounts it, and I can read the files on it. If I additionally mount it manually it tells me it’s mounted write only. Yast won’t format it, neither will XP. Also “dd” will not write to it.
Any suggestions?
That is a bit contradictory. Please insert it mount it as you said using the device notifier and post
mount
and
fdisk -l
And, as you have two versions of openSUSE mentioned in your signature, that of course narrows it a bit down, but we still do not know which one you are talking about (my personal opinion: I hate it when people put those things in their signature).
Thank you for the speedy response.
Using openSUSE 13.1 64bit KDE Version 4.11.5
:~> mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=954860k,nr_inodes=238715,mode=755)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda2 on / type ext4 (rw,relatime,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=38,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda4 on /home/ion/DATA type ext4 (rw,relatime,data=ordered)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
gvfsd-fuse on /var/run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
/dev/sdb1 on /run/media/ion/KEY 1 type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdb1 on /var/run/media/ion/KEY 1 type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
# fdisk -l
Disk /dev/sda: 320.1 GB, 320072933376 bytes, 625142448 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
Disk label type: dos
Disk identifier: 0x000d150e
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 58593279 29295616 83 Linux
/dev/sda2 58593280 117186559 29296640 83 Linux
/dev/sda3 117186560 121092095 1952768 82 Linux swap / Solaris
/dev/sda4 121092096 625141759 252024832 83 Linux
Disk /dev/sdb: 7962 MB, 7962886144 bytes, 15552512 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
Disk label type: dos
Disk identifier: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sdb1 * 24 15552511 7776244 b W95 FAT32
Device Boot Start End Blocks Id System
/dev/sdb1 * 24 15552511 7776244 b W95 FAT32
So it is shown by fdisk -l (contrary to what you say).
/dev/sdb1 on /var/run/media/ion/KEY 1 type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro)
and it is mounted (by the desktop mechanism).
And it seems to be mounted read-only because there where errors.
Did you look what dmesg says after you inserted it?
BTW, please use normal CODE tags (the # button) as long as you do not want to show HTML code here.
Yes I agree. But several times when I plugged the stick in and did not mount with device notifier, “fdisk -l” did not list it at all. Also when I tried to mount it by “mount /dev/sdb1 /mnt/hd” it reported that /dev/sdb1 did not exist. Until I opened it with the file browser from device notifier (i.e. it got mounted). Then “fdisk -l” did show it. Now that is no longer the case. So perhaps there is a hardware inconsistency. The USB socket was my first suspicion, but it works with any other USB device. Still the inability to write to it continues.
That is correct.
dmesg reports…
7134.468036] usb 1-5: new high-speed USB device number 11 using ehci-pci
7134.583802] usb 1-5: New USB device found, idVendor=090c, idProduct=1000
7134.583810] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
7134.583816] usb 1-5: Product: USB DISK
7134.583821] usb 1-5: Manufacturer: SMI Corporation
7134.583826] usb 1-5: SerialNumber: HA08010000002269
7134.587827] usb-storage 1-5:1.0: USB Mass Storage device detected
7134.588992] scsi13 : usb-storage 1-5:1.0
7135.766979] scsi 13:0:0:0: Direct-Access SMI USB DISK 1100 PQ: 0 ANSI: 4
7135.767173] scsi 13:0:0:0: alua: supports implicit and explicit TPGS
7135.769189] scsi 13:0:0:0: alua: No target port descriptors found
7135.769202] scsi 13:0:0:0: alua: not attached
7135.769641] sd 13:0:0:0: Attached scsi generic sg2 type 0
7135.773587] sd 13:0:0:0: [sdb] 15552512 512-byte logical blocks: (7.96 GB/7.41 GiB)
7135.775076] sd 13:0:0:0: [sdb] Write Protect is on
7135.775088] sd 13:0:0:0: [sdb] Mode Sense: 43 00 80 00
7135.776093] sd 13:0:0:0: [sdb] No Caching mode page found
7135.776101] sd 13:0:0:0: [sdb] Assuming drive cache: write through
7135.776111] sd 13:0:0:0: [sdb] Attached SCSI removable disk
7135.796886] sd 13:0:0:0: [sdb] No Caching mode page found
7135.796898] sd 13:0:0:0: [sdb] Assuming drive cache: write through
7135.801078] sd 13:0:0:0: [sdb] No Caching mode page found
7135.801089] sd 13:0:0:0: [sdb] Assuming drive cache: write through
7135.801976] sdb: sdb1
There is no write-protect switch on the device, and it was written to before.
Some further output from fdisk.
# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 7962 MB, 7962886144 bytes, 15552512 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
Disk label type: dos
Disk identifier: 0xc3072e18
Device Boot Start End Blocks Id System
/dev/sdb1 * 24 15552511 7776244 b W95 FAT32
Command (m for help): d
Selected partition 1
Partition 1 is deleted
Command (m for help): w
fdisk: cannot write disk label: Bad file descriptor
Device Boot Start End Blocks Id System
/dev/sdb1 * 24 15552511 7776244 b W95 FAT32
Isn’t byte 24 an odd location for the start of a block?
Something lousy here. You can not even write a partition table.
I know almost nothing about Windows, but there being a VAT file system on it, did you use it on Windows before this problem? Then it could be that it is not properly closed by Windows (e.g. when you remove it without telling Windows). According to what I remember from other threads then connecting it to a Windows system and removing it save might hlp.
Yes I like this comment!
I know almost nothing about Windows, but there being a VAT file system on it, did you use it on Windows before this problem? Then it could be that it is not properly closed by Windows (e.g. when you remove it without telling Windows). According to what I remember from other threads then connecting it to a Windows system and removing it save might hlp.
I’m not a Windows user either, but that’s one of the first things I tried. Didn’t help. Thanks for the suggestions anyway. I think I’ll consider it a dead stick.
On 2014-04-02 22:46, ionmich wrote:
>
> Some further output from fdisk.
>
>
> Code:
> --------------------
> # fdisk /dev/sdb
…
> Command (m for help): w
> fdisk: cannot write disk label: Bad file descriptor
> --------------------
Ow.
Look at the output of dmesg while you do that. You can, for instance,
use “dmesg -H --follow” on a terminal (press an extra enter or two after
it), then run that fdisk sequence on another terminal, and notice what
new messages, if any, are printed on the dmesg terminal.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
As it seems that you are willing to loose what is on that stick (my observation after you tried in vain to remove it’s only partition), you could try to write a complete new empty partition table to it. Use the fdisk commands o and w for it. And follow Carlos’ suggestion to see the dmesg output that it generates.
Another** “destryoing”** action is:
dd if=/dev/null of=/dev/sdb count=1 bs=1024
This will write a block of 1024 zero bytes to the begin of the device. Again to check if there are errors (and dmesg loging) reported.
When these actions show problems, I also think the stick is broken.
fdisk “o” and “w” did not produce any errors. dmesg reported…
[Apr 3 10:52] sd 4:0:0:0: [sdb] No Caching mode page found
+0.000015] sd 4:0:0:0: [sdb] Assuming drive cache: write through
+0.002200] sdb: sdb1
and nothing changed.
Another** “destryoing”** action is:
dd if=/dev/null of=/dev/sdb count=1 bs=1024
This will write a block of 1024 zero bytes to the begin of the device. Again to check if there are errors (and dmesg loging) reported.
When these actions show problems, I also think the stick is broken.
I tried that some time back. Here is the result. Strangely dmesg does NOT report anything.
# dd if=/dev/null of=/dev/sdb count=1 bs=1024
dd: failed to open ‘/dev/sdb’: Read-only file system
After that action you should have an empty partition table (to be confirmed by fdisk -l). Thus there shouldn’t be no /dev/sdb1 anymore, no desktop mounting, etc.
That is a bit strange as /dev/sdb is not file system at all. What says
ls -l /dev/sdb
# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 Apr 3 11:42 /dev/sdb
couple of question and a possible result (may not be a good result but still)
Q. 1. how old is the USB stick?
Q.2. how was it used?
reason being, all Flash memory type devices have a limited numbers of writes.
so if the flash stick is very old and/or have been written to a lot it might have reached its write limit. since you can mount and read it I will say it is a good indication that that is the case. when flash stick reaches it’s write limit it becomes write only at best or unreadable at worst.
now other possibility is that some of the controlled circuitry got zapped(by static or something ) and it got into read-only mode.
That looks fine. I assume you did that dd as root, like the fdisk?
Correction, I meant to say Read-only not write only 
Yes I did. I assumed, perhaps incorrectly, that the “#” prompt showing in my code would indicate a root login.
Yes I did. I assumed, perhaps incorrectly, that the “#” prompt showing in my code, would indicate a root login.