Cle USB en "Système de fichiers accessible en lecture seulement"

Bonjour à tous,
Bien sûr, ce sujet a été maintes fois abordé.
J’ai trouvé, et lu, plusieurs dizaines de post sur différents forums qui traitent ce problème de clé qui, un jour, se met en mode “Write protect”

Vu le grand nombre de cas très similaires, j’exclue le cas de la panne matérielle. (Possible bien sûr, mais sans doute pas dans les cas signalés)

Dans l’immédiat, j’ai dans mon entourage 3 clés USB qui présentent ce même défaut.
-1- Elles ont jusque là, toutes fonctionné correctement
-2- Elles se retrouvent toutes, pour des raisons pas bien claires, dans un mode qui interdit toute écriture

Cela fait maintenant 2 jours que j’écume les forums et essaie toutes les variantes et solutions proposées. (Surtout celles marquées en Résolu…)
En désespoir de cause, j’ai même téléchargé, installé tous les outils proposés. (Y compris les Win-Tools)
Aucune n’a fonctionné pour ma clé. (Toutes les variantes finissent à un moment par un message type “Commande impossible car la clé est en lecture seule”

Tous les variantes de tentative de re-formatage, supression de partition etc. finissent pareil.

Et le pire de tout, mon fidèle gparted lui-même, refuse de faire avec le même message “system file en read only”

A la fin j’opte pour un brutal #fdisk /dev/sde1
qui immédiatement répond:
fdisk: impossible d’ouvrir /dev/sde1: Système de fichiers accessible en lecture seulement

Et ça m’énerve car je n’y comprend rien !


D’ou ma question:

Quelqu’un a-t-il réellement creusé ce sujet, et pourrait-il nous expliquer ce qui se passe, et ce qu’il y a lieu de faire ?
Visiblement, nous sommes des dizaines à attendre une réelle explication.

D’avance un grand merci, au gourou qui saura nous aider.
Michel

Salut
C’est généralement le symptome d’une clé grillée suite à des passage sur windows/ port usb de télé ou décodeur en ne prenant pas la précaution d’éteindre l’équipement avant l’arrachage bestial de la clé

il semble que l’outil ultime s"appelle schred

https://debian-facile.org/doc:systeme:shred

Merci pour la réponse grandtoubab,
J’ai essayé shred,
réponse:
shred: /dev/sde : erreur d’écriture au décalage 15805952: Erreur d’entrée/sortie
^C

Des centaines de lignes identiques (sauf le nombre), j’ai arrêté avec “^C”

Nb: Cette clé est quasi neuve, presque pas servie…

Je dirai que tu l’as grillée

Cramée qu’elle serait…
Oui, peut-être, mais j’ai vraiment du mal à y croire.

Il y a tout de même beaucoup de remontées similaires qui restent relativement inexpliquées.

J’attends encore un peu, et puis je me résignerai à passer en [Résolu]
Merci grantoubab pour avoir répondu.

La mention “lecture seule” peut concerner plusieurs choses bien distinctes.

  • Un système de fichiers. Soit parce qu’il est intrinsèquement en lecture seule comme ISO 9660, soit parce qu’il est dans un état incohérent et qu’écrire dedans risquerait de provoquer des pertes de données, soit parce qu’il est sur un support de stockage en lecture seule, soit parce qu’il est volontairement monté en lecture seule.

  • Un support de stockage intrinsèquement en lecture seule comme un CD-ROM ; ou bien un support de stockage en lecture-écriture comme une disquette, une carte SD voire certaines clés USB, avec un commutateur de protection contre l’écriture dans la position interdisant l’écriture.

On peut voir si une clé USB est en lecture seule en examinant les derniers messages du noyau avec dmesg juste après l’avoir branchée.
Avec une clé normale :

 [ 4371.144306] sd 2:0:0:0: [sdb] Write Protect is off

Avec une clé en lecture seule :

[ 4469.020188] sd 3:0:0:0: [sdb] Write Protect is on

Par définition, il est impossible d’écrire sur un support en lecture seule par les moyens habituels, que ce soit avec shred, dd, fdisk ou gparted.

Une clé USB peut passer en lecture seule lorsque son contrôleur intégré détecte que l’écriture n’est plus fiable, afin de préserver les données existantes. On part du principe que les données ont plus de valeur que le support.

C’est le principe de la panne : jusque là, ça marchait.
Ce n’est pas comme si les clés USB étaient connues pour leur fiabilité.

J’ai entendu parler de programmes qui s’adresseraient directement au contrôleur intégré de la clé (donc dépendant du type de contrôleur intégré dans la clé) pour le réinitialiser. Je n’en sais pas plus.

Merci PH,
Oui, la clé est maintenant vue systématiquement en “Write Protect is on”

A la réflexion, après avoir vu passer plusieurs clés dans le même état, je fais globalement le constat suivant:
-1- Toutes ces clés ont fonctionné correctement tout le temps qu’elles étaient utilisées sur un même système. (Winxx, Mac, Linux)
-2- Les défauts constatés, ont toujours fait suite à des échanges de fichiers entre systèmes
-3- Le dernier cas (clé 32Go de ma fille), je l’ai observé d’un peu plus prêt. Elle l’utilise en sauvegarde pour ses fichiers importants (!..).
J’y ai observé la présence de nombreux fichiers ET Répertoires qui contiennent toutes sortes de caractères du type “space, # ~ ’ éè @^%:” etc.
Lorsque je lui ai rendu, après lui avoir ajouté de magnifiques photos de ma petite fille, a l’aide de mon PC favori qui tourne sous Debian Stretch, PATATRAS ! Elle voit sa clé vide sous Win10 !!!

Là, j’ai écumé les Forums pour tenter de comprendre et réparer. (Sans résultats probants)
Cependant, j’ai récupéré tous les fichiers, qui sont restés lisible sur ma Debian 9.

Finalement j’ai voulu tenter le “flashage” à neuf de la clé, mais impossible de trouver le code pour cette clé du type VID=058F PID=6387. (générique, mais pas de micro-logiciel de disponible)

Donc, je suis sur le point de laisser tomber.
Mais je fais ce post pour alerter les éventuels lecteurs.

Soyez très prudents, avec le partage de votre clé (formatée FAT), entre Linux et autres systèmes
**Il semble que Linux, dès qu’il détecte une incohérence , déclare le système de fichiers corrompu, et positionne un flag qui force la clé en “Write of” **
A partir de là, vous oubliez (pour toujours) l’écriture sur cette clé !!!..

Sous linux, prends tu toujours soin de faire clic droit sur l’icone de la clé -> éjecter avant de l’arracher sauvagement du port usb :grinning:

Oui toujours,

Sous WinXX, et sous Linux.
Mais sous Linux le plus souvent je fais “démonter le volume” plutôt que “Éjecter”.

Je fais mal ?

Je viens de retrouver ce topic: https://forum.ubuntu-fr.org/viewtopic.php?id=350318
qui discute de ce sujet.
Ici, sur ma Stretch j’ai également les deux options possibles qui sont:
–> Ejecter le volume
–> Démonter le volume
J’avoue ne pas très bien saisir la nuance…

je ne sais pas dire la différence, j’ai des clés avec led quand je fais éjecter je vois bien que la led clignote et que le système agit sur la clé
j’attends toujours la fin des clignotements ( 3 ou 4 secondes) avant de retirer la clé
toujours est-il qu’en 10 ans de linux j’ai pas encore eu de clé cramée

Ok,
ben je vais prendre l’habitude de plutôt passer par "Ejecter"
On verra bien.
Merci.

Quand on fait démonter, la clé est toujours visible dans l’explorateur de fichier Thunar et on peut rouvrir l’arborescence si on clic sur son nom

quand on fait éjecter, la clé n’est plus visible dans l’explorateur de fichier Thunar, elle n’est plus connu du noyau, donc à mon avis électriquement isolée. Si on veut y avoir de nouveau accès il faut la retirer et la rebrancher

D’aillieurs dans l’explorateur de fichiers Nautilus il n’y a que éjecter et on a la notification "peut etre débrancher sans craintes"
c.q.f.d :grinning:

Bonjour

J’ai le même problème de clé Usb qui est passée en"lecture seule" pendant l’installation de Stretch (alors qu’elle était formatée en Ext4) lors de la phase “copie des fichiers”.
Depuis, Gparted détecte bien les deux partitions Ext4 et “Non alloué” mais impossible de modifier ou même lire quoi que ce soit.
Ce n’est pas au cours d’un "arrachage " que le problème est survenu mais bien en cours d’écriture.
Un espoir ou pas ???
Merci beaucoup

Salutations

Peu d’espoir il me semble.
J’ai également déjà eu ce même phénomène.
Et la clé a fini à la poubelle… :disappointed_relieved:

Bonjour

Désolé d’avoir tardé à vous répondre. Je crois effectivement que je vais devoir me résoudre à adopter la même issue que vous !!

Merci pour tout

Salutations

Je n’avais pas vu l’existence de ce sujet, mais ayant été confronté à ce problème pas plus tard que dimanche avec une clef bloquée en lecture qu’on m’a confié, j’ai pas mal creusé le sujet, mais sans résultat.

Avant de mettre à la poubelle, il y a encore des choses intéressantes à voir; lancer

udevadm monitor --environment --udev

puis insérer la clef, et vérifier que la clef a bien le statut Read Only ( DISK_RO=1 ).

Ensuite tenter:
hdparm -r0 /dev/sdx
(=> avec x correspondant à la clef)
Puis plus hard:

hdparm --yes-i-know-what-i-am-doing --dco-restore /dev/sdx

  • voir man hdparm

J’aurai éventuellement d’autres commentaires sur différence entre capacité annoncée de la clef et vue par l’OS, et la capacité réelle de la clef… (!! attention aux clefs chinoises à marques bidons !! / démonstration à l’appui).
Une clef vendue pour 8Go, et vue par “windows” à 7.5Go, peut faire en capacité réelle max 1.8 Go.
Lorsque que le volume écrit dépasse la capacité réelle de la clef, la clef se met en Read Only par firmware.

Si les IDs vendeur/modèle de la clef sont connus, il y a alors l’attaque du firmware avec des outils windows
http://flashboot.ru/files/file/361/

C’est tout, pour le moment, mais mieux vaut partir du principe absolu qu’une clef USB ne peut pas être considérée comme un support “fiable”.

Merci Verner pour ces infos.
Je ne connaissais pas “udevadm monitor”

Cela dit, ici le résultat n’est pas probant.
J’ai lancé la commande clé insérée, mais pas montée, et cela donne:

root: ~# hdparm -r0 /dev/sdf

/dev/sdf:
setting readonly to 0 (off)
readonly = 0 (off)
root: ~# hdparm --yes-i-know-what-i-am-doing --dco-restore /dev/sdf

/dev/sdf:
issuing DCO restore command
SG_IO: bad/missing sense data, sb[]: f0 00 05 00 00 00 00 0a 00 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
root: ~#

Je conserve la clé au cas “ou”
(Sait-on jamais, au cas ou un jour, un outil “magique” ferait son apparition … :wink:
Pour l’instant la clé se monte, est lisible, mais pas “writable”

une vérification sur une clé fonctionnelle indique ça

hdparm /dev/sdb

/dev/sdb:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 multcount     =  0 (off)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 1018/124/62, sectors = 7831552, start = 0