<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Bonjour Joyce,<br>
<br>
Il me semble avoir répondu à certaines de tes questions dans ma
réponse à Sylvain.<br>
<br>
Les 6 premières lignes concernent la première capture d'écran :
"impossible d'accéder ..."<br>
<br>
Le résultat du lsbk liste les 2 HDD :<br>
<pre class="moz-quote-pre" wrap=""> lsblk -o KNAME,TYPE,SIZE
KNAME TYPE SIZE
<font color="#00ff00">sda disk 1,8T
sda1 part 1,8T
dm-0 crypt 1,8T</font>
<font color="#0000ff">sdb disk 1,8T
sdb1 part 1,8T
dm-1 crypt 1,8T</font>
mmcblk0 disk 7,4G
mmcblk0p1 part 113,3M
mmcblk0p2 part 1K
mmcblk0p3 part 32M
mmcblk0p5 part 60M
mmcblk0p6 part 7,2G
</pre>
<div class="moz-signature">
<div class="moz-signature">
<pre class="moz-signature" cols="72">Nico
</pre>
</div>
</div>
<div class="moz-cite-prefix">Le 30/05/2022 à 12:22, Joyce MARKOLL
via Toulouse-ll a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20220530122244.936e1edd07e8ad9bccb9daf2@netc.eu">
<pre class="moz-quote-pre" wrap="">Bonjour,
On Mon, 30 May 2022 09:56:47 +0200
Sylvain via Toulouse-ll <a class="moz-txt-link-rfc2396E" href="mailto:toulouse-ll@toulibre.org"><toulouse-ll@toulibre.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Tu peux essayer fsck.ntfs et ntfsfix (à installer peut-être).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
sur des partitions contenant un system Ext* ? "Faiscommechezmoi" a dit:
"Sous une vielle Debian 9 (stretch) qui me sers de NAS"
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Je trouve un peu risqué d'avoir fait une partition NTFS sur un NAS
Debian.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Il y une partitions NTFS ? Il a juste parlé de partage Samba et d'accès depuis Windows
non ?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Le 2022-05-29 12:37, toulibre.org--- via Toulouse-ll a écrit :
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Sous une vielle Debian 9 (stretch) qui me sers de NAS, je dispose de 2
HDD identiques branchés en USB.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Ces HDD sont chiffrés en LUKS. Une seule partition par HDD.
Je n'utilise pas de LVM.
lsblk -o KNAME,TYPE,SIZE
KNAME TYPE SIZE
sda disk 1,8T
sda1 part 1,8T
dm-0 crypt 1,8T
sdb disk 1,8T
sdb1 part 1,8T
mmcblk0 disk 7,4G
mmcblk0p1 part 113,3M
mmcblk0p2 part 1K
mmcblk0p3 part 32M
mmcblk0p5 part 60M
mmcblk0p6 part 7,2G
Une arborescence du HDD1 (sda) est partagée sur mon LAN avec Samba.
le HDD1 est rsync régulièrement vers le HDD2 (sdb).
Sur le HDD1, j'ai provoqué une corruption en bougeant les câbles
trop brusquement.
Le résultat donne ceci :
Les 6 premières lignes n'étaient pas d'origine. Elles apparaissent
car j'ai d'abord tenté de supprimer le répertoire, sans succès...
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
quelles 6 premières lignes ?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Pas de soucis sur le répertoire équivalent sur le HDD2.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
À quoi ressemble le retour de lsblk sur celui-là par comparaison ?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Après avoir rebooté (les HDD1&2 ne sont pas déchiffrés ni montés
lors du boot), j'ai tenté de réparer comme suit :
1- déchiffrage du HDD1
cryptsetup luksOpen /dev/sda1 c1
Saisissez la phrase secrète pour /dev/sda1 :
=> ok
2- déchiffrage du HDD2
cryptsetup luksOpen /dev/sdb1 c2
Saisissez la phrase secrète pour /dev/sdb1 :
=> ok
3- Vérification avec un fdisk :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap=""> 4- tentative de montage du volume NTFS :
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Ah oui, un volume NTFS : je croyais que c'était une Debian Stretch ?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> Mais si j'utilise le script d'outillage que je m'étais fait pour
automatiser les arrets/démarrages de la "fonction" NAS de ce serveur;
cela fonctionne bien; alors que la commande contenue dans le script
est rigoureusement la même ...
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Cette partie ↑ est obscure.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> Bref, une fois le volume monté et Samba démarré, je navigue
bien dans le partage samba, depuis un poste en windows.
En revanche, j'ai des soucis d'écriture ..
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Dans ce cas je ne vois qu'une chose à faire tant que c'est possible : faire une
sauvegarde générale vers un support de stockage sain.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 5- Je stoppe Samba et démonte les volumes et ferme les volumes
LUKS :
/etc/init.d/samba stop
umount /media/USBHDD1/shares
umount /media/USBHDD2/shares
cryptsetup luksClose c1
cryptsetup luksClose c2
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 6- Je tente un fsck sur .. justement ... je ne sais plus trop car
mes souvenirs sur la gestion des devices et la terminologie associée,
sont assez diffus :
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
aïe. :)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> J'essaye sur le périphérique :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""># fsck /dev/sdb
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Non. man fsck dit:
"fsck - check and repair a Linux filesystem"
fsck vérifie et répare des systèmes de fichiers Linux.
Donc si sdb contient des partitions ext2/3 ou ext4 ça marchera, à condition d'invoquer
fsck sur des volumes et non sur le disque.
Si c'est du ntfs, il existe le paquet ntfs-3g qui fournit ntfsfix, lequel peut aider à
réparer des fs ntfs.
(Essaie "ntfs<tab>"
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de
sauvetage...
fsck.ext2: Numéro magique invalide dans le super-bloc lors de la
tentative d'ouverture de /dev/sdb
Le superbloc n'a pu être lu ou ne contient pas un système de
fichiers
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
sdb représente le disque complet. (Tu peux regarder le retour de "sudo fdisk -l /dev/sdb")
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">ext2 correct. Si le périphérique est valide et qu'il contient
réellement
un système de fichiers ext2 (et non pas de type swap, ufs ou
autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap=""> Ce qui ne me surprends qu'à moitié puisque le périphérique
est chiffré.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Non. On invoque fsck sur un système de fichiers. (insister sur "système de
fichiers"). sdb contient des volumes, des partitions, pas un système de fichiers.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> Si je déchiffre le périphérique et essaye la partition:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">fsck /dev/sda1
fsck from util-linux 2.20.1
fsck: fsck.crypto_LUKS: not found
fsck: error 2 while executing fsck.crypto_LUKS for /dev/sda1
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Auriez vous une idée ?
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
en regardant sur le web ce que ça dit à propos d'erreurs fsck.crypto_LUKS il y a pas mal
de messages. Par exemple:
<a class="moz-txt-link-freetext" href="https://unix.stackexchange.com/questions/646569/superblock-problem-on-a-crypto-luks-drive">https://unix.stackexchange.com/questions/646569/superblock-problem-on-a-crypto-luks-drive</a>
“The filesystem on your root logical volume is corrupted, not the LUKS device
itself. /dev/sda5 is partition that holds the LUKS/dm-crypt device, with encryption (and
also LVM which you are also using), the storage works in layers, you can't run fsck on
the LUKS (encryption) layer, you must run it on the LVM logical volume layer
-- /dev/mapper/trisquel--vg-root in your case.”
Cela rejoint ce que te dit Sylvain:
"As-tu essayé fsck sur la partition /dev/mapper/c1 ? (décryptée et non
montée)"
Par contre mon "apt-file update && apt-file search" ne trouve pas "fsck.ntfs".
En conclusion, je commencerais par une sauvegarde complète (ou pas, si le disque miroir
ne rencontre pas de problème), et à déterminer quel type de systèmes de fichiers se
trouve(nt) sur les volumes /dev/mapper avant de choisir un outil à invoquer dessus.
Joyce
</pre>
</blockquote>
<br>
</body>
</html>