-
LINUX > les clés USB
MONTER UNE CLÉ
sudo mount -t vfat /dev/sda1 /point/de/montage
/dev/sdxxélément à monter/point/de/montagerépertoire dans lequel sera monté le périphérique.Pour avoir les informations sur la clé :
lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sdb └─sdb1 ntfs MP3 9AC97028117E08B1 /media/données sda ├─sda2 ├─sda5 swap fdccf841-faeb-4fe8-abb9-3462ebce47e1 [SWAP] └─sda1 ext4 0a50cda2-c3cb-4817-a66b-5da89af82d7b /La liste affiche les
périphériquesainsi que leurpoint de montagelosqu’ils sont déjà montés.udisksctl mount -b /dev/sdxxsudo udisksctl mount -b /dev/sdxxsudo /sbin/fdisk -l
cat /proc/partitions cat /proc/mounts
Monter une partition WINDOWS
sudo mount -t ntfs /dev/sdxx /point/de/montage
Démonter une clé
sudo umount /dev/sdxxFORMATER UNE CLÉ
Formater en ext3
Démonter la clé avant de formater :
umount /dev/sdxxmkfs -t ext3 /dev/sdc1
Formater en FAT32
Démonter la clé avant de formater :
umount /dev/sdxxmkfs -t vfat -L "nouveau_nom" /dev/sdxx
-Lpour donner un nom à la clé en même temps.sudo mkdosfs -F 32 -I /dev/sdxxErreurs rencontrées
sudo chmod 777 /dev/sdxx // si Error while copying to XXXXX The destination is read-only
RENOMMER UNE CLÉ
Il faut commencer par démonter la clé :
sudo umount /point/de/montagesudo mlabel -i /dev/xxx ::nom_donné
Erreurs possibles
echo mtools_skip_check=1 >> ~/.mtoolsrc // si Total number of sectors (7880) not a multiple of sectors per track (63)!Réparer une clé USB ou carte sd bloquée en lecture seule
L’utilisation conjointe d’un support en FAT32 sur Linux d’une part et Windows d’autre part entraine des problèmes. Cela se traduit généralement par l’impossibilité d’accéder à la clé en écriture, puisque un système de fichiers endommagé est généralement remonté automatiquement en ReadOnly.
Il va falloir recréer un système de fichier sain après avoir mis ses données en sécurité. La démarche est donc la suivante :
Vérifications préalables,
Sécurisation des données existantes,
Tentative de réparation avec l’outil théoriquement approprié,
En dernier recours, destruction et reconstruction du système de fichiers.
Vérifications préalables
À essayer et vérifier avant toute manipulation potentiellement destructrice…
- brancher la clé directement sur un port USB. Certains périphériques ne fonctionnent pas sur un câble USB trop long.
Si usb en façade, essayez un port usb à l’arrière, directement sur la carte mère. Parfois la gestion des alimentations usb ou le partage des périphérique pose des problèmes avec certains matériels.
De manière générale, si vous pouvez écrire avec Windows mais plus avec Ubuntu, vous pouvez éliminer ces cas de figure.
Il se peut aussi tout simplement que l’usage de la commande sudo à la place de gksudo pour des applications graphiques corrompe vos droits sur votre périphérique. Dans ce cas essayez de supprimer ou de renommer le fichier .Xauthority de votre dossier personnel avant tout autre chose avec cette commande par exemple :mv .Xauthority .Xauthority_vieux
Redémarrez votre ordinateur.
Mettre les données existantes en sécurité
Les tentatives de réparation présentées aux chapitres suivants peuvent être destructrices. Il vous faut donc commencer par sauvegarder vos données. Comme certains lecteurs mp3 n’apprécient pas du tout que leurs partitions soient modifiées et pourraient ne plus fonctionner, choisissez ci-dessous parmi les deux options de sauvegarde proposées en fonction de votre type de média.
Attention, la récupération des données dans la sauvegarde de l’ensemble de la clé n’est pas intuitive; faites-vous aider sur le forum si besoin. Cette sauvegarde est aussi, en cas de souci, une sécurité pour remettre la clé dans son état antérieur.
Nota : Si vous n’arrivez plus du tout à accéder à vos données même en forçant le montage en lecture seule, tournez-vous d’abord vers des outils de récupération de données (testdisk, photorec, foremost) avant de reconstruire votre système de fichiers.- Sauvegardez vos fichiers par copie classique : normalement votre clé se monte automatiquement à l’insertion. Utilisez votre explorateur de fichiers pour copier les données dans un dossier de votre espace personnel.
et/ou
- Sauvegardez l’ensemble de la clé (MBR + Partitionnement + données) dans un fichier "image" grâce à un outil adapté. Vous pouvez le faire avec dd, partimage, clonezilla et d’autres… par exemple, avec dd vous pouvez utiliser une commande du type
sudo dd if=/dev/sdf of=/home/mondossier/monimage.img
Bien sûr il faudra personnaliser cette commande en remplaçant par les valeurs appropriées "sdf" "mondossier" et "monimage.img"
Pour identifier quel périphérique (dev) est votre clé (/dev/sd?) vous pouvez utiliser:mount -l
si celle-ci est montée automatiquement, et alors votre clef apparaître en fin de réponse, si elle est le dernier périphérique monté.
Et, clé montée ou pas, vous pouvez utiliser
sudo lsblk -o name,fstype,size,label,mountpoint,uuid
et la repérer à son système de fichiers, sa taille, son étiquette, son éventuel point de montage, ou son UUID.
Ou encore utiliser, sans faire de modification, l’outil de partitionnement graphique gparted: dans sa fenêtre, en haut à droite, il affiche le /dev/sd? concerné, avec possibilité de montrer tous les /dev/sd? présents et reconnus.Tenter de réparer le système de fichiers
Après avoir identifié votre clé (voir paragraphe précédent au besoin), vous allez pouvoir essayer de réparer le système de fichiers qui vous pose problème. L’outil théoriquement adapté est fsck.
Commencez par démonter votre clé, il ne faut pas réparer un système monté :
sudo umount /dev/sdx1
où "/dev/sdx1″ doit être adapté à votre cas (x represente une lettre minuscule: a,b.) Avec cette méthode sous Kubuntu 17.10, le fichier /dev/sdx1 disparaît et fsck ne le trouve pas. Plus simplement, éjecter la clé et la réinsérer. Ensuite, réparez le système de fichier :
sudo fsck -yfv /dev/sdx1
où "/dev/sdx1″ doit être adapté à votre cas. Attention les options passées forcent la vérification et la réparation sans votre consentement. Pour plus d’infos, consultez le man de fsck ou sa page de documentation Ubuntu-fr.
Si après cette étape, en éjectant la clé et en la rebranchant le montage ne s’effectue toujours pas en "rw" (ReadWrite, lecture-écriture) et que l’erreur persiste, il ne vous reste plus que l’option "brutale" du chapitre à suivre…
Reconstruction d’un système de fichier
Si vous avez loupé le début… reprenez ce tutoriel et assurez vous d’avoir sauvegardé vos données.
Nous allons ici en dernier recours détruire le système de fichier existant et le reconstruire. Il est possible de le faire graphiquement ou en ligne de commande dans un terminal ou une console.
Graphiquement
Sous Unity et Gnome
Ouvrez l’éditeur de partition, en faisant une recherche dans votre tableau de bord avec le mot clé "partition". Pour cela vous devez avoir installé le paquet gparted.
Dans le menu Gparted>Périphérique choisissez votre clé USB.
Ensuite, si elle ne l’est pas, démontez votre clé : allez dans Partition>Démonter.
Créez maintenant une nouvelle table de partitions : Périphérique → Créer une table de partitions
Puis créez une nouvelle partition et formatez la en FAT32 Partition → Nouveau
Appliquez toutes les opérations dans le menu « Édition ».
Normalement à ce stade votre clé est à nouveau fonctionnelle. Débranchez et rebranchez puis copiez vos données en sécurité.
Sous KDE
Pré-requis : Vous devez avoir installé le paquet partitionmanager.
Ouvrez l’éditeur de partition, Applications → Système → Partition Editor (KDE partition Manager).
Dans la fenêtre Périphériques, sélectionnez votre clé USB
Ensuite démonter votre clé, clic droit puis Libérer.
Et recréer la partition Fat32, clic droit, Nouvelle.
Dans la nouvelle fenêtre choisir le système de fichier fat32, puis OK.
Et enfin dans le menu cliquez sur « Appliquer ».
Dans un terminal ou une console
Démonter avant tout la clé :
sudo umount /dev/sdx # voir la note suivante x n'est qu'un exemple il faut utiliser sdb ou sdc ou sdd ou sde ou sdf ou etc !!!!!!!
où il faudra adapter /dev/sdx à votre cas (x représente une lettre minuscule ex:a,b.).
Puis, recréer un système de fichier :
sudo mkfs.fat -I -F 32 /dev/sdxn # xn vaut b1 ou b2 ou c1 ou c2 ou
en général et sauf exeption on formate une partition , pas une clé , il faut donc indiquer le numéro de la partition à formater n qui prendra la valeur 1 ou 2 ou 3 ou ….. !!!!!! où il faudra adapter /dev/sdxn à votre cas, et éventuellement la valeur du paramètre -F si vous souhaitez de la FAT16 ou FAT32. il faudra donc utiliser sdb1 ou sdc1 ou sdd1 [ou sdb2 ou sdc2 ou etc !!!!! ]
Si ça ne fonctionne toujours pas
Si vous mettez la mauvaise lettre genre sda, sdb,… la table de partitions sera perdue et il faudra réécrire cette dernière via testdisk pour détecter les partitions et les restaurer.
Repérez au dernier moment par
sudo lsblk -o name,fstype,size,mountpoint,label
la lettre "x" correspondant momentanément à votre clef.
Aussitôt après, lancez ces commandes sur sdx (sans chiffre, et en adaptant la lettre du disque au vôtre) :sudo dd if=/dev/zero of=/dev/sdx bs=512 count=4096 sudo apt install mbr sudo install-mbr /dev/sdx --force -t 0 -e 1
Enfin créez et formatez sdx1 (avec chiffre, cette fois) :
sudo mkfs.fat -I -F 32 /dev/sdx1
Si vous obtenez des messages d’erreur, ouvrez un fil sur le forum.
L’ancien remède consistant à écrire des zéros sur le seul premier Mio (…bs=512 count=2048) ne suffit pas avec beaucoup de gravures modernes. Explications aux messages 27 (résumé) et 19 (détaillé) de cette discussion « Page USB-Creator du Wiki »Le problème entre Linux et FAT32
FAT32 ne gère ni les droits (lecture, écriture, exécution) ni les attributions (groupe, propriétaire). Pour contourner cette imperfection et s’assurer de pouvoir accéder à la clé en FAT32, il est donc parfois utile de la remonter avec l’option « umask=0 »:
sudo umount /dev/sdf1 && sudo mount -o umask=0 /dev/sdf1 /media/usbdisk
À partir de trusty:
sudo umount /dev/sdf1 && sudo mount -o umask=0 /dev/sdf1 /media/$USER/usbdisk
où il faudra adapter /dev/sdf1 et /media/usbdisk à votre situation.
Voilà, votre clé devrait être pleinement fonctionnelle.
—
auto mount a flash drive with root and rwx privileges
I have an issue with mounting my Flash drive on Ubuntu 10.04 with write privileges. It’s currently partitioned as Fat32 with Label KINGSTON but when I insert it into the Laptop it reads it as usb0, read-only privileges.
What I’ve had to do so that it is writable is to unmount it using Disk Utility and mount it again, and then it picks it up as KINGSTON with root privileges.
What I want is to automatically mount the flash drive with root privileges without going to Disk Utility to set this. Any help would be appreciated.
is your user in the plugdev group?
Open the terminal using:
Menu: Applications menu -> Accessories -> Terminal.Keyboard Shortcut: Ctrl + Alt + T
And type the following:
sudo fdisk -l
The output should be similar to:
karthick@Ubuntu-desktop:~$ sudo fdisk -l Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00af00af Device Boot Start End Blocks Id System /dev/sda1 * 1 3188 25607578+ 7 HPFS/NTFS /dev/sda2 3189 4462 10233405 83 Linux /dev/sda3 4463 19458 120449002+ f W95 Ext'd (LBA) Partition 3 does not end on cylinder boundary. /dev/sda5 4463 9561 40957686 7 HPFS/NTFS /dev/sda6 9562 14660 40957686 7 HPFS/NTFS /dev/sda7 14661 19255 36905984 83 Linux /dev/sda8 19255 19458 1626112 82 Linux swap / Solaris Disk /dev/sdb: 4022 MB, 4022337024 bytes 255 heads, 63 sectors/track, 489 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000b5e92 Device Boot Start End Blocks Id System /dev/sdb1 1 489 3927861 7 HPFS/NTFS
My flash drive is located at /dev/sdb1 (yours may vary).
Make the following ajustments:For NTFS file system:
You should edit the fstab file. Type the following in terminal:
sudo gedit /etc/fstab
At the bottom of the fstab file paste the following:
/dev/sdb1 /media/Datas ntfs-3g defaults 0 0
For FAT 16/32 file system run the following in terminal:
sudo mount -t vfat /dev/sdb1 /media/Datas -o uid=1000,gid=100,utf8,dmask=027,fmask=137
Note: You should create the mount point, in terminal type the following:
sudo mkdir /media/Datas sudo mount -a
This might sound like a bizarre answer, but I just ran into the same problem - it’s worth a look.
Make sure you don’t have the usbmount application installed - it seems to cause conflicts and mounts your USB drives to the "usb#" folders that you mentioned.
More information is available in the related Ubuntu forums post.
—
C’est usbmount qui monte automatiquement les clés, et non pmount.
Si tu n’avais pas installé usbmount, tu monterais les clés manuellement avec pmount.
Là, du coup, c’est usbmount qui s’en charge.
Sauf que, pour une clé fat, il faut donner des droits particuliers lors du montage auto.
Donc, si tu veux utiliser usbmount, il te faut éditer le fichier /etc/usbmount/usbmount.conf, puis repérer la ligne FS_MOUNTOPTIONS tout en bas, et la modifier comme suit :FS_MOUNTOPTIONS="-fstype=vfat,gid=plugdev,fmask=0002,dmask=0002"
De manière à ce que seuls les membres du groupe plugdev puisse modifier son contenu (mais qu’ils le puissent tout de même…)
Si tu utilises aussi des clés usb formatées en ntfs (montées soit par "ntfs" soit par "ntfs-3g"), probablement voudras-tu ajuster la ligne pour qu’elle leur réserve le même sort lors du montage :FS_MOUNTOPTIONS="-fstype=vfat,gid=plugdev,fmask=0002,dmask=0002 -fstype=ntfs-3g,gid=plugdev,fmask=0002,dmask=0002 -fstype=ntfs,gid=plugdev,fmask=0002,dmask=0002"
@tagada (bis): inutile de désinstaller et réinstaller pmount. S’il y est, c’est très bien, pas besoin de le virer et de le remettre
@smolski: faut arrêter avec les chmod/chown sur du fat32 ou du ntfs, ça ne marche pas—
J’ai une clé usb qui sans prévenir, s’est mise en lecture seule…. Je décide donc de changer les permissions via la commande chmod.
Je tape donc la commande sudo chmod a+rwx /media/xavier/USB DISK, la réponse étant la suivante:
chmod: impossible d’accéder à «/media/xavier/USB»: Aucun fichier ou dossier de ce type
chmod: impossible d’accéder à «DISK»: Aucun fichier ou dossier de ce typepourtant j’écris bien le bon chemin! Pour vérifier je me place dans le dossier /media/xavier/USB DISK et tape ls et je vérifie s’il y a bien tous mes dossiers et effectivement je retrouve la liste de ces derniers .
Je test ls /media/xavier et cela me renvoie bien USB DISK, par conséquent le dossier USB DISK existe bien!
Question: Pourquoi la commande sudo chmod a+rwx /media/xavier/USB DISK m’indique qu’il n’y a pas de dossier USB DISK? Ce qui m’empêche de changer les permissions et donc de pouvoir réutiliser ma clé
1/ je débranche la clé usb et la remets et, là, c’est magique, elle redevient normale.
2/ si ça marche pas je faissudo chown -R user:user /media/user
"user" = mon user
C’est expliqué ici.
Pourquoi la commande sudo chmod a+rwx /media/xavier/USB DISK m’indique qu’il n’y a pas de dossier USB DISK
ton problème vient du fait qu’il y a un espace dans le nom
essaies
sudo chmod a+rwx "/media/xavier/USB DISK"
Ceci mis à part et strictement entre nous, quel est le format de ta clef USB ?
Tu as obtenu la réponse à la question que tu avais posée, puisque f.x0 t’a montré comment éviter l’erreur de syntaxe.
=============
Maintenant il faut prendre les bonnes habitudes : le diagnostic avant le remède.
Que dirais-tu si, consultant pour une infection, on te posait un plâtre ?Tu dis en #1 :
J’ai une clé usb qui sans prévenir, s’est mise en lecture seule
Eh bien la première chose à faire, c’est de chercher pourquoi.
Modifier a priori les droits sur une clef usb qui marchait bien jusque là, c’est un contresens.J’espère que tu n’as pas appliqué le bricolage proposé en #2. Parce que dans 14.04 et suivantes, /media/user a pour propriétaire root:root, c’est normal.
Donc pour repartir sur de bonnes bases, branche ta clef et donne
sudo fdisk -l
qui répond à la question posée par Braun,
lsb_release -d
qui nous dira quelle version d’Ubuntu tu utilises
mount dmesg | tail -n 30
qui nous donneront des détails sur la façon dont ta clef est montée.
Merci !Si je puis me permettre, j’ajouterai la commande :
ls -l /media/$USER
afin de voir les droits et propriétés de cette clé (celle-ci étant montée, bien sûr).
@moko138: sawen93 s’ennuie de toi pour son souci de démarrage…
sinon il y a un bout de tuto sur le site : https://doc.ubuntu-fr.org/tutoriel/comm … r_clef_usb
On y apprends entre autre que cela peut venir d’un problème de .Xauthority..
J’espère que tu n’as pas appliqué le bricolage proposé en #2. Parce que dans 14.04 et suivantes, /media/user a pour propriétaire root:root, c’est normal.
Autant pour moi.
Si je puis me permettre, j’ajouterai la commande :
ls -l /media/$USER
afin de voir les droits et propriétés de cette clé (celle-ci étant montée, bien sûr).
@moko138: sawen93 s’ennuie de toi pour son souci de démarrage…
Très juste ! j’ajouterais même un "a" :
ls -la /media/$USER
—
Pour sawen93, c’est faitMerci pour toutes vos réponses précises comme d’habitude.
J’ai testé la manip proposé en #2 sans résultat. J’ai ensuite voulu testé la clé sous windows seven et la pas de problème, je pouvais copier, effacer enregistrer des fichiers sur la clé.
Je teste alors la clé sur un autre pc (sous kubuntu 14.04.3) et la encore pas de problèmes, je recommence la manip sur mon pc et miracle tout refonctionne!!!
Je peux à nouveau réutiliser normalement ma clé.
Comme le dit moko138, j’aimerais savoir pourquoi ce problème est arrivé, je suis les manips proposées et :
1) la syntaxe sudo chmod a+rwx "/media/xavier/USB DISK" ne me revoie plus d’erreur (merci je ne connaissais pas l’astuce des guillemets)
2) la clé est au format fat 32
3) j’utilise kubuntu 14.04.3
3)mount renvoie:/dev/sda1 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/cgroup type tmpfs (rw) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755) none on /sys/fs/pstore type pstore (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd) /dev/sdb1 on /media/xavier/USB DISK type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,flush,uhelper=udisks2)
4) dmesg | tail -n 30 renvoie:
[11071.645441] vgaarb: this pci device is not a vga device [11372.096379] vgaarb: this pci device is not a vga device [11672.012628] vgaarb: this pci device is not a vga device [13677.347229] vgaarb: this pci device is not a vga device [13920.599945] vgaarb: this pci device is not a vga device [13938.493636] vgaarb: this pci device is not a vga device [13962.822331] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd [13962.849051] usb 4-2: New USB device found, idVendor=13fe, idProduct=5500 [13962.849057] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [13962.849060] usb 4-2: Product: USB DISK 3.0 [13962.849063] usb 4-2: Manufacturer: [13962.849065] usb 4-2: SerialNumber: 070B4C13A6A99E81 [13962.850567] usb-storage 4-2:1.0: USB Mass Storage device detected [13962.850701] scsi8 : usb-storage 4-2:1.0 [13963.852829] scsi 8:0:0:0: Direct-Access USB DISK 3.0 PMAP PQ: 0 ANSI: 6 [13963.853605] sd 8:0:0:0: Attached scsi generic sg2 type 0 [13964.301435] sd 8:0:0:0: [sdb] 30965760 512-byte logical blocks: (15.8 GB/14.7 GiB) [13964.302624] sd 8:0:0:0: [sdb] Write Protect is off [13964.302631] sd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00 [13964.303880] sd 8:0:0:0: [sdb] No Caching mode page found [13964.303886] sd 8:0:0:0: [sdb] Assuming drive cache: write through [13964.309819] sdb: sdb1 [13964.313762] sd 8:0:0:0: [sdb] Attached SCSI removable disk [14032.054693] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [14218.370934] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [14218.388092] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ef356f00 [14218.388102] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ef356f30 [14258.459483] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [14258.476565] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ef356f00 [14258.476576] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ef356f30
pour le 3 et 4 je ne comprends rien….
5) ls -la /media/$xavier renvoie
total 12 drwxrwxrwx 3 root root 4096 août 10 22:18 . drwxr-xr-x 22 root root 4096 déc. 21 11:41 .. lrwxrwxrwx 1 root root 45 août 10 20:43 .directory -> /etc/kubuntu-default-settings/directory-media lrwxrwxrwx 1 root root 42 août 10 20:43 .hidden -> /etc/kubuntu-default-settings/hidden-media drwxrwxrwx+ 3 xavier xavier 4096 janv. 27 19:48 xavier
pas trop compris non plus!
merci pour vos explications
xd1
S’il te plaît, peux-tu modifier ton message #10 pour y encadrer chaque retour de commande par des balises-code (les < > bleus de la barre de mise en forme) comme indiqué là par ljere, et conformément aux règles du forum.
Je teste alors la clé sur un autre pc (sous kubuntu 14.04.3) et la encore pas de problèmes, je recommence la manip sur mon pc et miracle tout refonctionne!!!Je le savais, c’est de la magie.
Eh non pas de magie ! Juste des règles.
1) la syntaxe sudo chmod a+rwx "/media/xavier/USB DISK" ne me revoie plus d’erreur (merci je ne connaissais pas l’astuce des guillemets)
Il est aussi astucieux de donner toi-même (depuis gparted) à chaque partition une étiquette (en anglais: label) sans espace ni accent. Elle servira automatiquement de point de montage et ça évite le souci.
mount a écrit :
/dev/sdb1 on /media/xavier/USB DISK type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,flush,uhelper=udisks2)montre que le système voit correctement la clef en fat32, la monte en lecture-écriture, avec le bon propriétaire.
dmesg a écrit :
[14032.054693] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.montre que tu ne démontes pas toujours tes périphériques avant de les débrancher.
Le remède n’est pas fsck (cf. Maintenance des supports de stockage et des micrologiciels). Le remède est sous windows, au minimum clic droit puis "vérifier". Ou, mieux :chkdsk /r X:
en remplaçant "X" par la lettre que windows attribuera à la partition de ta clef.
- -Il est presque toujours préférable de copier-coller les commandes et leurs retours. C’est
ls -la /media/$USER
qui t’était demandé, or tu as fait
ls -la /media/$xavier
qui est différent (et que, semble-t-il, le système a interprété - sans message d’erreur pour une raison qui m’échappe - comme "ls -la /media").
Pour info, le symbole "$" dit au système qu’il a affaire à la variable nommée juste après. Et USER réfère à l’utilisateur courant.
Donc soit on met $USER soit on met xavier, mais pas $xavier.Je ne commenterai pas les deux liens (lignes commençant par un "l") vers /etc/kubuntu-default-settings/… Car c’est peut-être propre à KDE, que je ne connais presque pas.
Mais si c’est bien "ls -la /media" qui a été exécuté, ça confirmerait deux corruptions, la corruption de /media qui apparaît ainsi :drwxrwxrwx 3 root root 4096 août 10 22:18 .
ce qui est dangereux. Au lieu de
drwxr-xr-x 3 root root 4096 août 10 22:18 .
Ça, ça peut se corriger facilement.
Mais il y a une autre corruption :drwxrwxrwx+ 3 xavier xavier 4096 janv. 27 19:48 xavier
là où j’attendais
drwxr-x---+ 3 root root 4096 août 10 22:18 xavier
Le signe "+" indique des des ACL sont en jeu (ACL pour "Access Control Lists"/"Listes de Contrôle d’Accès"). J’ai rédigé là-bas ./viewtopic.php?pid=18082171#p18082171 le peu que j’en ai compris.
Et ça, j’ignore leurs réglages originels, je suppose sans certitude qu’elles ont été corrompues et, dans cette éventualité, j’ignore comment rétablir leurs réglages d’origine.Donne exactement
ls -la /media/$USER
mais je crois que le plus raisonnable serait de réinstaller après sauvegarde des données.
C’est en tout cas, ce que je ferais s’il s’agissait de mon système.Retiens au moins ceci :
===================================
Avant de toucher aux fichiers et répertoires du système, on se réfère
- de préférence aux manuels officiels (commande "man"),
- sinon, à la Documentation,
et au moindre doute, on demande confirmation plutôt trois fois qu’une.
===================================C’est
ls -la /media/$USER
qui t’était demandé, or tu as fait
ls -la /media/$xavier
qui est différent (et que, semble-t-il, le système a interprété - sans message d’erreur pour une raison qui m’échappe - comme "ls -la /media").
C’est normal, xavier n’étant pas une variable d’environnement, $xavier est vide, et la commande est syntaxiquement correcte.
Merci de l’explication, pingouinux !
En référence aux messages #1 #2 et #3 de la discussion, c’est toujours une mauvaise idée de modifier les droits et propriétés de répertoires qui sont et doivent être gérés par le système sous "root". Ça ne débouche généralement que sur une construction bancale qui ne fonctionne pas ou mal…
Le système monte automatiquement "à la volée" les volumes externes lors de leur connexion, il ne faut donc pas les décrire dans /etc/fstab qui lui, fait monter les volumes "dits internes" au moment du démarrage.
Par convention, dans les *buntu, les montages "externes" sont placés dans le répertoire /media/$USER. Dans d’autres distributions, ils peuvent être dans /media, voire parfois dans /mnt.
Pour les *buntu, le répertoire /mnt doit être réservé aux montages temporaires manuels, via "mount".Les montages "internes" sont à placer ailleurs que dans /media, /media/$USER ou /mnt, ma préférence va à la racine même du système.
Pourquoi à la racine ? Parce-que lorsqu’on crée un point de montage à l’installation du système, il est créé à la racine, voilà tout !Bien sûr, rien de tout cela n’est obligatoire, chacun est libre de faire ce qu’il veut de son système et de monter ses volumes où bon lui semble, ce ne sont là que conventions, mais quant à utiliser une certaine distribution, autant se conformer à ses règles, non ?
Le propriétaire des répertoires "/media" et "/media/$USER" (où $USER représente le nom de l’utilisateur) est "root". Le sous-répertoire créé avec le nom (si étiquette) ou l’UUID du volume sera donc "/media/$USER/volume" et il appartient à l’utilisateur.
Lorsqu’un volume externe est monté automatiquement, il l’est en principe avec les droits de lecture/écriture pour le propriétaire qui est l’utilisateur.On peut, bien sûr, lorsqu’on ajoute ultérieurement un nouveau volume à son système, l’affecter "a posteriori", on ne va pas réinstaller pour ça, mais il est alors bon de le faire en observant les règles qui régissent les autres montages de même type, et de paramétrer correctement le fichier /etc/fstab (notamment si le volume est en NTFS, par exemple) pour obtenir les bons droits et propriétés.
En général, ça évite d’aller bricoler les droits avec des "chown" et des "chmod" pour finalement risquer de se retrouver "en short" !sans renter dans la discussion sur les commandes chmod ou autres, un conseil à appliquer:
faire la chasse systématique aux espaces dans les noms de fichiers et des dossiers.
Exemple au poste #1:sudo chmod a+rwx /media/xavier/USB DISK
où l’OS cherche à faire un chmod sur /media/xavier/USB puis sur DISK…
Pas de problème d’interprétation pour Linux si on lui donne la bonne syntaxe ou si on supprime les espaces dans les noms.@sinbad83: Dans l’absolu, tu as parfaitement raison, mais s’agissant de clé USB, elles sont déjà formatées la plupart du temps avec un nom de périphérique "à la noix" qu’on ne choisit pas, d’où le "USB DISK" par exemple…
À moins de partitionner / formater sa clé avant tout usage, on n’est pas maître du nom qu’elle porte.Mais il y a une autre corruption :
drwxrwxrwx+ 3 xavier xavier 4096 janv. 27 19:48 xavier
là où j’attendais
drwxr-x---+ 3 root root 4096 août 10 22:18 xavier
Le signe "+" indique des des ACL sont en jeu (Access Control Lists).
Les montages "automatiques" se font dans /media/<user>
ls -la /media ls -la /media/$USER
Exécuter une commande lors de l’insertion d’un clé spécifique
execute () { DRIVE="/dev/sdb1" if mount | grep -q $DRIVE; then // ... fi; }