Impossible d'ouvrir ma session

[hjr]

Bonjour

Quand j'essaie d'ouvrir ma session, j'ai le message suivant : "Vous ne pouvez pas ouvrir de session sous le compte utilisateur "intel" pour le moment. L'ouverture de session du compte a échoué à la suite d'une erreur."
En fait cela vient d'une succession de mauvaises manip'. J'ai fait un peu n'importe quoi et je ne me souviens pas trop des chemins que j'ai empruntés.

En essayant d'être claire : j'ai souhaité changer le nom de mon dossier de départ. J'ai activé le compte root puis j'ai ouvert une session avec ce compte. J'ai changé le nom du dossier de départ. J'ai créé un nouvel utilisateur. Bref j'ai appliqué la procédure trouvée sur le support d'apple.
Sauf que cela ne fonctionnait pas pour moi à l'étape de "Vous devez pouvoir accéder à tous vos fichiers d’origine (sur le bureau, dans le dossier Documents et dans les autres dossiers du répertoire de départ)."

Là j'ai fait n'importe quoi. J'ai supprimé le fichier "intel.sparsbundle". J'ai essayé de redémarrer ma session : impossible. Puis je me suis rendue compte de ma bourde donc je suis allée chercher le fichier dans la corbeille. J'ai pu réouvrir ma session du coup. Mais ensuite je ne sais plus ce que j'ai fait mais en changeant les noms et en supprimant les comptes utilisateurs créés, j'ai dû faire des mauvaises manip' parce qu'après impossible d'ouvrir. Et le message cité au début de ce message.

Si quelqu'un peut m'aider, ce serait chouette. C'est la première fois que je poste un message sur un forum macgé. Donc désolée si c'est trop long, mal formulée, imprécis etc… Heeelpp !

Merci !

 

[bompi]

As-tu au moins un compte avec lequel ouvrir une session ?

 

[pascalformac]

et coté sauvegardes externes
clone?
Time machine?
les deux?

 

[hjr]

Merci de ton aide !
Oui j'ai d'autres sessions à ouvrir ; notamment une session "root".

---------- Nouveau message ajouté à 19h23 ---------- Le message précédent a été envoyé à 19h21 ----------

Je suis un peu nulle en sauvegarde externe donc…rien ou alors des dossiers par-ci, par-là sur des clés usb.

 

[pascalformac]

Je suis un peu nulle en sauvegarde externe donc…rien ou alors des dossiers par-ci, par-là sur des clés usb.

pas bon
1 ce n'est qu'une "copie" partielle
dite " picorage"
déconseillé car manque des tonnes de fichiers importants


2- les cles USB ne sont PAS des supports de stockage fiables
là pour transport temporaire entre ordi 1 et 2


alors qu'une vraie sauvegarde ( sur disque externe) clone et ou time machine ou au moins copie de tout un dossier ( le compte)
resoud 1 et 2

 

[Membre supprimé 1060554]

Salut hjr (habile_joliment_refaite)

Concernant le problème que tu exposes, le diagnostic est aisé, la réparation plus délicate.

Diagnostic​

Supposons que ton nom abrégé de compte original était : intel, que tu voulais renommer en lola (nom que je prends en exemple tout du long et que tu remplaces par le nouveau que tu souhaites). En session root, tu as donc graphiquement été à /Utilisateurs/intel et tu as manuellement édité l'intitulé du répertoire en lola. Puis, tu as été dans les Préférences Système/Comptes où tu as créé un nouvel utilisateur au nom abrégé : lola et le Système t'a demandé : un répertoire de compte du même nom existe déjà - voulez-vous l'utiliser comme répertoire de l'utilisateur lola? - Tu as dit oui, et normalement la procédure que tu as employée était correcte et tu aurais dû pouvoir te logger dans la session lola sans problème. Sauf...

... sauf que tu as oublié un point décisif : comme tu évoques au passage un intel.sparsebundle, cela signifie qu'étant sous «Léopard 10.5», à la création du compte intel tu avais coché l'option : Activer la protection FileVault, dont la propriété dans sa version 1 (correspondant à «Léopard 10.5») est de crypter le répertoire d'utilisateur concerné sous forme d'une image-disque protégée par un mot-de-passe .sparsebundle. Le résultat est que le répertoire d'utilisateur de intel présent à l'adresse /Utilisateurs se présente sous forme d'une structure gigogne : un dossier intel contenant un disque intel.sparsebundle à la place des sous-répertoires classiques d'utilisateur (Bureau, Téléchargements, Bibliothèque, Documents, Séquences, Musique, Images, Public et Sites -sous «Léopard»-).

