Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Contourné] Impossible de copier sur DD externe

seboseb

Bonjour,
j'ai rénové mon PC, isntallé un Ubuntu sur un SSD et les documents sur un HDD
J'ai un second HDD externe USB, que j'aimerais laisser en permanence branché et sur lequel je souhaite faire des sauvegardes.

Je n'en suis pas encore au paramétrage de rsync que je bute sur un problème : mon disque n'accepte aucune copie.
Je l'avais pourtant testé à l'achat (avant de remanier mon PC), et n'avais pas noté de pb, mis à part le branchement impératif en USB3 sous peine de vitesse extrêmement faible (alimentation insuffisante en USB2)

J'ai un message de "Permission non accordée" lorsque je tente un copier coller.
Voilà ce que donne la commande fdisk -l

seboseb@Seb-SSD:~$ sudo fdisk -l
Disque /dev/loop0 : 89,9 MiB, 93417472 octets, 182456 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop1 : 55,33 MiB, 58007552 octets, 113296 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop2 : 16 KiB, 16384 octets, 32 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop3 : 7,94 MiB, 8306688 octets, 16224 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop4 : 14,87 MiB, 15572992 octets, 30416 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop5 : 16 KiB, 16384 octets, 32 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop6 : 97,6 MiB, 101777408 octets, 198784 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop7 : 7,95 MiB, 8310784 octets, 16232 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/sda : 931,53 GiB, 1000204885504 octets, 1953525167 secteurs
Disk model: Basic           
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x67d8f61c

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sda1              2048 1953523711 1953521664 931,5G  c W95 FAT32 (LBA)


Disque /dev/sdb : 931,53 GiB, 1000204886016 octets, 1953525168 secteurs
Disk model: WDC WD10EARS-00Y
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xf53cf78d

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdb1    *         2048 1953523711 1953521664 931,5G 83 Linux


Disque /dev/sdc : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: SanDisk SSD G5 B
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9e060590

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sdc1    *         2048 976771071 976769024 465,8G 83 Linux


Disque /dev/loop8 : 14,89 MiB, 15589376 octets, 30448 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Le disque qui nous intéresse est le /dev/sda
J'ai tenté un

sudo chmod 777 /dev/sda

sans succès même après redémarrage.

Que puis-je faire d'autre SVP ?

lann

Tu peux donner le retour de

df -h

et dire sur quelle partition tu veux copier tes fichiers
puis donner le retour de

ls -laht

du dossier ou est montée ta partition

seboseb

Merci lann,
je viens de contourner le problème en reformatant en EXT4. Je m'étais dit que le FAT était plus facilement lisible par une autre machine (potentiellement utile pour une sauvegarde) mais tant pis !

Ce qui est tout de même curieux, c'est que mon précédent disque de sauvegarde était en FAT et ne posait aucun problème.

lann

L'idée de sauvegarder des données sur un disque FAT est très mauvaise

Coeur Noir

seboseb a écritLe disque qui nous intéresse est le /dev/sda
J'ai tenté un

sudo chmod 777 /dev/sda

sans succès même après redémarrage.

Peut-être parce qu'il fallait viser la partition sda1 ( le système de fichiers ) et non le disque sda ( périphérique ) ?

Puisque ce stockage est dorénavant en EXT4
⋅ il comprend les droits et permissions spécifiques aux systèmes de fichiers Linux. Les FAT/NTFS du monde windows ne connaissent pas ces subtilités, c'est sans doute pour ça que Lann a écrit « L'idée de sauvegarder des données sur un disque FAT est très mauvaise ». Ça et le fait que la taille maxi d'un fichier sur FAT est de 4Go - ce qui est aussi potentiellement problématique…
⋅ il est donc utilisable uniquement depuis des systèmes Linux ( en gros ),
⋅ je te recommande de laisser cette partition appartenir à root et seulement en droits 755 mais par contre d'y créer
- un dossier où toi seul pourras écrire :

sudo   mkdir   /chemin/vers_partition/'Mon Dossier'

puis de t'approprier ce dossier

sudo   chown   seboseb:seboseb   /chemin/vers_partition/'Mon dossier perso'

et n'accorder tous les droits qu'à l'utilisateur propriétaire via

chmod   755   /chemin/vers_partition/'Mon dossier perso'

- un autre dossier où n'importe qui pourra écrire :

sudo   mkdir   /chemin/vers_partition/'Dossier public'

que tu laisses appartenir à root
mais où tout le monde peut tout faire via

sudo   chmod   777   /chemin/vers_partition/'Dossier public'

seboseb

