Other Unmountable USB flash drive

[quamenzullo]

Hello,

I've got an USB flash drive that I "formatted" under Linux as FAT32 (but I get the same results when it's "formatted" in ext4).
In the Linux box, there's no problem, one can mount it, write on it, unmount it.

In FreeBSD, it's impossible to just mount it and read data from it.

When I plug it in, /dev/da0 show up, but no /dev/da0s1.

# mount /dev/da0 /media/da0/
mount: /dev/da0: Read-only file system

I don't understand this: if this is "seen" as read only, then how is it a problem to mount it?
Whatever:

# mount -r /dev/da0 /media/da0/
mount: /dev/da0: No such file or directory

But /dev/da0 is still here.

This "read-only" status shows up in different tools' outputs. The flash drive has actually no knob nor swich of any kind allowing to turn on or off any write/read mode.

Some more checks:

# fsck /dev/da0
Can't open /dev/da0: No such file or directory

But:

# fsck.ext4 -n /dev/da0
e2fsck 1.45.6 (20-Mar-2020)
CLE4GB : clean, 11/244800 files, 33670/978944 blocks

When "formatted" in FAT32, here's the log file of automount:

2020-04-21 17:53:03 /dev/ugen7.3: attach
2020-04-21 17:53:05 /dev/ugen7.3: no MTP devices found
2020-04-21 17:53:05 /dev/da0: attach
2020-04-21 17:53:05 /dev/da0: create '/media/da0' dir
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs ** /dev/da0 (NO WRITE)
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs Invalid signature in fsinfo block
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs Fix? no
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs ** Phase 1 - Read and Compare FATs
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs ** Phase 2 - Check Cluster Chains
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs ** Phase 3 - Checking Directories
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs ** Phase 4 - Checking for Lost Files
2020-04-21 17:53:06 /dev/da0: fsck_msdosfs 1 files, 3908116 free (977029 clusters)
2020-04-21 17:53:07 /dev/da0: filesystem mount retry: 1/3
2020-04-21 17:53:08 /dev/da0: filesystem mount retry: 2/3
2020-04-21 17:53:09 /dev/da0: filesystem mount retry: 3/3
2020-04-21 17:53:09 /dev/da0: mount FAIL: 'mount_msdosfs -o longnames -m 644 -M 775 -D cp437 -L fr_FR.UTF-8 -u 1001 -g 5 -o noatime  /dev/da0 /media/da0'

And indeed:

# mount_msdosfs -o longnames -m 644 -M 775 -D cp437 -L fr_FR.UTF-8 -u 1001 -g 5 -o noatime  /dev/da0 /media/da0
mount_msdosfs: /dev/da0: Read-only file system

But, why is it a problem to only mount it?

The configuration is fine (since I can mount/umount other USB devices), but for information (my username being nico):

# groups nico
nico wheel operator video dialer network cups
# sysctl vfs.usermount
vfs.usermount: 1
# grep devfs /etc/rc.conf
devfs_system_ruleset="localrules"
# cat /etc/devfs.rules
[localrules=5]
add path 'da*' mode 0660 group operator
add path 'acd*' mode 0660 group operator
add path 'cd*' mode 0660 group operator
add path 'pass*' mode 0660 group operator
add path 'xpt*' mode 0660 group operator
add path 'msdosfs/*' mode 0660 group operator
add path 'ext2fs/' mode 0660 group operator
add path 'ntfs/*' mode 0660 group operator
add path 'usb/*' mode 0660 group operator
add path 'unlpt*' mode 0660 group cups
add path 'ulpt*' mode 0660 group cups
add path 'lpt*' mode 0660 group cups
add path 'usb/7.2' mode 0660 group cups
# usbconfig
ugen3.1: <Intel EHCI root HUB> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.1: <Intel UHCI root HUB> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen2.1: <Intel UHCI root HUB> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen5.1: <Intel UHCI root HUB> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen7.1: <Intel EHCI root HUB> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.1: <Intel UHCI root HUB> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen4.1: <Intel UHCI root HUB> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen6.1: <Intel UHCI root HUB> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen7.2: <Image Processor Lenovo EasyCamera> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen6.2: <Logitech USB Receiver> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA)
ugen7.3: <General USB Flash Disk> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)

