[RESOLU] Fedora : impossible d'accéder au coffre-fort numérique

[Glenic1]

Bonjour,

Un des points forts de la distribution Fedora est la fourniture directe (comprise dans l'installation de la distribution) d'un coffre-fort numérique pour y caser ses données personnelles.
Techniquement, ce coffre-fort est une partition chiffrée de type "cryptFS" que l'on monte à la demande en introduisant le code de déverrouillage. Par habitude, j'ai baptisé LUKS cette partition.

Jusqu'à présent, tout fonctionnait bien sur mon HP Probook avec Fedora 42.
Mais aujourd'hui, patatras, voici ce que me dit l'ordi à la tentative d'ouverture (de montage) du coffre-fort, une fois que j'ai tapé le code dans la fenêtre adéquate.

2025-06-30_impossible d'ouvrir LUKS.png (66.63 Kio) Vu 48962 fois

Quand on clique sur "OK", le 2ème message arrive de suite.

2025-06-30_impossible de déverrouiller LUKS.png (40.92 Kio) Vu 48963 fois

"dossier de point de montage non vide" = la partition chiffrée serait déjà montée ??????? sans avoir eu besoin de taper le code ????
A l'examen de l'explorateur, effectivement la partition LUKS est accessible mais seulement pour un fichier : un petit tableur Calc laissé ouvert un certain temps, au moins le temps que l'ordi se mette en veille.

1er réflexe : fermer ce tableur en espérant que les choses s'arrangent => hélas échec

2ème reflexe : redémarrer l'ordi, en espérant là aussi que les "compteurs seront remis à zéro" => nouvel échec

3ème reflexe : via l'explorateur (Thunar), essayer d'accéder à une commande (graphique) de démontage de la partition LUKS puisqu'elle est visible (très partiellement) comme indiqué ci-dessus. Une fois cette partition démontée, on "repartirait à zéro". Hélas aucune commande "démontage" visible ! ! ça devrait se régler en lignes de commande mais il ne faut pas se tromper. Il ne s'agit pas d'effacer la partition.

Une recherche sur Internet n'a rien donné : le forum Fedora est parfaitement incompréhensible pour un débutant comme moi et de plus, je n'ai pas trouvé trace de ce défaut spécifique. On y cause par contre de problèmes où le point de montage n'existe pas,ce qui n'est pas le cas ici.

Pas de trace du code d'erreur 12 non plus.

Il y a bien des généralités sur les points de montage du coté d'Ubuntu mais là on sort du cadre Fedora....

[maxoxo]

Héhé problème résolu ! Heureusement que RustDesk existe ! (Pour ceux qui ne le connaissent pas, excellente alternative libre au logiciel propriétaire Teamviewer qui est le roi des logiciels d'assistance à distance).
https://rustdesk.com/fr/

Pour donner l'explication, Glenic avait accidentellement enregistré des fichiers sur le point de montage du conteneur chiffré alors que celui-ci n'était justement pas monté. De ce fait, le système (et plus précisément la commande mount qui est appelée par l'interface graphique) refusait donc fort logiquement de monter le conteneur chiffré (appelé ici "coffre") car elle nécessite que le dossier qui sert de point de montage soit vide.

En ligne de commande on aurait pu éventuellement contourner avec un mount --force mais aucun intérêt, c'est plutôt sain de ne pas écrire des données dans un répertoire destiné à servir de point de montage pour un disque, un lecteur réseau ou autre

[Glenic1]

......et on a donc supprimé le fichier parasite (dont la version originale figure toujours dans le coffre-fort).
Tout est rentré dans l'ordre.
A noter que ce n'est pas un problème spécifiquement "Fedora"
Le même bug serait survenu avec une autre distribution comportant une partition chiffrée, en cas d'écriture accidentelle sur le dossier du point de montage de la-dite partition.

Un grand merci à maxoxo !

[Stéphane Ascoët]

Pour donner l'explication, Glenic avait accidentellement enregistré des fichiers sur le point de montage du conteneur chiffré alors que celui-ci n'était justement pas monté. De ce fait, le système (et plus précisément la commande mount qui est appelée par l'interface graphique) refusait donc fort logiquement de monter le conteneur chiffré (appelé ici "coffre") car elle nécessite que le dossier qui sert de point de montage soit vide.

Il va falloir créer une catégorie de forum "Fedora" Cette mésaventure m'arrive hélas, mais seulement en super-utilisateur Ça veut dire que Glenic a créé un fichier bureautique en étant root  Pour identifier le problème, je mets dans les points de montage un fichier vide "siceciestvisiblec-estquelemontagen-estpasfait" mais là ça ne fonctionnerait pas vu qu'il exige que ce soit vide

[maxoxo]

Il va falloir créer une catégorie de forum "Fedora" Cette mésaventure m'arrive hélas, mais seulement en super-utilisateur Ça veut dire que Glenic a créé un fichier bureautique en étant root  Pour identifier le problème, je mets dans les points de montage un fichier vide "siceciestvisiblec-estquelemontagen-estpasfait" mais là ça ne fonctionnerait pas vu qu'il exige que ce soit vide

Bof, là ça portait plus sur Plasma-Vault que est un composant de KDE qui sur Fedora en soi. Sur toutes les versions 6 de Plasma on a accès à cet outil de chiffrement très pratique.

Et non non, Glenic n'a pas exécuté LibreOffice en root, ni même utilisé la commande mount

Plasma-Vault est interface conviviale pour gocryptfs/ et ce dernier repose sur un système de fichiers FUSE donc on peut le monter dans l'espace utilisateur sans avoir besoin de privilèges ou même de sudo

[Stéphane Ascoët]

Bof, là ça portait plus sur Plasma-Vault que est un composant de KDE qui sur Fedora en soi. Sur toutes les versions 6 de Plasma on a accès à cet outil de chiffrement très pratique.

Quand même

Et non non, Glenic n'a pas exécuté LibreOffice en root, ni même utilisé la commande mount

Plasma-Vault est interface conviviale pour gocryptfs/ et ce dernier repose sur un système de fichiers FUSE donc on peut le monter dans l'espace utilisateur sans avoir besoin de privilèges ou même de sudo

Ça j'avais compris, je parlais du fait d'avoir mis un fichier dans le dossier de montage quand il n'est pas monté

[maxoxo]

Ça j'avais compris, je parlais du fait d'avoir mis un fichier dans le dossier de montage quand il n'est pas monté

Oui mais pourquoi ça nécessiterait d'être root alors que le point de montage est dans son /home ?
Le vrai point problématique pour moi, c'est plutôt que le coffre chiffré puisse être lock alors que des processus comme LibreOffice l'utilisent encore...Imaginons que le coffre se verrouille avec la session, ça veut dire que le fichier ouvert dans LibreOffice est encore affiché alors que le contenu du coffre est censé être chiffré et inaccessible

[Stéphane Ascoët]

Ça j'avais compris, je parlais du fait d'avoir mis un fichier dans le dossier de montage quand il n'est pas monté

Oui mais pourquoi ça nécessiterait d'être root alors que le point de montage est dans son /home ?

Ça m'avait échappé, pour moi un montage se fait forcément dans /mnt ou /media

[maxoxo]

Ça m'avait échappé, pour moi un montage se fait forcément dans /mnt ou /media

Voilà pourquoi on ne se comprenait pas

Les outils modernes de chiffrement et "user friendly" comme Cryptomator ou Plasma-Vaults font du fusermount et donc montage dans l'espace utilisateur via FUSE et du coup plutôt dans du /run ou du /home de façon à être accessible sans privilèges root. Cela dit, ça ne permet pas de monter des disques (à l'exception des disques USB gérés par udisks en user aussi).