Merci coeur noir,
il est bon de profiter de l'expérience de ceux qui en ont ! Ca n'a jamais été très clair pour moi, ces histoires de droits. Je connais la théorie mais pas les implications concrètes
.
J'ai fait comme tu l'indiques, et ça fonctionne parfaitement.

Si j'ai bien compris, par défaut, ma partition sda1 appartient à "root" ?
Deuxième question : est-il important de laisser mon dossier public appartenir à "root", ou bien pourrait-il tout aussi bien appartenir à "seboseb" ? Vu que les droits sont ouverts à tous vents...

Coeur Noir

Deuxième question : est-il important de laisser mon dossier public appartenir à "root", ou bien pourrait-il tout aussi bien appartenir à "seboseb" ? Vu que les droits sont ouverts à tous vents...
Pertinente, la question ;-)
En le laissant à root ça limite le risque que n'importe qui puisse changer les droits et permissions sur ce dossier ( seul l'utilisateur propriétaire a ce pouvoir, root dans ce cas ).
Et - à vérifier là je suis moins sûr - ça limite peut-être le risque que n'importe qui efface ce dossier.

Si j'ai bien compris, par défaut, ma partition sda1 appartient à "root" ?
Oui, c'est un support de données, une partition du périphérique disque, on peut laisser ça appartenir au système. Le dossier ( et son contenu ) eux ce sont des données qu'on peut attribuer à un ( ou des ) utilisateur⋅s.

On pourrait l'attribuer à quelqu'un d'autre en particulier, hein, mais il me semble que cette séparation entre « matériel » ( = système ) et « données » ( = utilisateurs, groupes ) est plutôt saine à long terme.

Zakhar

Les réponses de Coeur Noir sont parfaites, mais il faut avoir conscience seboseb que s'il s'agit d'un support physique (qui se démonte), ou si quelqu'un a accès physique à ta machine, tu ne peux rien faire qui te protège à part le chiffrement. En effet, il suffit par exemple de démarrer avec une clé USB et tu as accès à tout.

Par contre mettre des droits corrects (et pas "à tout vent" comme W$ qui en fait ne gère pas du tout les droits POSIX, et pas grand monde n'a envie d'entrer dans la complexité encore bien plus grande des ACL !..) te protègera mieux contre des
- virus et malware (assez théoriques, sauf si tu es vraiment négilgent)
- failles (ça existe)
- erreur de l'utilisateur (le plus fréquent !)

seboseb