I'd liked to try to "format" it from FreeBSD, but of course:

# dd if=/dev/zero of=/dev/da0 bs=2M
dd: /dev/da0: Read-only file system
# fdisk -i /dev/da0
fdisk: can't open device /dev/da0
fdisk: cannot open disk /dev/da0: Read-only file system

And there's no /dev/da0s1 where I could create a msdos partition.
I could zero it from linux and create the table and then a partition.

Is there anything to do to force mounting or "formatting" it? Or do the fsck_msdosfs Invalid signature in fsinfo block and fsck_msdosfs Fix? no messages mean there's no solution at all?

Any clue or idea, what to do to get more information or solve this?

 

[George]

I would always start with gpart show da0. Then see what we got.

 

[quamenzullo]

Unfortunately it looks like it doesn't "see" the drive at all:

# gpart show da0
gpart: No such geom: da0.

 

[Alain De Vos]

[The output of fdisk -l in linux can be interesting to know.]
Is there a partition table.
Is it mbr or gpt.
Look at /var/log/messages when you plug the stick in and out.
What is returned by "file -s /dev/da0" , "file -s /dev/da0s1" , "file -s /dev/da0p1"

 

[George]

I would double check whether da0 appears in sysctl kern.disks, and then go on with partitioning.
Like "gpart create -s GPT da0", then "gpart add -t fat32 da0", then newfs_msdos /dev/da0p1". Or so. ;D

Then mount it.

 

[PMc]

I don't know what an USB "key" is supposed to be. If this is a kind of small umass device, then most of them are just crap. They behave differently on different systems, they behave differently on different plugs of the same system, they behave differently half a day later, and so on.

You tried to write it with dd, that is the most low-level one can do. So these are the messages I would rely on: the device does not allow to be written. Other interesting question would be what it does when trying to read from it with dd - but there one would need to recognise a partition table in hexdump. Since gpart says there is none, I might suppose the thing reads just zero-bytes.
So, as you say, there is no enable switch on it, there might be some other trick needed to enable it. No idea what the thing actually is, maybe some quirk missing or it has some more functionality.

 

[quamenzullo]

I would double check whether da0 appears in sysctl kern.disks,

It does:

# sysctl kern.disks
kern.disks: da0 ada0 cd0

and then go on with partitioning.
Like "gpart create -s GPT da0"

I've tried it after having zeroed it (using dd in linux), but:

# gpart create -s GPT da0
gpart: geom 'da0': Read-only file system

so I could not try the next steps. Note: if I create the GPT partition table with linux, then the next step's output is:

# gpart add -t fat32 da0
gpart: geom 'da0': Read-only file system

[The output of fdisk -l in linux can be interesting to know.]

Here it is (with GPT and 1 FAT32 partition): (the output was in french, so I translated it, hope my translation is fine)

$ fdisk -l /dev/sdb
Disk /dev/sdb: 3,75 GiB, 4009754624 bytes, 7831552 sectors
Disk model: USB Flash Disk
Units: sector of 1 × 512 = 512 bytes
Sector size (logical / physical) : 512 bytes / 512 bytes
I/O size (minimal / optimal) : 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: A93B74DD-77EF-46F1-9D10-CF816E9C62BD

Device        Start  End      Sectors   Size Type
/dev/sdb1     2048   7829503  7827456   3,8G Microsoft base data

Is there a partition table.
Is it mbr or gpt.

Well I've tried "formatting" from linux (gparted) starting with either GPT or "msdos" (I guess "MBR") tables, I get similar results any time.

Look at /var/log/messages when you plug the stick in and out.

Here it is (this time, MBR partitions table, don't know if that's relevant):

