It was the "dirty bit"!
I used the fsck command to check the fileysystem. For me, it is the first time I have tried this.

If your USB flash drive suddenly becomes read-only..
Suspect that there is a corrupt or broken file somewhere on it. It is the signal that the USB flash drive has "suffered an event". It need not be broken, but it may have copied onto it somewhere, a file that is (broken). Mine happened to come from a Windows system, and it had something called "broken chains".

It need not be a Windows file, but most users opt to use a Windows/MSDOS type filesystem on flash sticks, usually FAT32 if it it is a stick bigger than 4GB. It allows to move files between Linux and Windows machines. I have no idea what a Windows machine does if one plugs in an ext4 formatted stick.

If a whole folder was copied, with files in sub-folders, it can happen that there are broken chains in fragmented files.

If the drive was removed while the copy was only locally cached, it can cause broken chains in a FAT32 system. Even if enough time has passed for the copy to complete - it does not mean the cache cooperated. "Safely Remove" is what you need, but this still does not guarantee the flash drive dirty bit will stay OK.

All the later symptoms of repeatedly reverting to read-only seem to be because of the "dirty bit" flag

The drive can be temporarily set to read-write, and under limited forced conditions, be written to, but as soon as it is seen in normal operation, the "dirty bit" flag will turn it back into read-only.

In the following fix-it example, the flash drive is /dev/sdb1 and has name B3AB-8FAD

Repair the filesystem with sudo fsck
..lets one correct the dirty bit flag. It finds messed up folder, and allows to delete the directory and reclaim unused clusters.

We are not done yet. The fix leaves some loose ends, and the filesystem is still read-only. Use sudo fsck again. It allows to correct the free cluster summary.
Keep going one last time - to check it reports clean.It may be fixed, but it is still flagged read-only. So finally use the remount again to force it to be mounted as read-write.From this point on, the USB flash drive should work again normally.

Very strange that the "dirty" Windows file was easily copied off the USB while in "dirty" read-only state, and it seemed OK, but I trashed it anyway.

I am hoping this can be marked "SOLVED", but I leave it here for a bit.
My thanks to all for their suggestions.

2 members found this post helpful.

I was going to ask why no-one had thought of fsck! It's a standard Linux procedure to mark a device as read-only if the filing system looks suspicious, to prevent possible corruption.

My own experience, using CentOS and Salix, was that I only once had a USB stick suffer that fate. The first couple of times I used fsck, then I reformated it, then I ditched it. But my sticks are all ext2 format and I don't have Windows.

Hi David
I entirely agree. You would have thought that out of the very many postings, suggestions, "solutions" that seemed OK at the time, but turned out to be somewhat short-lived, that by now, someone would have explained why it happens, and how to use fsck to fix it. Maybe they did, but it would be in the middle of a lot of misguided noise, and I never found it. It seems similar situations happen in Windows-Windows transfers, and with a lot of variable advice on what to do.

For Windows users
There have to be equivalent commands. DISKPART can reset the read-only flag, but you need chkdsk to repair the messed up chains. There are arguments chkdsk C: /f /r /x
/f allow to fix any errors it finds.
/r tells it to locate bad sectors and recover any readable information. (This may result in a blizzard of default named files, all from recovered clusters, that may have to be stitched together later - or abandoned.
/x forces the drive to be dismounted before the fix gets under way.
That is the best I can do, because I am on shakey ground anyway, and more so when it comes to Windows systems. I am sure some search keywords will help.

As a user, and not a programmer, a command line adventure involving fsck gives me a case of nerves, and what I put in the posting was, in fact, the first time I have ever used it. What I posted seems to work, and tentatively, I am going to mark this phenomenon "SOLVED"

That's a sensible instinct! Luckily the tool has the -N option that doesn't actually do anything, just reporting what fsck would do if you let it.