OK, coeur noir, c'est très clair et ça me semble en effet assez logique... après-coup ;-)
Et oui, Zakhar, en effet ce ne sera pas une sauvegarde sécurisée... là, l'idée est de pallier une éventuelle défaillance du disque interne qui est vieux, et éventuellement de pouvoir attraper la sauvegarde au passage en cas d'incendie de autre problème grave (je n'ai rien sur le cloud).
Merci à tous les 2 !

Coeur Noir

Concernant Et - à vérifier là je suis moins sûr - ça limite peut-être le risque que n'importe qui efface ce dossier. voir → https://forum.ubuntu-fr.org/viewtopic.php?pid=22261222#p22261222

Donc pour faire en sorte que seul l'utilisateur propriétaire puisse effacer ce qui lui appartient :

sudo   chmod   1777   /chemin/vers_partition/'Dossier public'

dans ce cas seul root a le pouvoir de supprimer Dossier Public mais bidule ou machin pourront toujours effacer ce qui appartient à bidule ou machin à l'intérieur de Dossier Public.

( c'est ainsi que fonctionne le dossier /tmp par exemple ).

Edit : décidément j'ai la mémoire courte. Le bit -t agit sur ce qui se passe dans le dossier. Donc ici si le chemin vers le dossier à protéger est

/media/DiSQUE_2/'Dossier public'

c'est alors sur le dossier

/media/DiSQUE_2

qu'il faut ajouter le sticky bit -t.

Attention au fonctionnement du dossier /media ( voir plus bas ).

seboseb

Décidément... J'ai testé le chmod 1777 sur le dossier public. Eh bien à la première fausse manip avec rsync, aujourd'hui même, toute ma saivegarde a été effacée, dossier public comme privé. Je précise que j'ai utilisé Grsync, peut-être qi'il travaille en "root", et qu'il s'arroge tous les droits. Mais çà m'étonnerait : je n'ai pas saisi mon mot de passe. Bizarre.

Quand à la discussion que tu mentionnes, ça vole bien trop haut pour moi 🙂

Coeur Noir

Ce serait pas plutôt une option de (g)rsync qui aurait fichu la pagaille ?

Je ne suis pas du tout à l'aise avec (g)rsync : à chaque fois que je l'essaie, ça ne fonctionne jamais comme je le crois, même avec sa doc' sous les yeux… donc je ne me permettrais pas de te conseiller à son sujet.

Si tu penses que le bit -t est fautif :

sudo   chmod   a-t   /chemin/vers_partition/'Dossier public'

sudo   chmod   -t   /chemin/vers_partition/'Dossier public'

sudo   chmod  0777   /chemin/vers_partition/'Dossier public'

devrait l'enlever.

seboseb

Lu sur le web, et qui corrobore d'autres lectures :

Le drapeau de suppression restreinte ou le bit sticky est un simple bit dont l'interprétation dépend du système de fichiers. Pour les répertoires, il empêche les utilisateurs non autorisés de supprimer ou renommer un fichier dans le répertoire sauf s'ils sont propriétaires de ce fichier ou du répertoire ; c'est ce qui est appelé le drapeau de suppression restreinte pour le répertoire, et est habituellement trouvé sur les répertoires en écriture ouverte comme /tmp. Pour les fichiers normaux sur des systèmes plus anciens, le bit permet de conserver l'image du programme sur le périphérique d'échange afin qu'il se charge plus rapidement au lancement ; c'est ce qui est appelé le bit sticky.

Quand on lit de vieilles pages de MAN, le "sticky bit" est surtout décrit comme une conservation des fichiers d'un programme dans le SWAP. La fonction sur les machines modernes semble donc différente.
Je viens de faire un petit test, il il semble que ce Sticky bit fonctionne bien, dès lors que le dossier n'est pas vide
Première étape : créer un dossier root avec le sticky bitet le supprimer

seboseb@Seb-SSD:~$ cd /media/seboseb/SEAGATE
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ sudo mkdir test
[sudo] Mot de passe de seboseb : 
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ sudo chmod 1777 test
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ rm test
rm: impossible de supprimer 'test': est un dossier
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ rmdir test

Dossier supprimé sans problème, si on utilise la bonne commande...

Ensuite, créer un dossier avec sticky bit et un fichier texte dedans (j'ai pompé un tuto pour la commande cat 😉 )

seboseb@Seb-SSD:/media/seboseb/SEAGATE$ sudo mkdir test2
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ sudo chmod 1777 test2
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ cd test2
seboseb@Seb-SSD:/media/seboseb/SEAGATE/test2$ cat > fichiertest.txt
trucbidulechouette
[1]+  Arrêté                cat > fichiertest.txt

Revenir dans le répertoire initial et essayer de supprimer le dossier :

seboseb@Seb-SSD:/media/seboseb/SEAGATE/test2$ cd ..
seboseb@Seb-SSD:/media/seboseb/SEAGATE$ rmdir test2
rmdir: impossible de supprimer 'test2': Le dossier n'est pas vide
seboseb@Seb-SSD:/media/seboseb/SEAGATE$

Conclusion, j'ai parlé trop vite, il suffisait de remplir mon Dossier-public pour le protéger...

Coeur Noir

rmdir n'efface un dossier que s'il est vide. C'est plus prudent qu'un rm -rf /vers/dossier qui lui effacerait le dossier même s'il contient quelque chose.

Le sticky bit -t fonctionne pour ce qui est dans le dossier. Seul l'utilisateur propriétaire machin pourra effacer/renommer ce qui appartient à machin dans ce dossier.
C'est donc sur le dossier parent ( contenant ) qu'il faut agir pour protéger un dossier.

Dans ce cas il vaut mieux éviter ce genre de manipulations sur le dossier /media qui a un fonctionnement un peu particulier : le système s'en sert automatiquement pour y monter les médias amovibles, en y créant d'abord un dossier au nom de l'$USER courant, puis dedans un dossier au nom de l'étiquette ou UUID du périphérique qu'on vient de brancher, avec des ACL pour gérer les droits et permissions sur cette ressource, afin que seul $USER puisse y agir. Je suppute très fort qu'ajouter le sticky bit -t à /media ou /media/$USER pourrait perturber ce fonctionnement automatisé.

Par contre, je ne vois pas de risque à le faire sur un dossier créé dans /media si ce dossier a un nom qui n'a aucun risque d'être confondu avec celui d'un $USER du système.
D'où cette astuce : si tu crées un dossier pour point de montage dans /media, nomme le avec des majuscules car le système ne crée jamais de nom d'$USER en majuscules.
Genre :

/media/DATA
ou
/media/HDD-1To

Désolé j'avais manqué de précision J'ai modifié le post #10 en conséquence. Et merci encore à Kamaris.