Apr 22 16:35:40 meztli kernel: ugen7.3: <General USB Flash Disk> at usbus7
Apr 22 16:35:40 meztli kernel: umass0 on uhub3
Apr 22 16:35:40 meztli kernel: umass0: <General USB Flash Disk, class 0/0, rev 2.00/1.00, addr 3> on usbus7
Apr 22 16:35:40 meztli kernel: umass0:  SCSI over Bulk-Only; quirks = 0xc101
Apr 22 16:35:40 meztli kernel: umass0:3:0: Attached to scbus3
Apr 22 16:35:40 meztli kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
Apr 22 16:35:40 meztli kernel: da0: <General USB Flash Disk 0.00> Removable Direct Access SCSI-2 device
Apr 22 16:35:40 meztli kernel: da0: Serial Number 00000000000004EC
Apr 22 16:35:40 meztli kernel: da0: 40.000MB/s transfers
Apr 22 16:35:40 meztli kernel: da0: 3824MB (7831552 512 byte sectors)
Apr 22 16:35:40 meztli kernel: da0: quirks=0x2<NO_6_BYTE>
Apr 22 16:35:40 meztli kernel: da0: Write Protected

And I think the main problem is this "Write Protected" message (that echoes the several "read-only" warnings from different commands previously). Still, I don't understand why Linux seems to ignore it. And why it would prevent FreeBSD to at least mount it (even if it's read-only).

What is returned by "file -s /dev/da0" , "file -s /dev/da0s1" , "file -s /dev/da0p1"

Here are the results (case of MBR partitions table):

 # file -s /dev/da0
