[Résolu] Souci de permissions rwx lors de màj (partition ext4)

Pardalis · Le 15/09/2022, à 15:45

Bonjour à tous,

j'ai résolu ce problème en cherchant moi-même, mais je pense que ce sujet peut servir à d'autres (y compris à moi-même dans quelques années, lors de la MàJ vers la future nouvelle LTS). Au passage, si certains, plus chevronnés que moi, tombent dessus, ils pourront commenter ce que j'ai fait modestement (si ça se trouve, je me suis compliqué la vie ou la solution que j'ai trouvée est dangereuse).

Voici le problème :
Après la màj Ubuntu 20.04 -> 22.04 (qui s'est très bien passée), je n'ai plus eu accès qu'en lecture seule à mon disque dur n°2, celui que j'utilise pour stocker les photos que je prends depuis de nombreuses années et que j'améliore. Je ne pouvais donc plus rien modifier, synchroniser ni ajouter... ce qui est embêtant pour un disque de stockage et de sauvegarde. Je précise que mon disque dur n°2 est formaté en ext4 (ça a son importance !).

La solution n°1 (qui n'a pas marché, mais qui peut marcher chez d'autres) :
Je l'ai trouvée ici.

Je résume en vous mettant comment j'ai fait :

Pour ouvrir un terminal : Ctrl+Alt+t
Dans le terminal : sudo fdisk -l

Là, vous avez beaucoup de blabla qui commence par Disque /dev/loop suivi d'un chiffre : scrollez jusqu'à tomber sur un tableau avec les entrées Périphérique|Amorçage|Début|Fin|Secteurs|Taille|Id|Type. D'après la taille indiquée, vous comprenez si le disque qui vous pose problème s'appelle /dev/sda1, /dev/sda2 etc. S'il n'apparaît pas, scrollez plus bas, jusqu'au tableau suivant (le mien s'appelait /dev/sdb4).

Une fois que vous avez l'info, toujours dans le terminal : blkid

Maintenant, vous avez un tableau avec les UUID (= les identifiants) de chaque partition (exemple : ma partition sdb4 a l'identifiant UUID "d0d1aa98-e611-4630-816e-74f5cc59306a")

Toujours dans le terminal : ll /media/[VotreNomUtilisateur]

Je précise : la commande ll, ce sont deux L minuscules (pas deux i majuscules). Là, ça vous affiche les UUID des partitions montées dans le dossier /media/[VotreNomUtilisateur] avec les permissions associées (drwxrwxrwx si tout le monde a toutes les permissions). À ce stade, si vous avez un - à la place d'un r, w ou x, c'est qu'un utilisateur n'a pas ces autorisations (a priori, vous êtes l'utilisateur du milieu dans rwxrwxrwx et celui qui vient avant est l'admin root).

Si c'est ça votre problème (ce n'était pas le mien), il vous reste deux commandes à taper dans le terminal et c'est plié :