Lorsque tu as donc créé ton nouveau compte lola, en le liant (dans les 'Options avancées' du panneau des Comptes dans les Préférences Système) au répertoire des /Utilisateurs renommé à l'avance de intel en lola, cette opération qui normalement étend récursivement aux sous répertoires du compte lié les droits d'accès propriétaires du nouveau compte (= lola) s'est en fait heurté à un mur en béton armé : le disque crypté intel.sparsebundle, non monté et verrouillé par son mot-de-passe. Ce qui fait que les sous-répertoires de ce compte n'ont pu être approprié récursivement au répertoire propriétaire lola. À partir de là, en résumé, c'était mal barré.

Ce que tu as bien pu faire ensuite en te débattant dans une fuite en avant manipulatrice grevée par l'ignorance du 'fond du problème' (pour parodier Graham Greene ) - je conjecture que ça n'a pas dû être triste.

Lorsque tu as tenté, par exemple, de mettre à la corbeille le contenu du répertoire renommé lola (ex intel) = le intel.sparsebundle, tu n'avais pas conscience qu'il s'agissait du contenu crypté sous forme de disque du répertoire complet d'utilisateur. Tu n'avais plus alors qu'une enveloppe vide à l'adresse /Utilisateurs = un dossier vide lola. Et quand tu évoques une erreur ensuite à l'ouverture de session, il s'agissait vraisemblablement d'une situation où cela impliquait de monter le volume du disque crypté intel.sparsebundle avec le mot-de-passe originel d'intel, alors que tu avais dû définir un autre mot-de-passe de session inopérant par conséquent.

Le seul point clair et net, qui est un levier décisif, c'est que tu possèdes une session root ouvrable dans l'espace laquelle tu peux rattraper les choses.

♤

La réparation​