/dev/da0: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x4,4,1), end-CHS (0x3ff,254,2), startsector 2048, 7829504 sectors
# file -s /dev/da0s1
/dev/da0s1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 124, hidden sectors 2048, sectors 7829504 (volumes > 32 MB), FAT (32 bit), sectors/FAT 7632, serial number 0x9d2b5c57, label: "CLE4GB     "
# file -s /dev/da0p1
/dev/da0p1: cannot open `/dev/da0p1' (No such file or directory)

(in case of GPT, results from the two last commands were swapped).

I don't know what an USB "key" is supposed to be.

Oh I'm sorry it's a kind of direct translation from my language (french), but I've seen this here and there in internet too.
The most common name for it seems to be "flash drive", but this is only one among a few others apparently
I will edit the thread's title and my messages to remove the "key" word and use "drive" instead.

If this is a kind of small umass device, then most of them are just crap. They behave differently on different systems, they behave differently on different plugs of the same system, they behave differently half a day later, and so on.

You tried to write it with dd, that is the most low-level one can do. So these are the messages I would rely on: the device does not allow to be written. Other interesting question would be what it does when trying to read from it with dd - but there one would need to recognise a partition table in hexdump. Since gpart says there is none, I might suppose the thing reads just zero-bytes.
So, as you say, there is no enable switch on it, there might be some other trick needed to enable it. No idea what the thing actually is, maybe some quirk missing or it has some more functionality.

Some say too, on sites like superuser.com or unix.stackexchange.com etc., that this might be caused by corrupted hardware or firmware of the flash drive.

Well as I've been stopped in many attempts by this "read-only something" messages, I've searched about write protected flash drives, and got some results. It seems there's a "read-only" attribute on flash drives, that may be set or not.
In Linux one can use, for instance for a drive showing up as /dev/sdb/: sudo hdparm -r /dev/sdb to read this attribute and sudo hdparm -r0 /dev/sdb to disable it. But from linux it read readonly = 0 (off). Still I ran the command to set it to 0 (once unmounted, one mounted), then checked it, it was still set to 0. I guess this explains why linux does not see this flash drive as read-only. I wonder why FreeBSD does. Maybe I should still try the equivalent tricks from a Windows machine.

I've looked for something similar in FreeBSD but was not really successful.
I can mention camcontrol(8)'s attrib subcommand, but I couldn't let it work.

# camcontrol attrib -r attr_list da0
camcontrol: subcommand "attrib" requires a valid device identifier
# camcontrol attrib -r attr_list /dev/da0
camcontrol: subcommand "attrib" requires a valid device identifier

camcontrol has such a long manpage I cannot tell nothing else would be useful, but so far I haven't found it.

 

[PMc]

Oh I'm sorry it's a kind of direct translation from my language (french), but I've seen this here and there in internet too.
The most common name for it seems to be "flash drive", but this is only one among a few others apparently
I will edit the thread's title and my messages to remove the "key" word and use "drive" instead.

Never mind. I'm just stating what I do not know, instead of following wrong assumptions. So in fact the thing is an umass device aka memstick aka usbstick aka pendrive aka whateverelse. These are usually the cheapest pieces of flash memory and can have all kinds of weird behaviour. One of mine does mount only on the pinout usb connectors, not on those in the backpanel. Another one went offline when I tried to create a portstree UFS filesystem on it (it was obviousely not amused by that kind of traffic) and came back a day later. And so on.

Now your's seem to have an internal write protect switch, and I wonder how that would be implemented. Or FreeBSD somehow gets that idea on initial inquiry and then behaves accordingly (but then it would be mountable in r/o).

I've looked for something similar in FreeBSD but was not really successful.
I can mention camcontrol(8)'s attrib subcommand, but I couldn't let it work.

# camcontrol attrib -r attr_list da0
camcontrol: subcommand "attrib" requires a valid device identifier
# camcontrol attrib -r attr_list /dev/da0
camcontrol: subcommand "attrib" requires a valid device identifier

That's a syntax mistake. It should be camcontrol attrib da0 -r attr_list, but I then I get "Argument list too long" from the memsticks. It seems one does not even get a modepage from them.

 

[Alain De Vos]

If it is readonly, just remove everything on any o.s. And try to create a partition table, partition,format,and write some files in freebsd. And one knows if it is readonly or not ?

 

[George]

You can ask the geom layer for its opinion with geom disk list da0, and geom part list da0.

This shows what the da driver thinks about the stick: dmesg | grep da0

 

[quamenzullo]

That's a syntax mistake. It should be camcontrol attrib da0 -r attr_list, but I then I get "Argument list too long" from the memsticks. It seems one does not even get a modepage from them.

Thanks for this correction. Now I also get the same "Argument list too long" error (for each one of the available actions).

If it is readonly, just remove everything on any o.s.

Do you mean, zero it? I've used this exact command to perform the zeroing from Linux: sudo dd if=/dev/zero of=/dev/sdb bs=2M status=progress oflag=sync. Is there anything deleting "better" than this?

And try to create a partition table, partition,format,and write some files in freebsd. And one knows if it is readonly or not ?

Well after having zeroed the drive in Linux, when plugged in in FreeBSD, I got results like:

# gpart create -s GPT da0
gpart: geom 'da0': Read-only file system

You can ask the geom layer for its opinion with geom disk list da0, and geom part list da0.

This shows what the da driver thinks about the stick: dmesg | grep da0

Here are the results (this time it was a GPT partition table with one FAT32 partition):

# geom disk list da0
Geom name: da0
Providers:
1. Name: da0
   Mediasize: 4009754624 (3.7G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: General USB Flash Disk
   ident: 00000000000004EC
   rotationrate: unknown
   fwsectors: 63
   fwheads: 255

# geom part list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 7831518
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 4007657472 (3.7G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r0w0e0
   efimedia: HD(1,GPT,fbaebdfb-c300-4df7-9f97-f5737dc7a5c6,0x800,0x777000)
   rawuuid: fbaebdfb-c300-4df7-9f97-f5737dc7a5c6
   rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
   label: (null)
   length: 4007657472
   offset: 1048576
   type: ms-basic-data
   index: 1
   end: 7829503
   start: 2048
Consumers:
1. Name: da0
   Mediasize: 4009754624 (3.7G)
   Sectorsize: 512
   Mode: r0w0e0

# dmesg | grep da0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <WDC WD3200BEVT-24A23T0 01.01A02> ATA8-ACS SATA 2.x device
ada0: Serial Number WD-WXK1A30P8719
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors)
Trying to mount root from ufs:/dev/ada0p2 [rw]...
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <General USB Flash Disk 0.00> Removable Direct Access SCSI-2 device
da0: Serial Number 00000000000004EC
da0: 40.000MB/s transfers
da0: 3824MB (7831552 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
da0: Write Protected

Apart from this final "Write Protected", I don't see anything wrong... (or is there anything suspicious?)

 

[George]

 da0: Write Protected

That's the culprit.

You tried hdparm on linux already. Not much else to do, I guess?

 

[PMc]

One might revert before that patch...

⚙ D13360 geom_disk / scsi_da: deny opening write-protected disks for writing

reviews.freebsd.org

 

[quamenzullo]

One might revert before that patch...

⚙ D13360 geom_disk / scsi_da: deny opening write-protected disks for writing

reviews.freebsd.org

I'm not so sure this would help, because unless I misunderstand this discussion, it's about preventing to mount read-only disks as writable, not at all. There's still something unexplained as to why the drive doesn't get mounted at least as read-only. If I explicitely tell mount to mount the drive as read-only, I get:

# mount -r /dev/da0 /media/da0/
mount: /dev/da0: No such file or directory

Although the drive is still plugged in: for instance, geom disk list da0 and geom part list da0 still give the same results as in #11, the last time umass0 got disconnected in /var/log/messages was three days ago etc.

However, this discussion teaches us that the

bit 7 of the device specific field in the mode parameter header returned by MODE SENSE

is used to determine whether the flash drive is write protected or not.

Some search about this MODE SENSE lead me to this interesting blog post, that teaches us that flash drives behave differently from one brand to another (even from one model to another maybe) and that different OSes also do not communicate exactly the same way with flash drives. That would explain why Linux and Windows do not determine the flash drive as read-only, and FreeBSD does.

Not much else to do, I guess?

Well it seems the only way to get further would be to find a way of reading and maybe modifying this MODE SENSE's bit 7... But this is becoming a little bit too low-level, and maybe it requires specific equipment. This is really a lot of time spent for one single flash drive, so I'd better give up. I hope this one at least is an exception and that all other flash drives here will just work correctly with FreeBSD. I'm happy the problem doesn't happen with my printer

Also I've learned some more common commands to use when dealing with flash drives from my FreeBSD computer (that I'm currently discovering as desktop) and I think this thread is quite a nice summary of all that's possible to try before going more low-level. Thank you all for your precious help!

 

[George]

For the sake of completeness you could post the mode pages of your stick. Maybe someone out there can figure it out.

sg_modes /dev/da0 lists them in raw format. It is part of sg3_utils package, either on linux or FreeBSD.
sdparm --long -a /dev/da0 is probably the better command.. sysutils/sdparm is equivalent to hdparm on linux.

I agree that mount should be able to see the device, and mount its file systems read-only.
*edit: the mount command should be mount -t msdosfs -r /dev/da0p1 /mnt , not just "da0". ;D

 

[quamenzullo]

You pointed out the wrong command that I used to mount the stick correctly. I could mount it as read-only now. Thank you!!
There's still something weird: sometimes it shows up in the left panel of thunar, sometimes not. But I guess this is another setting.

So, the only mystery remaining in this thread is why is the flash drive seen as read-only with FreeBSD and not Linux nor Windows.

Here are the results of sg_modes and sdparm:

$ sg_modes /dev/da0
    General   USB Flash Disk    0.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=32, medium type=0x70, WP=1, DpoFua=0, longlba=0
  Block descriptor length=0
>> page_code: 0x2a, page_control: current
 00     2a 46 07 07 f5 77 29 23  1b 80 00 ff 08 00 1b 80
 10     00 10 06 e0 06 e0 00 00
$ sdparm --long -a /dev/da0
    /dev/da0: General   USB Flash Disk    0.00
    Direct access device specific parameters: WP=1  DPOFUA=0

 

[mark_j]

Is this device on an external hub or using an extension cable?
It's a da0 device? What's the output of ls -Fl /dev/da0*

I see in your output it shows Mode as r0w0e0. That's unusual for a connected device.

 

[George]

Maybe there is a scsi command to reset the device, or to set this to zero. WP is write protected, I assume:

    Direct access device specific parameters: WP=1

 

[quamenzullo]

Is this device on an external hub or using an extension cable?
It's a da0 device? What's the output of ls -Fl /dev/da0*

No, it's plugged in directly in the computer (no cable, no external hub). It's recognized as da0 indeed.

# ls -Fl /dev/da0*
crw-rw----  1 root  operator  0x9e 26 avr.  18:10 /dev/da0
crw-rw----  1 root  operator  0x9f 26 avr.  18:10 /dev/da0p1

I see in your output it shows Mode as r0w0e0. That's unusual for a connected device.

Indeed. Looks like it matches the "write protected" message from dmesg | grep da0.

Maybe there is a scsi command to reset the device, or to set this to zero. WP is write protected, I assume:

    Direct access device specific parameters: WP=1

Yes, I'm trying to figure out the right command from sdparm(8) or sg_wr_mode(8).

 

[mark_j]

The mode: r0w0e0 indicates it's connected but not mounted. Which I guess you already knew?


In your opening comment you attempt to mount the entire device, not the partition because the system is not generating the device nodes in /dev?
Now, I see from your output it is, so can you mount /dev/da0p1?

So, what's the file system on it right now? Can you apply a file system to it (apologies if you've gone through this before, I've come in late to this discussion)?

newfs /dev/da0p1

Sometimes sysctl -b kern.geom.confxml can provide you with more understandable information.

Do you have autofs(5) enabled on this system? (I think not, but better to ask).

 

[quamenzullo]

Hello, sorry for this delay, I've been really busy the last few days.

The mode: r0w0e0 indicates it's connected but not mounted. Which I guess you already knew?

No, indeed, I thought it was only another hint of this Write Protected "mode".

In your opening comment you attempt to mount the entire device, not the partition because the system is not generating the device nodes in /dev?

Indeed, I couldn't find any /dev/da0* (except for /dev/da0 itself).
I've "formatted" the drive many many times (and "zeroed" it via dd too, several times), so I don't know at which point exactly the /dev/da0s1 or /dev/da0p1 did show up. I used gparted on Linux, and trying to create a partition without any partitions table is not allowed by gparted. So I don't know why the partitions finally showed up.

Now, I see from your output it is, so can you mount /dev/da0p1?

Yes I finally could, read-only, but at least readable.

So, what's the file system on it right now? Can you apply a file system to it (apologies if you've gone through this before, I've come in late to this discussion)?

newfs /dev/da0p1

Right now this is FAT32 (with GPT).
It looks like something happened:

# newfs /dev/da0p1
/dev/da0p1: 3822.0MB (7827456 sectors) block size 32768, fragment size 4096
    using 7 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632

But I could umount and mount -t msdosfs -o autoro /dev/da0p1 /media/da0/ again and nothing had changed on the drive.

Sometimes sysctl -b kern.geom.confxml can provide you with more understandable information.

Well it outputs a long long xml file. Several parts look relevant (are about da0 or da0p1) but I don't really know what to do with them.

Do you have autofs(5) enabled on this system? (I think not, but better to ask).

So. I enabled it at some point, then disabled it. (So if I want to enable it again, only turning autofs_enable to "YES" will be enough). I hope other settings do not disturb the mounting of drives, but I guess not, since I can mount and read / write other flash drives.

Well I need some time to read sdparm(8) and sg_wr_mode(8) and other related pages, but it seems possible to investigate and reset this read-only/read-write mode, so I hope I'll find something.

 

[quamenzullo]

Some interesting findings: the difference between MODE SENSE(10) (maybe the default used by FreeBSD) and MODE SENSE(6) (apparently used by Linux) outputs (check the WP result):

# sg_modes --all /dev/da0
    General   USB Flash Disk    0.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=32, medium type=0x70, WP=1, DpoFua=0, longlba=0
  Block descriptor length=0
>> page_code: 0x2a, page_control: current
00     2a 46 07 07 f5 77 29 23  1b 80 00 ff 08 00 1b 80
10     00 10 06 e0 06 e0 00 00

# sg_modes --all --six /dev/da0
    General   USB Flash Disk    0.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(6):
  Mode data length=12, medium type=0x00, WP=0, DpoFua=0, longlba=0
  Block descriptor length=8
> Direct access device block descriptors:
   Density code=0x0
00     00 03 e3 11 00 00 08 00

It looks like the field to change is SWP. Only, sdparm cannot get it unfortunately...

# sdparm --get=SWP --long /dev/da0
    /dev/da0: General   USB Flash Disk    0.00

It should be possible to set the matching code page (0x0a) via sg_wr_mode, but I really don't know how to deal with it: I should use the output of sg_modes:

# sg_modes --page=0a /dev/da0
    General   USB Flash Disk    0.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
  Mode data length=32, medium type=0x70, WP=1, DpoFua=0, longlba=0
  Block descriptor length=0
>> page_code: 0x2a, page_control: current
00     2a 46 07 07 f5 77 29 23  1b 80 00 ff 08 00 1b 80
10     00 10 06 e0 06 e0 00 00

but I have no idea how I could change 2a 46 07 07 f5 77 29 23 1b 80 00 ff 08 00 1b 80 00 10 06 e0 06 e0 00 00 in order to only set the SWP field to 0. Where is the part to change and how...?

Using sdparm looks indeed easier, so in spite of sdparm not "seeing" SWP, I tried to clear it:

# sdparm --clear=SWP /dev/da0
    /dev/da0: General   USB Flash Disk    0.00
mode select(10): transport: (pass2:umass-sim0:0:0:0): MODE SELECT(10). CDB: 55 10 00 00 00 00 00 00 20 00
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error

didn't look very successful... but I checked the WP field and errors now show up, but...:

# sg_modes --all /dev/da0
inquiry: transport: (pass2:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error

           peripheral_type: disk [0x0]
mode sense(10): transport: (pass2:umass-sim0:0:0:0): MODE SENSE(10). CDB: 5a 00 3f 00 00 00 00 10 00 00
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error

Mode parameter header from MODE SENSE(10):
Invalid block descriptor length=0, ignore
  Mode data length=2, medium type=0x00, WP=0, DpoFua=0, longlba=0
  Block descriptor length=0

Unfortunately, I couldn't mount the drive any longer. Maybe I've messed up...

 

[quamenzullo]

Well, don't know how, although the changes written by sdparm default to current values (so next time the drive is used, these changes should disappear), the drive is modified now: I can still mount it in Linux, but have to do it manually. Also, I still get a lot of "Malformed SCSI command" when using sg_modes or sdparm, that did NOT show up before with the same commands. Weird.

Anyway, trying to save the changes seems forbidden:

# sdparm --clear=SWP --save /dev/da0
    /dev/da0: General   USB Flash Disk    0.00
change_mode_page: mode page indicates it is not saveable but
    '--save' option given (try without it)

So, it seems it's not possible to change this Write Protected mode...

If I do clear it (without saving), then when I want to mount, I get:

# mount -t msdosfs -o autoro /dev/da0p1 /media/da0/
mount_msdosfs: /dev/da0p1: Device not configured

If anyone has a clue? Otherwise I'll just give up I think!

 

[T-Daemon]

I came across this in da(4):

CACHE EFFECTS
     Many direct access    devices    are equipped with read and/or write caches.
     Parameters    affecting the device's cache are stored    in mode    page 8,    the
     caching control page.  Mode pages can be examined and modified via    the
     camcontrol(8) utility.

From camcontrol(8):

 modepage     Allows    the user to display and    optionally edit    a SCSI mode
             page.    The mode page formats are located in
             /usr/share/misc/scsi_modes.

I would give a try playing with the modepage command arguments.

The "Write Protected" message is generated by /usr/src/sys/cam/scsi/scsi_da.c ( SCSI Direct Access Peripheral driver for CAM )

if ((softc->disk->d_flags & DISKFLAG_WRITE_PROTECT) != 0 &&
        (softc->flags & DA_FLAG_ANNOUNCED) == 0) {
        printf("%s%d: Write Protected\n", periph->periph_name,
            periph->unit_number);
    }

I haven't closely investigated which function determines to set a write protect disk flag, also my knowledge might be insufficient to extract that information. Maybe someone else has a clue.

Is this an older USB device, respectively used a lot? The Read-only file system message sounds a lot like the drive has reached it's write cycle limit, but on the other hand it shouldn't be mountable/writable in Linux.

 

[George]

So using MODE SENSE(10) returns write protected, and MODE SENSE(6) says it's not write protected?

Maybe that is why Linux and Freebsd handle the stick differently.

Unlucky, I guess.