LinuxQuestions.org - can't read/write to USB sticks--"read-only filesystem"

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - can't read/write to USB sticks--"read-only filesystem" (https://www.linuxquestions.org/questions/linux-general-1/cant-read-write-to-usb-sticks-read-only-filesystem-4175473265/)

can't read/write to USB sticks--"read-only filesystem"

I have a recurring (but not continuous) problem with reading or writing to my USB sticks (other than the one containing this OS) and don't understand why. My system will refuse to write to them in any way, saying they're read-only filesystems. It's not a problem of permissions, because I couldn't write to the sticks even as root. I don't think there's anything wrong with the sticks, because I wrote to both of them a few days ago and one of them is no more than a couple months old.

This is my fstab file; the sticks in question are sda1 and sdc1--
# /etc/fstab: static file system information
#
# Created by make-fstab on Thu Aug 8 20:01:15 MST 2013

# <file system> <mount point> <type> <options> <dump/pass>

Code:

# Added by antiX

/dev/sda1        /media/sda1      vfat      noauto,uid=1000,gid=users,dmask=002,fmask=113,relatime,users  0 0

# Added by antiX

/dev/sdb1        /live/boot-dev  ext3      noauto,exec,relatime            0 0

# Added by antiX

/dev/sdc1        /media/sdc1      vfat      noauto,uid=1000,gid=users,dmask=002,fmask=113,relatime,users  0 0

# Added by antiX

/dev/sdb2        swap            swap      defaults                        0 0

# Added by antiX

/dev/cdrom      /media/cdrom    iso9660    noauto,exec,users,ro            0 0

# Added by antiX

/dev/sr0        /media/sr0      auto      noauto,exec,users,ro            0 0

# Added by antiX

/dev/cdrw        /media/cdrw      iso9660    noauto,exec,users,rw            0 0

If the fstab entries are wrong, I don't understand what happened, because I don't remember editing fstab recently.

I do unplug my sticks and/or move them between ports fairly often; does that probably have to do with this? The comments say the system generated the fstab five days ago, and I probably had the sticks plugged into different ports.

yes removing and inserting USB devices into the system can cause their device name to change.

ex:

if you plug in USB today and the system reads it as /dev/sdb1 then you add a 2nd USB that is read as /dev/sdc1. when you remove /dev/sdb1 if it was not properly umounted or an some cases the system just forgets to drop that device name when you plug it back in you COULD end up with /dev/sdd1 instead of /dev/sdb1 so now your ftab is going to fail.

removable media and fstab do not play nice for that very reason.

depending on your OS and how it handles automagically mounting of devices your system could even be trying to mount the device two times. one in the fstab entry and an other in the default location of /media or /run or what ever your distro uses.

if you will be using only a handful of USB devices it might be advantageous to manually mount them, or consider looking into udev rules. an other option is to label the drives then create a script to detect what label the drive is and mount it a specific way.

sadly dealing with USB devices is just like that. heck even MS windows screws it up more then it gets it right. ive lost count how many times ive seen multiple copies of the same USB device in winXP, Vista, and 7, have never worked with 8, but i can almost bet 100% the problem is still there.

It boils down to the system not "forgetting" properly the temporary assigned address of the device.

The next time it happens issue a mount command and see if the USB stick is mounted ro (read only).

To expand on lieb's answer you could try continuing to let the system automatically mount USB sticks when you plug them in and issue a umount command for the device before you pull the USB stick out. If the system is still confused about which USB stick is mounted where then you could disable the automatic mounts and manually mount and umount the devices.

---------------------
Steve Stites