Comme je possède un MacBook qui fait tourner «Léopard 10.5.8» (ton OS d'après tes infos) dont la session root est ouvrable, je me suis amusé à diverses manipulations qui ont eu pour moi un parfum nostalgique : celui de cet âge héroïque où, sans savoir ce que je faisais quand je le faisais, néanmoins la même fougue au service de la même curiosité expérimentale que les tiennes me conduisaient à démonter et remonter hardiment et sans crainte les diverses pièces de la 'mécanique logicielle' d'OSX.

Donc, concernant les données de ton problème que j'ai reproduites, je me suis aperçu qu'une fois qu'on a cassé la 'solidarité formelle' qui lie un compte d'utilisateur protégé par FileVault_1 avec le répertoire dédié ET son contenu gigogne : le .sparsebundle, on n'arrive pas à reconstituer correctement le puzzle. Alors voilà la solution un tantinet byzantine (comme l'esprit de son auteur) que je te propose et qui a marché pour moi (il y en a sans doute bien d'autres) ☞

• Tu te logges en session root. Tu vas à /Utilisateurs et tu déplaces l'élément stratégique intel.sparsebundle dans l'espace du répertoire /Utilisateurs hors de tout répertoire d'utilisateur qui pourrait bien le contenir actuellement, de manière à ce que la suppression de compte dans le panneau dédié des Préférences Système n'enraîne pas avec elle sa destruction.
  
  
• Tu vas maintenant à Préférences Système/Comptes et tu supprimes résolument le compte lola (dans les faits : celui au nouveau nom que tu souhaitais) qui pourrait bien y exister avec l'option : suppression de son répertoire d'utilisateur (le intel.sparsebundle délocalisé n'étant donc pas touché).
  
  
• Tu vas à /Utilisateurs et grâce au Finder tu crées un dossier vide que tu nommes lola (en fait le nouveau nom que tu souhaites) - si jamais l'ancien dossier lola avait subsisté, tu le supprimes préalablement à cette re-création ex nihilo. Tu double-cliques maintenant le disque .intel.sparsebundle pour le monter. Une fenêtre se lance : Diskimages-helper veut utiliser le trousseau « FileVaultMaster » - veuillez saisir le mot-de-passe du trousseau. Tu presses le bouton 'Annuler', ce qui démasque une 2è fenêtre : Saisissez le mot-de-passe pour accéder à « intel.sparsebundle ». Tu tapes le mot-de-passe de ton ancien compte intel et le volume du disque crypté monte sur le Bureau de root. Tu ouvres ce volume, tu sélectionnes tous les sous-répertoires décryptés de l'ancien répertoire intel et tu fais un glisser-déposer dans l'espace du dossier vide : lola, ce qui les copie dans ce dossier.
  
  
• Je vois déjà les puristes du forum en train de sourciller : hou! l'autre... Non content d'avoir créé par l'utilisateur root un répertoire lola dont root seul est le propriétaire en tant que son créateur, il vient de le remplir avec des copies qui, ayant root pour auteur, reproduisent le même propriétaire indû au niveau des sous-répertoires! - Je réponds : qui vivra verra . Car, superbes d'audace, allons donc à : Préférences Système/Comptes et pressons le bouton + pour créer un nouvel utilisateur. Nous prenons pour paramètres : admin, nom propre : Lola, non abrégé : lola (= rigoureusement le même que celui de l'intitulé du répertoire des /Utilisateurs - dans les faits : même nouveau nom conforme à tes souhaits), mot-de-passe : quodlibétique (celui qu'on veut) et inutile à ce stade d'activer la protection FileVault (il est toujours possible, après coup, de l'activer une fois loggé dans la session lola en allant au panneau Sécurité des Préférences Système). Lorsqu'on appuie le bouton : 'Créer', le Système demande comme déjà vu : un répertoire de compte du même nom existe déjà - voulez-vous l'utiliser comme répertoire de l'utilisateur lola? - Répondre oui.
  
  
• En allant par curiosité à /Utilisateurs/lola, il suffit de faire plusieurs ⌘I sur le répertoire global lola et ses sous-répertoires, et la bonne nouvelle s'affiche : lola a destitué récursivement root de la propriété du répertoire et de ses éléments, conformément aux attentes malignes de l'expérimentateur. Que demande le peuple? Il suffit de quitter la session root et à l'écran d'ouverture de session d'aviser l'utilisateur lola. En tapant son mot-de-passe, la session lola s'ouvre et en fait c'est celle d'intel (avec tous ses paramètres et documents), seul le nom a changé.

♧​

☞ cette expérience de disparition du nom et de préservation des choses paraît apporter un démenti à la citation d'Umberto Eco dans «Le nom de la rose» : «stat rosa pristina nomine nomina nuda tenemus » : de la rose d'autrefois ne subsiste que le nom - ce sont les noms seuls que nous détenons (jeu de mot médiéval sur rosa / cosa : sons si proches que le mot rosa, la rose, était pris pour synonyme de cosa -bas latin pour causa-, la chose --> les choses nous filent entre les doigts / nous ne possédons durablement que les noms qui les désignent. Sauf qu'au plan informatique il n'y a pas de 'choses', il n'y a que des 'noms', c'est-à-dire des signes d'écriture.

♡​

 

[hjr]

Merci beaucoup macomaniac pour cette réponse très détaillée et qui colle exactement à ce qui m'arrive. Bien entendu je n'ai pas tout compris (sinon je n'aurais pas fait la bourde qui m'a menée sur ce forum). Mais je vais, illico, imprimer tout cela, le lire tranquillement et surtout suivre scrupuleusement la procédure de réparation.

Je te tiens au courant. Encore un grand merci …

---------- Nouveau message ajouté à 09h10 ---------- Le message précédent a été envoyé à 08h03 ----------

Macomaniac,
Quand je suis à l'étape 3 de la réparation (Une fenêtre se lance : Diskimages-helper veut utiliser le trousseau « FileVaultMaster » - veuillez saisir le mot-de-passe du trousseau.), aucune fenêtre ne se lance. J'ai comme message : Echec du montage des images disques suivantes ; raison = opération non gérée sur la socket.

J'ai essayé d'ouvrir avec Utilitaire de disques / Restaurer mais nada : je n'arrive pas à rentrer la source et la destination.

??

---------- Nouveau message ajouté à 09h21 ---------- Le message précédent a été envoyé à 09h10 ----------

Je me pose des tas de questions de débutante : et si je pouvais désactiver filevault sur ma session inaccessible par un autre chemin ? et si je supprimais ma session intel en faisant enregistrer le dossier de départ ? et si le passage dans la corbeille du intel.sparsebundle l'avait rendu illisible ?

 

[Membre supprimé 1060554]

Salut hjr.

Ce n'est pas de veine que tu n'arrives pas à monter manuellement le volume de l'image-disque intel.sparsebundle. Car si tu n'y parviens pas, son contenu est inaccessible et la manip que je t'ai expliquée bloque faute d'accès aux répertoires d'utilisateur d'intel.

Pour l'instant, je ne peux que t'inciter à insister --> au cas où l'emplacement de intel.sparsebundle dans le répertoire /Utilisateurs serait le facteur bloquant, tu peux déplacer l'image-disque, par exemple sur le Bureau de root, voire la copier sur un DDE USB connecté au Mac, afin de vérifier si localisée à ce nouvel emplacement il est possible de monter le volume (que donne un double-clic?).

Va maintenant à /Applications/Utilitaires et lance «Trousseau d'accès». Au menu Fichier, sélectionne l'option : Déverrouiller le trousseau "FileVaultMaster" --> tu vas devoir renseigner le mot-de-passe que tu avais défini pour l'activation de FileVault (qui est peut-être le même que le mot-de-passe de session d'intel, mais pas nécessairement, au cas où tu aurais choisi un mot-de-passe maître pour FileVault entièrement distinct. Tu vas bien voir si le cadenas du trousseau : FileVaultMaster se déverrouille (que donne un double-clic sur le .sparsebundle?).

En lançant l'«Utilitaire de Disque», qui ne voit pas l'image-disque d'entrée, tu peux la glisser de son nouvel emplacement (Bureau par ex.) dans la colonne de gauche de l'utilitaire : elle va s'afficher, et, en la sélectionnant, tu peux engager l'option : Réparer le disque --> tu risques de rencontrer une demande de mot-de-passe, mais si le trousseau : FileVaultMaster est déverrouillé, ce ne sera que celui de la session ancienne de intel --> après réparation du .sparsebundle, est-ce que le bilan dans la fenêtre de droite de l'utilitaire est au vert (disque = OK)? Que donne un double-clic sur le .sparsebundle?

☞ si jamais une de ces manœuvres te permettait de monter le volume du .sparsebundle et d'accéder aux répertoires de l'utilisateur intel, alors continue la procédure que je t'ai décrite. Si rien ne marche, il me faudra réfléchir au procédé permettant de reconstruire le dispositif initial du répertoire intel lié à l'utilisateur intel (tu as bien dit dans ton 1er message que tu avais réussi à relancer ta session intel une fois en remettant le .sparsebundle de la corbeille dans le répertoire intel de /Utilisateurs? Tu ne peux pas recommencer? Parce que tu as trop chamboulé les identifiants de comptes dans le panneau des Préférences Système? Ou les mots-de-passe?). Quand je dis qu'il faut que je réfléchisse, c'est que passé le matin, je ne vaus plus rien et qu'il me faudra bidouiller expérimentalement sur mon MacBook sous «Léopard 10.5.8».

 

[hjr]

Merci macomaniac.

Alors :

- je n'ai pas FileVaultMaster dans Trousseau d'accès donc je n'ai rien à dévérouiller
- pour les mots de passe, pour ne pas m'embêter, j'ai le même à toutes les sessions
- pour Utilitaire de disque, le glisser-déposer dans la colonne de gauche est ok ; ensuite j'arrive à le mettre dans la source mais pour l'emplacement du disque-cible, je n'ai pas la main ; de toute façon, à un moment, le fichier s'évapore dans un bruit de feuille froissée

J'ai essayé DATA rescue. Je n'arrive pas à sélectionner le fichier en particulier mais seulement le volume entier de mon ordi.

Que penses-tu de supprimer la session et d'enregistrer le dossier de départ ?
Cela m'agace un peu. J'ai l'impression que la solution est tout près, qu'il ne faudrait pas grand-chose. Au moins me souvenir des chemins empruntés.

On peut désactiver FileVault sur la session intel en passant par un terminal ?

 

[Membre supprimé 1060554]

Je viens de tester et de réussir sur mon MacBook sous «Léopard» la manip suivante que je transpose pour toi relativement à un utilisateur intel.

1. Logge-toi en root. Veille dans le répertoire Utilisateurs à ce que le disque crypté intel.sparsebundle ne soit contenu dans aucun dossier d'utilisateur, mais coexiste à côté d'eux à l'état isolé et indépendant.
   
   
2. Va au panneau des Préférences Système/Comptes et supprime résolument tout utilisateur intel qui y apparaîtrait avec l'option : supprimer le dossier de départ (tu peux vérifier dans Utilisateurs qu'aucun dossier intel n'y existe plus. Sinon tu le mets illico à la corbeille).
   
   
3. Toujours dans le panneau Comptes, demande la re-création d'un utilisateur intel (admin, nom abrégé strictement intel, même mot-de-passe que le 1er intel dont le dossier crypté est le intel.sparsebundle). Et surtout ☞ coche la case : activer la protection Filevault (Attention! Décisif! Il faut absolument que tu re-crées un compte intel avec FileVault activé, afin qu'un répertoire crypté neuf, intitulé intel.sparsebundle soit généré dans son répertoire d'utilisateur).
   
   
4. Une fois le compte intel protégé par FileVault créé, re-démarre afin que les nouveaux paramètres soient installés dans le Système. Ne te logge pas dans la session intel. Re-logge-toi en session root derechef.
   
   
5. Dans la session root, va da capo au répertoire des Utilisateurs et ouvre le répertoire intel. Il faut absolument que son seul contenu soit une image-disque cryptée : intel.sparsebundle. Alors tu sélectionnes le fichier intel.sparsebundle isolé dans le répertoire des Utilisateurs (l'originel, objet de tous tes désirs, celui qui contient toutes les données cryptées du compte intel originel) et tu fais un glisser-déposer de l'item dans le répertoire intel afin d'écraser le intel.sparsebundle de 2è génération et vide de données personnelles. Une fenêtre te demande si tu veux remplacer intel.sparsebundle qui existe déjà par celui que tu fais glisser : tu réponds oui et hop! substitution. Attention! ne te trompe pas de sens : tu remplaces le nouveau intel.sparsebundle vide de données intéressantes par l'ancien plein de données intéressantes!
   
   
6. Fais ⌘I sur ce fichier image-disque intel.sparsebundle et lis les droits listées en bas de la fenêtre (bascule l'onglet s'il faut) à Partage et permissions. S'il y a marqué :
   
   

   intel : lecture & écriture
   everyone : accès interdit

   
   c'est tout bon. Si à la place d'intel il y a 'utilisateur inconnu' ou quoi que ce soit d'autre, alors tu ouvres une fenêtre du «Terminal» (/Applications/Utilitaires) et tu fais un copier-coller de :
   
   

   chown intel /Users/intel/intel.sparsebundle

   
   et presse la touche 'Entrée' du clavier pour activer la commande. En refaisant ⌘I sur intel.sparsebundle contenu dans le répertoire intel des Utilitsateurs, lis-tu bien :
   
   

   intel : lecture & écriture
   everyone : accès interdit

   
   Si oui, c'est bon.
   
   
7. Re-démarre encore une fois et logge-toi dans la session intel avec le mot-de-passe régulier. S'il n'y a pas de lézard, tu devrais pouvoir ouvrir ta session avec tes anciens paramètres et documents du compte intel originel. Si tout va bien (preuve que le disque intel.sparsebundle a été décrypté et monté), va maintenant à : Préférences Système/Sécurité/FileVault et demande la désactivation de la protection FileVault (attention! décisif!), ce qui peut prendre un certain temps si tu as beaucoup de données. À la fin, le Mac te ramène à l'écran d'ouverture de session.
   
   
8. Tu te re-loggues en root et tu vas à /Utilisateurs. Tu peux voir que le répertoire intel (si tu l'ouvres) est redevenu un banal répertoire non crypté. Superbe d'audace, tu le renommes en lola (mon exemple pour le nouveau nom que tu veux) si aucun utilisateur lola n'existe déjà, effet de tes manips antérieures. Si cela était, avant ce renommage, va au Panneau des Comptes et supprime préalablement l'utilisateur lola avec son répertoire. Alors seulement, renomme le répertoire intel des Utilisateurs en lola [Allo? Il y a toujours quelqu'un? ].
   
   
9. Tu vas au panneau Comptes une fois de plus, et tu crées un utilisateur admin intitulé? - lola! Le système te demande si tu veux lui attribuer le répertoire de départ qui existe déjà, et tu réponds : OUI. Tu re-démarres.
   
   
10. Tu te loggues dans la session lola et tu te retrouves dans le même environnement que dans l'ancienne et primitive session intel. Seul le nom d'utilisateur a changé.

☞ DONE.

 

[hjr]

Merci merci macomaniac.

J'ai juste un peu peur de supprimer le dossier de départ de ma session. D'où ma question : est-ce que je peux faire tout ce que tu me dis sauf l'étape où je supprime le dossier de départ ? Et bien sûr je le mets ailleurs que dans le dossier "Utilisateurs".

En fait quand je monte l'image disque de l'utilisateur "root", tout se passe bien et j'ai un disque root dans le Finder. Par contre quand j'essaie de faire la même chose avec "intel.sparsebundle", il y a : "Echec du montage des images disques" + "opération non gérée sur la socket". D'où mon flip que mon fichier "intel.sparsebundle" soit en fait corrompu et que je perde tout.

Qu'en penses-tu ? En attendant ta réponse, j'essaie de copier mon "intel.sparsebundle" sur une clé USB et j'essaie de monter l'image sur l'ordi de mon mari.

 

[Membre supprimé 1060554]

...avec "intel.sparsebundle", il y a : "Echec du montage des images disques" + "opération non gérée sur la socket". D'où mon flip que mon fichier "intel.sparsebundle" soit en fait corrompu et que je perde tout.

Personnellement, je me suis toujours méfié du protocole de chiffrement du répertoire de départ d'utilisateur FileVault_1, car en cas d'impossibilité accidentelle de décrypter le disque .sparsebundle qu'il génère et de monter son volume, toutes les données du compte sont perdues. C'est ce qui arrive lorsque le disque crypté .sparsebundle est corrompu. Si c'était le cas pour ton image-disque intel.sparsebundle, autant dire que c'est fichu.

Lorsque tu crées un compte d'utilisateur sous «Léopard» en activant la protection FileVault_1, il se passe 3 choses : il y a création d'une UserID dans la base de données du DirectoryService («Répertoire d'Annuaire») avec tous ses paramètres (nom -par exemple intel-, GroupID -par exemple admin-, Shell d'accès -par exemple /bin/bash-, mot-de-passe, identifiant d'utilisateur -par exemple 501 etc.). En relation avec l'UserID, il y a la création d'un Répertoire_de_départ, qui est un dossier portant l'intitulé du nom abrégé de l'utilisateur et créé par défaut dans le répertoire-système des /Utilisateurs, avec comme contenu une structure de sous-répertoires (Bureau, Documents, Musique etc.), lesquels ont des droits strictement réservés à l'utilisateur-propriétaire. Mais un 3è facteur intervient, qui est l'association d'un protocole de chiffrement du répertoire de départ à l'UserID lorsque la protection FileVault_1 est activée. Ce protocole crée un DiskImage .sparsebundle à l'intérieur du répertoire de départ de l'utilisateur, dont tous les sous-répertoires sont déplacés à l'intérieur de son volume logique. Il faut alors que le volume du DiskImage .sparsebundle soit monté, pour que les sous-répertoires de l'utilisateur soient accessibles, et une fois le volume démonté, ils deviennent inaccessibles. Le processus de montage/démontage est associé aux actions de l'utilisateur : ouvrir une session/quitter la session. Comme le montage/démontage s'accompagne d'un déchiffrement/chiffrement, un mot-de-passe FileVault est créé pour le gérer, et le mot-de-passe de l'utilisateur (qui peut en différer) est considéré comme ayant un pouvoir de substitution équivalent.

Comme tu peux le voir, c'est un montage logique compliqué, 'cryptique' serait le mot juste. Normalement, le DiskImage .sparsebundle contenu dans le répertoire de départ de l'utilisateur qui a activé la protection FileVault_1 se monte/démonte automatiquement à l'ouverture/fermeture de session de l'utilisateur. Mais, optionnellement, il est toujours possible à partir d'une session root de monter manuellement (double-clic) le volume du DiskImage .sparsebundle de l'utilisateur dont la session n'est pas ouverte - à la stricte condition que l'utilisateur root puisse renseigner le mot-de-passe associé au protocole FileVault : soit le mot-de-passe Maître, soit le mot-de-passe de l'utilisateur. En l'absence de ces mots-de-passe, root est aussi incapable que quiconque de lancer le déchiffrement du DiskImage .sparsebundle préalable au montage de son volume.

Mon message #6 supposait implicitement que le montage manuel du DiskImage chiffré : intel.sparsebundle dans une session root était exécutable, dès lors que tu connaissais le mot-de-passe de l'utilisateur intel qui avait choisi la protection FileVault_1. Le fait que le Système refuse d'engager cette procédure est tout à fait alarmant.

Mon message #8 t'a proposé plusieurs bricolages susceptibles d'outrepasser ce blocage inquiétant.

Mon message #10 t'a décrit une manœuvre de contournement graphique de la difficulté : re-créer de toutes pièces un utilisateur intel avec activation de la protection FileVault_1 sur le répertoire de départ, ce qui revient à générer dans le répertoire des /Utilisateurs un dossier intel contenant une DiskImage intel.sparsebundle chiffrée dont le montage/démontage du volume soit associé automatiquement à l'ouverture/fermeture de session de l'utilisateur intel. Une fois cette structure compliquée remise en place, la tactique consiste à berner le Système en remplaçant le DiskImage intel.sparsebundle créé de neuf par défaut (et vide de données personnelles) par l'ancien DiskImage intel.sparsebundle (recelant toutes les données personnelles) à l'intérieur du répertoire de départ intel des /Utilisateurs.

Ce remplacement de la DiskImage .sparsebundle attendue formellement par une DiskImage .sparsebundle trouvée présentant en tout point une identité formelle (d'intitulé, de droits propriétaires et de mot-de-passe de chiffrement) quoique le contenu embarqué dans son volume soit différent - normalement produit l'effet attendu, si & seulement si le disque n'est pas corrompu : il va y avoir déchiffrement et montage automatique de la DiskImage intel.sparsebundle à l'ouverture de la session de l'utilisateur intel qui utilise le répertoire de départ intel sur simple renseignement de son mot-de-passe admin inchangé. En cas de succès, la désactivation de la protection FileVault_1 permettrait de restaurer le répertoire de départ au statut normal (pas de DiskImage chiffrée) et par voie de conséquence le renommage classique en session root de ce répertoire plus verrouillé par la présence du sparsebundle.

Tu peux, pour lénifier tes appréhensions, faire une copie préalable du intel.sparsebundle sur un disque externe si tu veux - mais si tu n'es pas capable de monter son volume par déchiffrement de sa protection, autant dire qu'il n'y a là qu'un 'safe' imprenable et sans usage. Cela fait, je t'engage à tenter jusqu'au bout la manœuvre que je t'ai décrite. Je l'ai testée expérimentalement avec succès, d'où mon luxe de détails à la description. Si quelque chose peut monter le volume du intel.sparsebundle, c'est bien le protocole FileVault_1 associé à un compte intel dont l'UserID soit liée à un répertoire de départ intel recelant une DiskImage intel.sparsebundle formellement valide à l'emplacement attendu.

 

[pascalformac]

si on pige tu utilises " filevault"
( entité de sécurité , creation de "coffre fort" qui crypte verrouille les données)

perso- et je suis loin d'etre le seul- je déconseille
pourquoi?
très simple
en cas de probleme avec filevault
dans 90% des cas on ne peut rien faire pour acceder au contenu ( du coffre fort)


donc sauf s'il y a de bonnes justifications pour utiliser ce coffre fort là , autant éviter

 

[bompi]

Il faut quand même noter que Filevault a beaucoup changé entre Leopard et aujourd'hui.
Il me semble qu'actuellement, le chiffrement est mieux intégré que dans la première mouture.

Reste que si le disque part en vrille ou qu'il y a un bug sérieux dans le chiffrement, c'est râpé (et c'est logique : c'est quand même aussi le but de la sécurité).

 

[pascalformac]

toutafédakkor avec les deux aspects
( le mieux avec versions récentes et le négatif en cas de coincage rendant le coffre... inutilisable inouvrable)
c'est juste pour rappeler le petit risque lié à cette option, après chacun agit selon son choix, mais en en ayant conscience

 

[hjr]

Merci pour vos messages macomaniac, pascalformac, bompi.
Ce que je pressentais s'est avéré exact : le fichier intel.sparsebundle était corrompu.
Je me suis résolue à emmener mon ordi chez un "réparateur mac". Et (sniff) données non récupérables car impossible de monter l'image-disque.

Moralité : NE JAMAIS UTILISER FILEVAULT (en tout cas pour moi qui n'ai rien à crypter sur mon ordi) et FAIRE DES SAUVEGARDES.

Le réparateur mac me propose de me réinstaller le système pour repartir sur quelque chose de propre. Qu'en pensez-vous ? J'hésite. J'ai en moi l'espoir qu'un jour quelqu'un réussira à retrouver mes vidéos et photos qui sont sur l'ordi, quelque part… Espoir vain ??

Encore merci pour ton aide macomaniac.

 

[pascalformac]

aie
pas de bol
sans doute victime des faiblesses de filevault sur anciens OS
( plus manips hasardeuses en mode apprenti sorcier)

le truc un peu idiot c'est que tu aurais fait des sauvegardes completes standards ( clone ou time machine) la situation aurait peut etre pu etre corrigée par des retours arrières
( sauvegarde toujours à faire et primordial quand on se lance dans des manips "réparatrices")

la situation est peut etre réparable
(ou pas)
je conseillerai de faire un clone bootable sur un disque externe
car si un jour tu tombes sur une solution , tu auras le clone pour la tester
et ensuite
réparer -reinstaller l'OS sur disque interne
( ce que tu peux faire toi même)

je ne suis pas dans le cerveau du réparateur mais son idée est probablement de remplacer des fichiers de fonctionnement nazes ou perdus par des neufs
curieux qu'il n'ait pas fait ca sans t'en parler
( maj combinée ou nouvel OS)

 

[RmY]

Bonjour macomaniac, (et confrères),

suite à nos échanges mp de ce matin je reprends donc ici.

Le disque dur de HJR est arrivé entre nos mains pour tenter de pousser un peu plus loin les recherches. Une copie de sécurité a été effectuée pour conservation de l'état initial. Nous avons effectué plusieurs tentatives pour l'instant infructueuses et souhaitons envisager d'autres pistes.

Je ne rentre pas dans les détails pour le moment, mais je peux développer chaque information à la demande. Voici les constats de départ : il existe bien la trace de deux dossiers portant le nom de l'utilisateur (appelons les HJR1 et HJR2) aussi bien dans le dossier Users que dans la corbeille de root puisqu'il y a eu des tentatives par ce biais. Ces deux dossiers concordent deux à deux dans la corbeille et dans le dossier Users. L'un [HJR2] est le fait d'une tentative de re-création de profil (le déchiffrage filevault et le montage sont fonctionnels, mais le volume est vide de données) et l'autre [HJR1] est "le bon", objet de tous les désirs de l'utilisateur, toussa…

Nous avons tenté de notre côté de reproduire les tentatives et constatons plusieurs choses inquiétantes : dans le sparsebundle.HJR1, les "bandes" contenues dans le sous-dossier "bands" n'ont pas les mêmes droits utilisateur (et possiblement droits ACL) que lorsqu'un nouvel utilisateur est créé. Par ailleurs, et sans doute pire, il n'y a pas dans ce sparsebundle de fichier "token" ni pas plus de info.plist ou info.bckup…

Le meilleur résultat auquel nous sommes parvenu est effectivement de recréer une situation ou le filevault peut être déverrouillé, mais ensuite le volume n'est pas conforme, ne présente pas de partitionnement, fait une taille aberrante. Le reste des astuces de contournement ne fonctionne pas. Ce résultat a été obtenu en créant un utilisateur dans les mêmes conditions (comme indiqué ci-dessus) puis en faisant un rsync + chmod du contenu du dossier bands.

Pistes à explorer :
De ce que nous comprenons du problème, l'agrégat des bandelettes du sparsebundle permet la création d'une image disque chiffrée type WDE. Dans un premier temps il y a ouverture du conteneur de chiffrement géré par Filevault, puis dans un second temps montage des volumes. Tout cela est transparent pour l'utilisateur, mais un chiffrement reste un chiffrement avec un algorithme, une méthode, une ou plusieurs clés et un état de départ chiffré et un état d'arrivée déchiffré.

Quelqu'un pense-t-il, comme moi, qu'il doit être possible :
- de ré-agréger les bandelettes pour faire un seul volume chiffré (il me semble de mémoire qu'historiquement les bandelettes avaient été créées pour permettre une synchro plus rapide du volume utilisateur chiffré avec timemachine),
- puis "par un moyen ou un autre" (désespoir inside) récréer la clé de déchiffrement puisque les éléments sont connus (login, mot de passe, nom d'utilisateur, mot de passe root, mot de passe général/master filevault et je ne vois pas ce qu'il pourrait falloir d'autre),
- puis de déchiffrer le volume en appliquant le type de chiffrement de Filevault (AES, quelle méthode ?)
- enfin de lier le volume sans le monter pour faire une image de [la partition | du volume] déchiffré(e) afin de pouvoir au bout de compte le vérifier et le monter…

?

Voilà, pour le moment je considère qu'il n'y a que peu d'espoir, mais comme il s'agit pour moi d'une démarche professionnelle, et qu'en plus elle pourrait faire avancer toute une communauté, je m'en voudrais de ne pas essayer d'aller au bout.

Je suis preneur bien sûr de toute autre hypothèse de résolution.

PS : pour le backgroud… /me utilisateur mac très noob, utilisateur linux très avancé, aucun problème avec le terminal et… comme un gros bagage de récupération de données.

 

[Membre supprimé 1060554]

Salut Rémy.

Je vois que tes compétences logiques n'ont rien à apprendre d'un bricoleur fantasque comme macomaniac

dans le sparsebundle.HJR1, les "bandes" contenues dans le sous-dossier "bands" n'ont pas les mêmes droits utilisateur (et possiblement droits ACL) que lorsqu'un nouvel utilisateur est créé. Par ailleurs, et sans doute pire, il n'y a pas dans ce sparsebundle de fichier "token" ni pas plus de info.plist ou info.bckup…

☞ Suggestion d'un bidouillage qui vaut ce qu'il vaut -->

J'avais incité antérieurement l'habile_joliment_refaite (dont on peut dire qu'elle est drôlement accrochée aux données de son .sparsebundle ) à re-créer une UserID strictement identique à celle à laquelle était liée l'image-disque .sparsebundle corrompue, en activant la protection FileVault-1 sur son Dossier de Départ de manière à générer à neuf une image-disque .sparsebundle formellement substituable quoique vide de données. C'est celle que tu as dû trouver dans la corbeille de root.

À n'en pas douter, si tu ouvres le paquet de cette image-disque, non seulement tu dois tomber sur un répertoire bands vide de données, mais ce dernier doit être flanqué des fichiers info.bckup, info.plist et token attendus, qui font par ailleurs défaut dans l'image-disque corrompue.

Serait-il envisageable de les déplacer dans le paquet du .sparsebundle corrompu, afin de restaurer les fichiers manquants par des fichiers correspondants à une UserID au demeurant strictement identique?

Et, cela fait, par une commande récursive chown, suivie ou non selon l'état des permissions, par une commande récursive chmod, de rétablir les accédants et leurs permissions -s'il y a lieu- aux valeurs attendues par défaut d'après l'image-disque .sparsebundle neuve qui a été créée a posteriori en liaison avec une UrerID strictement identique mais en mode formellement valide?​

 

[RmY]

…/…mais ce dernier doit être flanqué des fichiers info.bckup, info.plist et token attendus, qui font par ailleurs défaut dans l'image-disque corrompue.

Serait-il envisageable de les déplacer dans le paquet du .sparsebundle corrompu, afin de restaurer les fichiers manquants par des fichiers correspondants à une UserID au demeurant strictement identique?​

Pour info, et que ce fil de discussion ne reste pas sans suivi pour de futurs utilisateurs, les différentes tentatives n'ont pas abouti.

Je ne voyais pas bien en quoi le fait de copier le fichier token et les info.* dans le .sparsebundle changerait la donne par rapport au fait de faire un rsync du dossier bands dans l'autre sens, mais j'ai tout de même fait le test, ainsi que l'ensemble des autres croisements possibles.

Nous avons aussi passé quelques heures a essayé de trouver des informations sur la façon dont sont chiffrés les dossiers utilisateurs protégés avec Filevault (v1), en vain. À regret, ne pouvant malheureusement pas y consacrer à perte plus de temps, nous allons donc abandonner ce dossier.