J’ai un disque dur externe dont je me sert pour sauvegarder mes données.
Il est formaté ntfs cryptés sous bitlocker.
Ensuite je l’ouvre et je lance Rsync pour sauvegarder mes données.
Sous windows et Cygwin sans probleme.
Sous OpenSuse sans problème
Sous Debian Trixie depuis quelques semaines je ne peux plus le monter:
Message reçu : L'opération demandée a échoué: Error mounting /dev/dm-5 at /media/ba/BA_PRO_TRAVAIL: wrong fs type, bad option, bad superblock on /dev/mapper/bitlk-e1300d37-90eb-49d3-9231-d8476643f92f, missing codepage or helper program, or other error
Comment expliquer cette différence?
Sachant que sous Trixie rsync se lance en automatique, j’ai une tache anacron qui vérifie la présence du disque ouvert et lance Rsync
Merci pour votre aide
EDIT: amusant, je viens de m’apercevoir que le script qui est lancé par la tache anaccron est vide, j’ai du mal le sauvegarder. Donc ce n’est pas lui qui bloque
@Anonymous23 , il faudrait qu’à chaque commande tu nous donne le détail complet, et aussi au même moment ce qu’il y a dans dmesg (la fin) ainsi que dans les logs (/var/log/syslog si tu as, sinon journalctl -n 50)
Habituellement je branchais le disque, avais un promt KDE qui proposais de monter et ouvrir, puis demandais le mot de passe. Ensuite avec Dolphin j’ouvrais le disque. Maintenant en haut de la fenêtre j’ai
"Une erreur est survenue en accédant à « B_PRO_TRAVAIL ». Message reçu : L'opération demandée a échoué: Error mounting /dev/dm-5 at /media/ba/B_PRO_TRAVAIL: wrong fs type, bad option, bad superblock on /dev/mapper/bitlk-e1300d37-90eb-49d3-9231-d8476643f92f, missing codepage or helper program, or other error"
si je tape:
dpkg -l | grep ntfs
ii libntfs-3g89t64:amd64 1:2022.10.3-5 amd64 read/write NTFS driver for FUSE (runtime library)
ii ntfs-3g 1:2022.10.3-5 amd64 read/write NTFS driver for FUSE
Comme le disque marche sur deux autres ordinateurs et qu’il contient des données précieuses, je pense que je vais éviter d’essayer de le réparer.
Je vais commencer par faire une copie de la copie…
Si je veux un système de sauvegarde multi-os, crypté, ou je peux toujours accéder aux fichiers sauvegardés en direct en branchant le disque tu me conseille quoi?
Tu vas avoir un problème. Microsoft n’est pas le plus haut niveau d’interopérabilité qui soit.
Le mieux c’est de faire un epartition LUKS sur ton disque.
Tu pourras utiliser les outils habituel de linux pour le déchiffrer, et pour Windows tu devrais pouvoir utiliser LibreCrypt.
Et sur cette partition LUKS tu crées une partition FAT. Et ça sera compatible pour les deux OS, M$ et Linux.
Je plussoie le conseil de @Zargos est logique, l’utilisation de LUKS est la plus interopérable. ntfs très bien supporté sur Linux, par contre je suis franchement froid pour utiliser du Bitlocker.
Il y a encore d’autres façons d’envisager la chose pour les backups, dans mon cas j’ai un disque externe chiffré en LUKS que je branche temporairement pour faire des backups en restic en utilisant un serveur temporaire S3. Mais je n’ai pas encore terminé mon cheminement pour la ma solution de backup finale et je n’ai pas de Windows dans la boucle.
Je confirme que cette erreur n’apparait que sous mon poste Debian et pas sous Windows ni sous OpenSuse que je teste en ce moment.
Sous Debian je fais :
sudo e2fsck -fn /dev/sdb
e2fsck 1.47.2 (1-Jan-2025)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Found a gpt partition table in /dev/sdb
Il faut que tu refasse ce disque.
Sur l’OS où tu peux accéder, tu récupère les données.
Ensuite tu refais complètement le disque.
Ça te prendra moins de temps que d’essayer de dépanner.
fsck marche sur les partitions, donc sdb1 pas sdb ( sauf peut être avec dislocker)
pour dislocker, tu dis que tu crées un fichier, pas un dossier, est-ce normal pour dislocker?
L’utilisation du chiffrement va créer un périphérique /dev/dmX où X est un chiffre dépendant du nombre de systèmes montés de cette façon, par dislocker ou par luks par exemple.
dans ton cas sur les logs fournis il y a trois jours dm-5.
tu le verras dans le dmseg
Les partitions de ton disque physique sont du style /dev/sdb2
/dev/sdb2 une fois déchiffrée par la couche dislocker, elle apparait sous /dev/dm-5 ( par exemple ).
ce qui est exposé est une vue par secteur du disque, donc un système de fichier est monté par dessus, ici ntfs.
Donc la vérification ntfs avec e2fsck doit être faite sur le /dev/dm-5 par exemple et surtout pas sur /dev/sdb2, sinon tu va écraser le contenu de ton disque et vraiment tout perdre. Le fait qu’il ne soit plus lisible sous windows n’est vraiment pas un bon signe.
Le mieux est de lire le disque depuis un système qui y arrive, si tu vois le contenu avec opensuse alors c’est sur l’opensuse qu’il faut regarder s’il y a eu des erreurs.
Selon les systèmes une vérification et récupération automatique est entreprise au montage du système fichier.