Utilisateur mac historique, je suis en recherche de solutions de
migration, point par point, pour les aspects et fonctions qui me sont
importants et je bloque sur le chiffrage à la volée de gros volumes
que permet, sous MacOS, FileVault 2.
L'essai que je viens de faire de Veracrypt ne soutient absolument pas
la comparaison, en particulier pour la mise en œuvre. Du moins
jusqu'à plus ample informé, raison de ce post.
S'agissant du chiffrage d'un volume de 3 To, ai-je raison de
constater que cela prend une trentaine d'heures ? Et pas en
arrière-plan ni avec possibilité d'interruption puis de reprise en
cours que permet Filevault ?
Je ne cherche pas à valoriser quoi que ce soit par rapport à quoi que
ce soit. Juste à trouver des solutions viables et inter-plateformes,
de préférence en open-source (sans obligation).
Peut-être suis-je parti sur une mauvaise piste ? Y a-t-il d'autres
solutions concurrentes ? On est d'accord que pour des dossiers
chiffrés de volume plus faible, VC fonctionne bien (même si on n'a
pas la fluidité d'une solution intégrée au système). J'ai ainsi créé
un dossier de 10 Go sur une clé USB en 6 minutes. Mais évidemment la
règle de trois est ensuite implacable... pour 100 Go -> 60 minutes etc.
OK, bien noté. DONC ? Quel format suggères-tu, inter-opérable en lecture/écriture, et qui supporte des tailles de fichiers supérieures à 4 Go ?
Si ça doit être accessible par Windows, il n'y a que NTFS.
Ou UDF, si MacOS sait gérer.
Pascal Hambourg
Le 27/09/2020 à 19:38, Gerald a écrit :
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Je *souhaiterais* juste trouver une solution équivalente à Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte" en lecture que si fourniture du mot de passe.
J'ai bien compris, bien que ne connaissant pas les fonctionnalités de Filevault 2. Par contre tu n'as pas compris ma question. Je reformule.
Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Le 27/09/2020 à 19:38, Gerald a écrit :
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Je *souhaiterais* juste trouver une solution équivalente à
Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte"
en lecture que si fourniture du mot de passe.
J'ai bien compris, bien que ne connaissant pas les fonctionnalités de
Filevault 2. Par contre tu n'as pas compris ma question. Je reformule.
Tout son contenu est
chiffré et déchiffré "à la volée" au fur et à mesure des demandes de
visualisation ou utilisation du User. Les données copiées dans un
sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine
d'heures" dans ton message initial, de quelle opération parlais-tu
exactement ?
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Je *souhaiterais* juste trouver une solution équivalente à Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte" en lecture que si fourniture du mot de passe.
J'ai bien compris, bien que ne connaissant pas les fonctionnalités de Filevault 2. Par contre tu n'as pas compris ma question. Je reformule.
Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Pascal Hambourg
Le 27/09/2020 à 23:31, pehache a écrit :
Le 27/09/2020 à 20:39, denis.paris a écrit :
NTFS est parfaitement géré par linux
Non, pas parfaitement. Voir plus bas.
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
Le 27/09/2020 à 23:31, pehache a écrit :
Le 27/09/2020 à 20:39, denis.paris a écrit :
NTFS est parfaitement géré par linux
Non, pas parfaitement. Voir plus bas.
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à
moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi
que l'écriture de façon très limitée (modification du contenu d'un
fichier existant sans changer sa taille) depuis longtemps. Mais Debian a
désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé
complètement le pilote dans le noyau 4.19 de Buster/10.
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
pehache
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Tout son contenu est
chiffré et déchiffré "à la volée" au fur et à mesure des demandes de
visualisation ou utilisation du User. Les données copiées dans un
sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine
d'heures" dans ton message initial, de quelle opération parlais-tu
exactement ?
Il parle de la création du volume VeraCrypt
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes." (ST sur fr.bio.medecine)
"Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici."
(FLC sur fr.comp.sys.atari)
Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Pascal Hambourg
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une
trentaine d'heures" dans ton message initial, de quelle opération
parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ?
Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à
écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les
calculs liés à la protection de la clé maîtresse et c'est indépendant de
la taille du volume.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
pehache
Le 28/09/2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ?
Remplissage de tout l'espace libre par des valeurs aléatoires.
Le 28/09/2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une
trentaine d'heures" dans ton message initial, de quelle opération
parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ?
Remplissage de tout l'espace libre par des valeurs aléatoires.
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
En quoi cela consiste-t-il pour prendre autant de temps ?
Remplissage de tout l'espace libre par des valeurs aléatoires.
Gerald
Le 28 septembre 2020 à 08:37, pehache a écrit :
Euh, pourquoi commander un nouveau HDD ?
euh... bon de toutes façons je vais en avoir besoin (j'arrive en limite de capacité pour certaines archives, et il faut que j'allège mes disques de travail). Et ensuite ça permettra d'exclure un problème qui serait lié au hardware.
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de chiffrer directement le disque ? Non seulement ça permettrait d'utiliser l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT (potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la partition chiffrée, le message est explicite) de préférer cette option si on est un utilisateur novice. Ils disent que le chiffrage du volume entier est possible mais pourrait le rendre définitivement inaccessible en cas de fausse manip. 2/ une mauvaise expérience, justement, avec une clé USB 64 que j'ai tenté de formater ainsi. Elle est effectivement devenue "invisible" à toute récupération ou reformatage. Jusqu'à ce qu'elle finisse par réapparaître le lendemain (dans Utilitaire de disque) mystérieusement. Autant la perte d'une clé serait bénigne, autant celle d'un gros DD serait quand même plus embêtante. Et surtout : s'ils avertissent, c'est qu'il doit y avoir une raison ! Et je ne suis, effectivement qu'un novice (en gros). Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre Astier avec son sketch sur la physique quantique). - déjà l'interopérabilité des formats de disques est loin d'être "velours" - de même que l'interopérabilité logicielle, qui semble se résumer, dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas à mes besoins (on s'éloigne très largement de la transparence dont j'ai l'habitude) - pour finir par le constat que cette pratique, qui me semblait naturelle, raisonnable et évidente, ne le serait pas tant que ça et en particulier pas pour vous (présents sur ce forum). Il semble que quand elle est mise en œuvre (en entreprise), ce n'est que dans le contexte d'un système, d'un parc homogène, sans interopérabilité. Reste à savoir comment ceux qui se passent de chiffrage (dont vous) assurent la sécurité de leurs archives... Peut-être "physiquement" ? C'est un peu comme la question plus globale desdites sauvegardes et archives d'ailleurs : beaucoup ne s'en préoccupent pas autant que moi : redondantes sur site et hors-site. Occasion de réfléchir et de prendre de la distance ? -- Gerald
Le 28 septembre 2020 à 08:37, pehache a écrit :
Euh, pourquoi commander un nouveau HDD ?
euh... bon de toutes façons je vais en avoir besoin (j'arrive en
limite de capacité pour certaines archives, et il faut que j'allège
mes disques de travail). Et ensuite ça permettra d'exclure un
problème qui serait lié au hardware.
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de
chiffrer directement le disque ? Non seulement ça permettrait d'utiliser
l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT
(potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la
partition chiffrée, le message est explicite) de préférer cette
option si on est un utilisateur novice. Ils disent que le chiffrage
du volume entier est possible mais pourrait le rendre définitivement
inaccessible en cas de fausse manip. 2/ une mauvaise expérience,
justement, avec une clé USB 64 que j'ai tenté de formater ainsi. Elle
est effectivement devenue "invisible" à toute récupération ou
reformatage. Jusqu'à ce qu'elle finisse par réapparaître le lendemain
(dans Utilitaire de disque) mystérieusement. Autant la perte d'une
clé serait bénigne, autant celle d'un gros DD serait quand même plus
embêtante.
Et surtout : s'ils avertissent, c'est qu'il doit y avoir une raison !
Et je ne suis, effectivement qu'un novice (en gros).
Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre
Astier avec son sketch sur la physique quantique).
- déjà l'interopérabilité des formats de disques est loin d'être
"velours"
- de même que l'interopérabilité logicielle, qui semble se résumer,
dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas
à mes besoins (on s'éloigne très largement de la transparence dont
j'ai l'habitude)
- pour finir par le constat que cette pratique, qui me semblait
naturelle, raisonnable et évidente, ne le serait pas tant que ça et
en particulier pas pour vous (présents sur ce forum). Il semble que
quand elle est mise en œuvre (en entreprise), ce n'est que dans le
contexte d'un système, d'un parc homogène, sans interopérabilité.
Reste à savoir comment ceux qui se passent de chiffrage (dont vous)
assurent la sécurité de leurs archives... Peut-être "physiquement" ?
C'est un peu comme la question plus globale desdites sauvegardes et
archives d'ailleurs : beaucoup ne s'en préoccupent pas autant que moi
: redondantes sur site et hors-site.
Occasion de réfléchir et de prendre de la distance ?
euh... bon de toutes façons je vais en avoir besoin (j'arrive en limite de capacité pour certaines archives, et il faut que j'allège mes disques de travail). Et ensuite ça permettra d'exclure un problème qui serait lié au hardware.
Par ailleurs, pourquoi crées-tu une image chiffrée plutôt que de chiffrer directement le disque ? Non seulement ça permettrait d'utiliser l'option "Quick format", mais tu éviterais l'empilement de 2 accès exFAT (potentiellement pénalisants sous Linux suivant les cas).
Là, c'est consécutif à 1/ d'une part *leur conseil* (quand on crée la partition chiffrée, le message est explicite) de préférer cette option si on est un utilisateur novice. Ils disent que le chiffrage du volume entier est possible mais pourrait le rendre définitivement inaccessible en cas de fausse manip. 2/ une mauvaise expérience, justement, avec une clé USB 64 que j'ai tenté de formater ainsi. Elle est effectivement devenue "invisible" à toute récupération ou reformatage. Jusqu'à ce qu'elle finisse par réapparaître le lendemain (dans Utilitaire de disque) mystérieusement. Autant la perte d'une clé serait bénigne, autant celle d'un gros DD serait quand même plus embêtante. Et surtout : s'ils avertissent, c'est qu'il doit y avoir une raison ! Et je ne suis, effectivement qu'un novice (en gros). Donc pour l'instant : "UN BILAN MITIGÉ" :-) (je pique à Alexandre Astier avec son sketch sur la physique quantique). - déjà l'interopérabilité des formats de disques est loin d'être "velours" - de même que l'interopérabilité logicielle, qui semble se résumer, dans ce domaine, à un seul, (Veracrypt), qui, en gros, ne répond pas à mes besoins (on s'éloigne très largement de la transparence dont j'ai l'habitude) - pour finir par le constat que cette pratique, qui me semblait naturelle, raisonnable et évidente, ne le serait pas tant que ça et en particulier pas pour vous (présents sur ce forum). Il semble que quand elle est mise en œuvre (en entreprise), ce n'est que dans le contexte d'un système, d'un parc homogène, sans interopérabilité. Reste à savoir comment ceux qui se passent de chiffrage (dont vous) assurent la sécurité de leurs archives... Peut-être "physiquement" ? C'est un peu comme la question plus globale desdites sauvegardes et archives d'ailleurs : beaucoup ne s'en préoccupent pas autant que moi : redondantes sur site et hors-site. Occasion de réfléchir et de prendre de la distance ? -- Gerald
Gerald
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go... Il reste à attendre la livraison d'un nouveau disque de grande capacité pour mettre le disque lui-même hors de cause, mais je ne suis pas très optimiste. Ça ne semble pas prévu pour gérer des volumes de grande capacité. À suivre. (et merci encore de votre intérêt). -- Gerald
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une
trentaine d'heures" dans ton message initial, de quelle opération
parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ?
Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à
écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les
calculs liés à la protection de la clé maîtresse et c'est indépendant de
la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est
pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata
temporis (apparemment).
Info additionnelle : après reformatage du disque (toujours en ExFAT,
vérification par les outils systèmes, reprise du chiffrement à partir
d'un autre ordi, et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Il reste à attendre la livraison d'un nouveau disque de grande
capacité pour mettre le disque lui-même hors de cause, mais je ne
suis pas très optimiste. Ça ne semble pas prévu pour gérer des
volumes de grande capacité.
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go... Il reste à attendre la livraison d'un nouveau disque de grande capacité pour mettre le disque lui-même hors de cause, mais je ne suis pas très optimiste. Ça ne semble pas prévu pour gérer des volumes de grande capacité. À suivre. (et merci encore de votre intérêt). -- Gerald
denis.paris
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le 27/09/2020 à 23:31, pehache a écrit :
Le 27/09/2020 à 20:39, denis.paris a écrit :
NTFS est parfaitement géré par linux
Non, pas parfaitement. Voir plus bas.
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) et je garde un Windows 10 natif pour la première partition, au début pour un problème de garantie machine puis finalement je l'ai laissé pour les (très) rares programmes dont j'ai besoin et qui ne tournent que sous Windows (exemple: la gestion d'une infrastructure ESX Vmware). Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture. Mais bon, puisqu'il y a un consensus pour extFAT, allons-y ! ;)
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le 27/09/2020 à 23:31, pehache a écrit :
Le 27/09/2020 à 20:39, denis.paris a écrit :
NTFS est parfaitement géré par linux
Non, pas parfaitement. Voir plus bas.
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à
moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi
que l'écriture de façon très limitée (modification du contenu d'un
fichier existant sans changer sa taille) depuis longtemps. Mais Debian a
désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé
complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) et je garde un
Windows 10 natif pour la première partition, au début pour un problème
de garantie machine puis finalement je l'ai laissé pour les (très) rares
programmes dont j'ai besoin et qui ne tournent que sous Windows
(exemple: la gestion d'une infrastructure ESX Vmware).
Et je n'ai strictement rien rajouté comme package pour accéder à la
partition NTFS, qui est accessible parfaitement en écriture.
Mais bon, puisqu'il y a un consensus pour extFAT, allons-y ! ;)
A contrario, NTFS n'est pas pris en charge nativement sous Linux (à moins que ça ait changé ?)
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) et je garde un Windows 10 natif pour la première partition, au début pour un problème de garantie machine puis finalement je l'ai laissé pour les (très) rares programmes dont j'ai besoin et qui ne tournent que sous Windows (exemple: la gestion d'une infrastructure ESX Vmware). Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture. Mais bon, puisqu'il y a un consensus pour extFAT, allons-y ! ;)
denis.paris
Le 28/09/2020 à 08:16, Gerald a écrit :
Le 27 septembre 2020 à 20:40, pehache a écrit :
Il y a clairement un problème, mais difficile à identifier. Refais déjà le test sur un disque interne de ton Mac au lieu d'une clé USB.
Je vais plutôt partir sur un essai réel de reformatage du disque 3 To de destination, suivi de reprise du protocole, mais à partir d'un autre ordi (Macbook) pour ne pas bloquer mon ordi de bourreau, et parallèlement commande d'un DD neuf pour éliminer l'hypothèse d'un problème hardware.
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela simplifiera les sauvegardes par duplication disque à disque, d'une manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Compte-tenu des temps prévisibles (du chiffrement, puis de la sauvegarde des données, et de livraison du nouveau disque), je ne reviendrai pas vous restituer les résultats avant plusieurs jours. Grand merci pour tous ces commentaires et aides. Sans obligation, mais on-topic quand même, je reste curieux des raisons pour lesquelles aucun d'entre vous ne semble utiliser *personnellement* le chiffrement de disque (ou de dossier/volume virtuel)
Si, moi ! Comme je l'ai indiqué, j'utilise un fichier de 300 Go pour les données personnelles, montée en loop et crypté avec cryptsetup.
Le 28/09/2020 à 08:16, Gerald a écrit :
Le 27 septembre 2020 à 20:40, pehache a écrit :
Il y a clairement un problème, mais difficile à identifier. Refais déjà
le test sur un disque interne de ton Mac au lieu d'une clé USB.
Je vais plutôt partir sur un essai réel de reformatage du disque 3 To
de destination, suivi de reprise du protocole, mais à partir d'un
autre ordi (Macbook) pour ne pas bloquer mon ordi de bourreau, et
parallèlement commande d'un DD neuf pour éliminer l'hypothèse d'un
problème hardware.
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela
simplifiera les sauvegardes par duplication disque à disque, d'une
manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Compte-tenu des temps prévisibles (du chiffrement, puis de la
sauvegarde des données, et de livraison du nouveau disque), je ne
reviendrai pas vous restituer les résultats avant plusieurs jours.
Grand merci pour tous ces commentaires et aides.
Sans obligation, mais on-topic quand même, je reste curieux des
raisons pour lesquelles aucun d'entre vous ne semble utiliser
*personnellement* le chiffrement de disque (ou de dossier/volume
virtuel)
Si, moi ! Comme je l'ai indiqué, j'utilise un fichier de 300 Go pour les
données personnelles, montée en loop et crypté avec cryptsetup.
Il y a clairement un problème, mais difficile à identifier. Refais déjà le test sur un disque interne de ton Mac au lieu d'une clé USB.
Je vais plutôt partir sur un essai réel de reformatage du disque 3 To de destination, suivi de reprise du protocole, mais à partir d'un autre ordi (Macbook) pour ne pas bloquer mon ordi de bourreau, et parallèlement commande d'un DD neuf pour éliminer l'hypothèse d'un problème hardware.
Je suggère l'acquisition d'un socle pouvant accueillir 2 DD, cela simplifiera les sauvegardes par duplication disque à disque, d'une manière autonome sans avoir besoin d’allumer un ordi (la nuit par exemple).
Compte-tenu des temps prévisibles (du chiffrement, puis de la sauvegarde des données, et de livraison du nouveau disque), je ne reviendrai pas vous restituer les résultats avant plusieurs jours. Grand merci pour tous ces commentaires et aides. Sans obligation, mais on-topic quand même, je reste curieux des raisons pour lesquelles aucun d'entre vous ne semble utiliser *personnellement* le chiffrement de disque (ou de dossier/volume virtuel)
Si, moi ! Comme je l'ai indiqué, j'utilise un fichier de 300 Go pour les données personnelles, montée en loop et crypté avec cryptsetup.