sudo chgrp adm /media/[VotreNomUtilisateur]/[l'UUID de la partition concernée]

sudo chmod g+w /media/[VotreNomUtilisateur]/[l'UUID de la partition concernée]

Et voilà !

La solution n°2 (celle qui a marché) :
Je l'ai trouvée ici, vers la fin de la discussion.

Toujours dans le terminal, vous pouvez tenter un : sudo chown [VotreNomUtilisateur] -R /media/[VotreNomUtilisateur]/[l'UUID de la partition concernée]

Si vous ne savez pas ce qu'est une UUID, c'est que vous n'avez pas lu la solution n°1. Il y a peu de chances que ça marche si la solution n°1 n'a rien donné. En tout cas, chez moi, ça n'a pas marché : mon DD n°2 était toujours en lecture seule. En fait, il semble que le problème venait du disque lui-même, qui comportait des incohérences. Il fallait donc la formule magique pour tout réviser et tout corriger.

Dans le terminal, il faut "démonter" la partition en cause : umount /dev/[NomDeVotrePartition] (rappel si vous n'avez pas lu ce qui précède : pour moi, le nom de la partition était sdb4).

Ensuite, toujours dans le terminal, la commande magique : sudo fsck.ext4 -f /dev/[NomDeVotrePartition]

Le .ext4 après fsck, c'est parce que mon disque est formaté en ext4 : ne le faites pas si vous avez un disque formaté en ext3, fat32 etc. L'utilitaire fsck qui va se lancer (en français !) va parcourir votre partition problématique et vous proposer des corrections. J'ai mis "o" pour "oui" à tout ce qu'il m'a proposé car ça m'a paru cohérent (je ne sais pas si j'ai bien fait). Toujours est-il que ça a marché.

N'oubliez pas, ensuite, de remonter votre partition démontée, en entrant dans le terminal : mount /dev/[NomDeVotrePartition]

Et voilà !

Si j'ai pu vous aider, je suis ravi. Si j'ai écrit des bêtises, veuillez me pardonner et n'hésitez pas à les corriger.

Coeur Noir · Le 15/09/2022, à 17:13

Hello,

tu devrais t'intéresser aux définitions et fonctions :
⋅ montage
⋅ partitions
⋅ fstab
⋅ droits et permissions
⋅ le rôle des dossiers « système », notamment /media
→ n'hésite pas à parcourir la doc' à ces sujets.

Un peu de lecture :
⋅ https://forum.ubuntu-fr.org/viewtopic.p … #p22585291 → les questions à se poser avant de « faire » un montage.
⋅ https://forum.ubuntu-fr.org/viewtopic.p … #p22583206 → à propos du dossier /media ( et plus précisément /media/$USER ).
⋅ https://forum.ubuntu-fr.org/viewtopic.p … #p22585820 → à propos de fstab.

Tu es donc arrivé à tes fins par des chemins quelque peu tortueux ;-)
Et si la situation finale est fonctionnelle pour toi, elle n'est cependant pas « idéale » à tous les contextes ( multi-utilisateurs… )

Dernière modification par Coeur Noir (Le 15/09/2022, à 17:44)

erresse · Le 15/09/2022, à 18:18

Bonjour,
Les commandes passées dans un terminal n'ont rien de magique, il faut toutefois bien comprendre leur utilité et leur fonctionnement.
La toute première étape de la résolution d'un problème consiste à poser le problème, justement.
Donc, quelle était ton problème ? Ton volume de disque externe était passé en "lecture seule". Investiguons...
- Dans un terminal (Ctrl+Alt+T ou depuis menu ou icône), on va d'abord afficher les caractéristiques de ce volume :

ll /media (ou ls -la /media

Cette commande va lister le répertoire dans lequel le système monte par défaut les volumes externes des utilisateurs.
Elle indique que le répertoire lui-même (/media) appartient à "root" et qu'il contient un sous-répertoire par utilisateur ($USER). Les droits d'accès à ce répertoire sont : Utilisateur root=RWX, Groupe root=RX, Autres=RX.

ll /media/$USER

La commande va nous lister les volumes contenus dans le répertoire de l'utilisateur (/media/$USER) et leurs caractéristiques. Elle indique que le répertoire lui-même (/media/$USER) appartient également à "root" et qu'il contient un point de montage pour chaque volume externe monté pour l'utilisateur. Les droits d'accès à ce répertoire sont : Utilsateur root=RWX, Groupe root=RX, Autres=--- (Aucun droit).
Chaque volume est identifié soit par son UUID s'il ne possède pas de nom, soit par l'étiquette qui lui a été attribuée lors de sa création (par exemple avec l'application graphique Gparted). Ces volumes doivent appartenir à l'utilisateur ($USER et à son groupe qui est généralement identique à $USER). Les droits d'accès à ces volumes sont : Utilisateur $USER=RWX, Groupe $USER=RX, Autres=RX.
- À ce stade de la procédure, tu peux vérifier que ce volume appartient bien à l'utilisateur $USER et qu'il a bien les droits d'accès à RWX,RX,RX. Si tel est le cas, le problème N'EST PAS un problème de droit d'accès au volume et, dans ce cas, il faut chercher ailleurs la raison du blocage en lecture seule (probablement un dysfonctionnement matériel).
La réparation ou l'échange du volume défectueux règle alors le problème.
En gros, c'est ta solution 2.

Si le volume n'appartient pas à l'utilisateur $USER ou qu'il ne dispose pas des droits d'accès adéquats, il va alors falloir les modifier pour rétablir la situation.
La commande "chown" permet de changer l'appartenance du volume afin qu'il devienne la propriété de l'utilisateur $USER et, éventuellement, de son groupe. On pourra donc passer la commande :

sudo chown -R $USER[:$USER] /media/$USER/<id_volume>

Où l'option -R applique la commande récursivement à tous les objets (répertoires et fichiers) contenus dans le volume. Comme le répertoire /media/$USER appartient à root, il est nécessaire d'utiliser "sudo" pour passer la commande.
Si les droits d'accès sont incorrects, il faudra les changer avec la commande "chmod" qui permet de modifier les droits d'accès à un volume. On pourra donc passer la commande :

sudo chmod -R u=rwX[,g=rX[,o=rX]] /media/$USER/<id_volume>

Où l'option -R applique la commande récursivement à tous les objets (répertoires et fichiers) contenus dans le volume.
Même remarque concernant l'appartenance du répertoire /media/$USER à root.
Le droit d'accès X (au lieu de x) permet de limiter ce droit aux seuls répertoires. Il signifie alors "search" et non "execute" qui s'applique aux fichiers exécutables.
En gros, ce sont là les éléments de ta solution 1 (en expliquant un peu les commandes utilisées).

Dernière modification par erresse (Le 16/09/2022, à 11:36)

Coeur Noir · Le 15/09/2022, à 18:56

Mmm… avec un gros oubli Erresse concernant /media et /media/$USER → les ACL qui sont un cas un peu particulier spécifique à ce dossier à cause de udisks / udisksctl qui se chargent du montage automatique des supports nomades~amovibles ! ( depuis bientôt 10 ans sous ×buntu. )

ls -la /media
total 24
drwxr-xr-x   6 root root 4096 juin  10 04:02 .
drwxr-xr-x  19 root root 4096 sept. 12 13:50 ..
drwxr-x---+  2 root root 4096 juil. 19 19:41 a×××××××××
drwxr-x---+  2 root root 4096 sept.  5 13:37 c×××××
drwxr-xr-x  14 root root 4096 août   6 20:19 DATA
drwxr-x---+  2 root root 4096 sept.  4 14:00 django

Repère les + à la suite des droits : ils indiquent la présence d'ACL.

Le dossier DATA je l'ai créé manuellement, c'est le point de montage d'un gros disque ( interne, permanent ) contenant essentiellement les données visibles des utilisateurs.
D'ailleurs tous ces dossiers sont des points de montage, d'où leur appartenance légitime à root ( c'est du matériel, des partitions, c'est géré par le système. )

C'est grâce à ces ACL que seul django a le droit d'écrire~modifier dans /media/django bien que ce dossier django ne lui appartient pas / appartient à root !

Il ne faut donc surtout pas toucher aux droits des divers dossiers /media/$USER créés automatiquement par udisks / udisksctl au risque de perturber l'automatisme de montage des supports nomades~amovibles,
ni créer manuellement un tel dossier s'il n'existe pas déjà : udisksctl crée un tel dossier $USER lors du branchement à chaud d'un support nomade~amovible, ou lors de la sollicitation via l'explorateur de fichiers d'une partition de support interne qui n'est pas inscrite dans /etc/fstab et une fois créé par cet automatisme, le dossier $USER demeure ( on pourrait l'effacer, il serait reconstruit au prochain branchement de support ou sollicitation de partition via l'explorateur de fichiers. )

Dans /media c'est légitime que les /media/$USER appartiennent à root, c'est la présence automatisée des ACL qui permet à chaque $USER d'accéder exclusivement et pleinement au contenu de ce dossier.

Ça, par contre, est envisageable seulement si le système de fichiers monté dans <id_volume> est compatible Linux ( ce qui est loin d'être toujours le cas à cet endroit là : clé usb, carte mémoire, DD externe, support optique… )

sudo chown -R $USER[:$USER] /media/$USER/<id_volume>
sudo -R chmod u=rwX[,g=rX[,o=rX]] /media/$USER/<id_volume>

Un système de fichiers non compatible Linux sera par défaut approprié à root:root avec droits buffet-à-volonté rwxrwxrwx
mais du coup, ici, restreint au seul $USER puisque personne d'autre que lui n'accède à l'emplacement parent de <id_volume> → /media/$USER/
( c'est un peu l'intérêt de udisksctl : c'est fait par et pour l'$USER sans trop avoir à se soucier des subtilités des systèmes de fichier ni des points de montage. )

Dernière modification par Coeur Noir (Le 15/09/2022, à 19:49)

erresse · Le 16/09/2022, à 11:47

Cœur Noir a écrit :

Mmm… avec un gros oubli Erresse concernant /media et /media/$USER → les ACL qui sont un cas un peu particulier spécifique à ce dossier à cause de udisks / udisksctl qui se chargent du montage automatique des supports nomades~amovibles ! ( depuis bientôt 10 ans sous ×buntu. )

OK pour préciser ce point concernant les ACL, ça complète utilement l'information.
Cependant, je n'ai pas mentionné qu'il faille modifier les répertoires "/media" ni "/media/$USER", les commandes chown et chmod ne portent que sur le répertoire contenu (le point de montage du volume) qui, lui, doit appartenir à l'utilisateur...
Note: Au passage, j'ai relevé l'erreur de ma commande "sudo -R chmod..." que j'ai corrigée en "sudo chmod -R...". Merci de m'avoir fait relire mon message.

Pardalis · Le 16/09/2022, à 15:30

Merci pour vos retours : il est vrai que j'ai l'habitude de naviguer à vue quand je rencontre un souci (je n'ai aucune formation en la matière). Au moins, là, je comprends ce que j'ai fait, pourquoi ça a marché et comment faire mieux la prochaine fois.

Coeur Noir · Le 16/09/2022, à 16:56

@Erresse mon « but » n'est pas de te prendre en défaut, désolé si ma formulation a pu te faire penser cela, c'est vraiment pas l'intention.
Je cherche en fait à « résumer / formuler » les précautions à prendre dès lors qu'on se sert du dossier /media pour des montages, temporaires ou définitifs, de sources internes ou externes.
Car /media
⋅ est globalement un emplacement de choix opportun pour monter toute sorte de données non vitales au système mais précieuses aux yeux des utilisateurs humains ( des documents et médias provenant de supports divers… )
⋅ tout ce qui est monté dans ce dossier apparaît automatiquement en signets dans le volet latéral de l'explorateur de fichiers ( sous Périphérique ou Autres Emplacements selon l'explorateur de fichiers, norme freedesktop )
⋅ fait partie des quelques dossiers hors $HOME accessibles aux logiciels confinés, type snap pour peu qu'on les ait connectés à l'interface removable-media.

Le dossier /media est un sujet indirectement récurrent sur le forum ( clé usb qui monte pas, où est mon 2ème DD interne, pourquoi je ne peux écrire dans telle partition d'un DD externe… ) et quand on gratte un peu les contextes de ces discussions, on s'aperçoit que le fonctionnement de udisks et udisksctl sont peu connus, avec parfois des conseils qui ne feront qu'empirer la situation, notamment : modifier des droits sur /media ou /media/$USER.

effectivement tes commandes chown -R et chmod -R ne portent que sur le répertoire contenu (le point de montage du volume) donc elles visent juste
MAIS
…ne sont complètement ( le -R ) effectives que si le système de fichiers monté à cet emplacement est compatible avec les droits et permissions à la sauce Linux.
Or à cet endroit là - puisqu'il s'agira souvent de supports nomades~amovibles - on aura affaire à divers FAT ou NTFS, insensibles à ces commandes.

Ça n'est pas gênant, puisque de tels systèmes de fichiers « étrangers à Linux » seront montés en rwxrwxrwx à l'intérieur d'un dossier <id_volume> dans /media/$USER/ ; ici dans le cas particulier udisks / usdisksctl :
⋅ /media/$USER appartient automatiquement à root:root
⋅ MAIS se voit automatiquement attribuer des ACL qui le rendent accessible en écriture + lecture uniquement à l'$USER
⋅ puisque les droits portés par un élément déterminent qui peut faire quoi DANS cet élément, on a alors un système de fichiers aux droits complètement ouverts ( dans <id_volume> ) contenu dans un dossier parent qui lui est restreint à un utilisateur en particulier ( /media/$USER/ qui appartient à root mais avec des ACL )
→ sans manip' particulière seul l'$USER fait ce qu'il veut dans <id_volume>
→ si c'est un système de fichiers compatible droits et permissions Linux qui est monté dans <id_volume> ALORS les droits portés par les éléments dans <id_volume> s'appliquent.

Par ailleurs : « (le point de montage du volume) qui, lui, doit appartenir à l'utilisateur » → beh non, même pas ;-)
Le point de montage n'a pas nécessairement besoin d'appartenir à l'utilisateur, il a juste besoin d'être accessible en lecture à cet $USER, il peut très bien appartenir à quelqu'un d'autre, tant qu'il accorde un droit de lecture rwxr-xr-x aux autres. Ce qui importe, c'est les droits portés par les éléments DANS le volume : c'est les droits portés par un élément qui déterminent qui peut faire quoi DANS cet élément.
On peut cependant trouver pratique d'attribuer tout un volume à un utilisateur en particulier ( dans ce cas on agit sur les droits du point de montage ) mais ça signifie potentiellement de restreindre l'usage de tout ce volume à un seul utilisateur ( pas opportun dans un contexte multi-utilisateurs. )

Breeeeeeeef. Comment résumer ?

Dans /media
⋅ on ne créé pas manuellement de dossier au nom d'un utilisateur potentiel, on laisse ça à l'automatisme udisks / udiskctl ( qui gérera les droits sur ce qu'il crée ) ;
⋅ si les dossiers $USER ont déjà été crées par l'automatisme, on ne se sert pas de ces dossiers manuellement pour y ajouter des montages (*), on laisse ça à l'automatisme udisks / udiskctl ( qui fera le ménage nécessaire dans le dossier $USER en fonction des montages~démontages qu'il y gère ) ;
⋅ autrement dit, ce qui est contenu sous les divers /media/$USER/ n'est pas stable, permanent, c'est mis à jour dynamiquement en fonction des branchements / sollicitations de partitions.
⋅ Par contre on peut créer manuellement autant de point de montages qu'on veut, directement sous /media, genre /media/DiSK_02 ou /media/'Bibliothèque Musicale' ou /media/USERS-DATA ou /media/NAS etc…
⋅ points de montage sur lesquels on règle les droits en fonction des besoins ( contexte multi-utilisateurs ou pas, partage ou pas, etc )
→ la seule contrainte : toujours veiller à ce que les noms de ces points de montage dans /media ne puissent jamais être confondus avec des noms d'$USER potentiels.
→ l'astuce ? Utiliser des majuscules dans ces noms de points de montage ( les noms d'$USER eux sont automatiquement en minuscules ).

(*) On pourrait… mais je préfère l'extrême prudence : comme ces dossiers n'existent pas par défaut dans /media ( ils ne sont créés par udisks / udiskctl que lors du branchement d'un support nomade~amovible, ou à la sollicitation d'une partition « interne » via l'explorateur de fichiers ) c'est prendre le risque de créer manuellement ces dossiers avec des droits inadéquats.
Ou prendre le risque de cibler un point de montage qui aura disparu au démarrage suivant ( puisque le ménage est fait par udisks / udisksctl dans les divers /media/$USER en fonction de ce qui y aura été monté~démonté pendant la session d'un $USER ).
→ ce qui est monté par udisks / udisksctl pour un $USER est démonté lorsque l'$USER quitte sa session.

Dernière modification par Coeur Noir (Le 16/09/2022, à 19:16)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/09/2022, à 15:45

[Résolu] Souci de permissions rwx lors de màj (partition ext4)

#2 Le 15/09/2022, à 17:13

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

#3 Le 15/09/2022, à 18:18

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

#4 Le 15/09/2022, à 18:56

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

#5 Le 16/09/2022, à 11:47

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

#6 Le 16/09/2022, à 15:30

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

#7 Le 16/09/2022, à 16:56

Re : [Résolu] Souci de permissions rwx lors de màj (partition ext4)

Pied de page des forums