10.12 Sierra Permissions System remplacé par Récupération

[Membre supprimé 1060554]

RAS pour wheel : rien à voir --> root est seul membre.

Tu n'as qu'à passer la commande de bompi (message #17) pour obtenir des infos ciblées de la Carte d'Identité de root et poster le retour.

 

[r e m y]

J'ai jeté un oeil hier soir (sur ma machine encore sur Yosemite) et, par exemple pour root :
dscl localhost -read /Local/Default/Users/root RealName RecordName UniqueID _writers_realname

[iMac-Famille:~] famille% dscl localhost -read /Local/Default/Users/root RealName RecordName UniqueID _writers_realname
RealName:
System Administrator
RecordName: root
UniqueID: 0
No such key: _writers_realname


Par rapport au retour obtenu par Bompi, je n'ai pas le
BUILTIN\Local System

 

[r e m y]

tout semble OK... je vais cloner le disque puis réinstaller macOS

 

[Membre supprimé 1060554]

Rien à redire non plus à ces paramètres de ton root.plist -->

- la clé (key) RealName a pour valeur de chaîne (string) : System Administrator

- la clé RecordName pour valeur de chaîne : root

- la clé UniqueID pour valeur de chaîne : 0 (= identifiant régulier de root en en valeur octale)​

J'ai strictement pareil dans le root.plist de mon OS.

Note néanmoins (conjecture affinée) : il pourrait suffire d'une corruption quelque part ailleurs dans le plist de root > pour que sa lecture soit altérée lors de la fameuse « récupération du RealName à fins d'affichage graphique »...

[Quoi plus précisément ? - en ce qui me concerne : jet de l'éponge

]

 

[r e m y]

Pareil...

Réinstallation de Sierra en cours.
Je vous tiens au courant dès qu'il arrive au bout de la root.

 

[r e m y]

Bon...
Réinstallation de Sierra terminée mais sans changement.
Toujours ce foutu "Récupération" là où devrait se trouver "Système".

Je laisse tomber, d'autant que ça n'a aucun impact dans le fonctionnement.

 

[bompi]

J'ai repassé ma commande sur le MBA sous Sierra (10.12) et j'obtiens pareil :

RealName:
 System Administrator
RecordName:
 root
 BUILTIN\Local System
UniqueID: 0
No such key: _writers_realname

 

[bompi]

Vraiment intriguant, ce fetching...

 

[r e m y]

En ouvrant root.plist avec PlistEditor, on voit que ce compte Root a été migré de mon ancien iMac et malgré la réinstallation de Sierra, il reste ainsi...

Peut-être est-ce l'origine du problème.

D'autre part (et je pense que c'est lié), l'édition avec dscl diffère légèrement de la tienne.
Je n'ai pas ce BUILTIN\Local System

En d'autre terme mon user Root n'a pas le statut de Local System built-in service account (SYSTEM), il n'est qu'un Root immigré que le système ne reconnait pas tout à fait pour l'afficher comme propriétaire d'un certain nombre d'éléments pré-installés.

 

[Membre supprimé 1060554]

En ce qui me concerne, j'ouvre les plist d'utilisateurs de la base de données : /private/var/db/dslocal/nodes /Default/users avec «TextWrangler» qui me présente le dispositif en tableau (array) > clé (key) > chaîne (string) avec toute la clarté requise (et un confort de lecture que n'offre pas dscl dans le «Terminal»).

En inspectant mon root.plist > je ne note pas entre la clé : <key>KerberosKeys</key> et la clé : <key>ShadowHashData</key> une clé : <key>MigratedAccount</key> comme chez toi ; mais une clé : <key>LinkedIdentity</key> qui est un véritable plist à l'intérieur du root.plist.

Ce point de détail ferait-il la différence ?

Car je tiens toujours à la conjecture que l'affichage d'un « Récupération... » (aka: « Fetching... ») dans les fenêtres d'information du Finder provient d'un achoppement en lecture de ton root.plist de la part de l'application. Ce qui n'empêche certainement pas ce root.plist de tenir son rôle pour le Système : représenter l'identité logique de l'utilisateur root.

 

[r e m y]

C'est vraiment mystérieux ce truc et je me perds en conjectures, mais le fait que ce compte Root soit identifié comme un compte "migrated" est certainement à l'origine du "probleme".
Sierra n'aime pas les immigrés... et recherche le root autochtone.


Pour autant, j'hésite à bricoler ce root.plist de peur de perdre tout accès au systeme.
Root n'est quand même pas n'importe quel utilisateur!

Pour l'instant, je vais laisser en l'état, et si un jour j'ai du temps, je démarrerai le Mac sur un clone, pour y faire des expériences de modifications ou de remplacement du root.plist.

 

[Deleted member 1099514]

Pour info que te renvoie un :
cat /etc/group | grep 80

 

[lolipale]

Bonjour,

Lorsque vous cliquez sur un document (clic-droit ou control-clic) et choisissez ouvrir avec ... avez-vous également le terme récupération sans autre choix possible ... ?

 

[r e m y]

Bonjour,

Lorsque vous cliquez sur un document (clic-droit ou control-clic) et choisissez ouvrir avec ... avez-vous également le terme récupération sans autre choix possible ... ?

Non, j'ai bien la liste des applications susceptibles d'ouvrir le document.

 

[FrançoisMacG]

Bonjour r e m y,

J'ai entendu parler de Fetching sous Lion : ça affectait des comptes qui venaient de Tiger.
Ce n'était qu'une anomalie des droits, sans conséquence pratique au quotidien (certains s'en sont même satisfaits), a priori liée au fait que l'UID du compte n'était plus rattachée au compte (OS X lui attribuait alors une immatriculation neutre : Fetching).
La seule solution rapide que j'ai alors lue était de copier le contenu du dossier de l'utilisateur affecté dans un dossier à la racine du Mac, puis de réimporter ces données copiées vers le dossier d'utilisateur.
La solution longue pouvait être la (vraie) clean reinstall.

Dans ton cas (où tout le Mac est affecté), je tenterais une fresh install de Sierra suivie d'une migration (voire d'une réimportation a la mano) au lieu d'une réinstallation au-dessus de ton système actuel.
Bon week-end !

 

[r e m y]

Merci François de ces suggestions.

Effectivement j'ai lu beaucoup de pages décrivant ce problème lié à des comptes utilisateurs migrés (et vu les diverses solutions).

Mon probleme c'est que sur mon Mac, c'est le compte Root qui présente cette anomalie (alors que les comptes utilisateurs importés, eux, n'ont pas ce probleme). Et à priori Root à son UID normale (0) , est bien rattaché au groupe Wheel comme il se doit...

Je pense qu'une clean install permettrait de retrouver un compte Root non affecté de cette anomalie, mais ensuite, je crains qu'une migration depuis le clone de mon ancien iMac recrée le probleme en re-migrant à nouveau le compte Root de l'ancien Mac (et dans l'assistant migration, il n'y a rien pour demander à exclure Root des utilisateurs à faire migrer).

Quant à faire une importation à la mano.... non merci. J'ai deja suffisamment galéré la première fois pour remettre d'aplomb Mail et y retrouver tous mes emails (le passage direct de SnowLeopard à Sierra a ete plutôt mal digéré par l'application Mail)

Comme tout fonctionne normalement et que je n'ai que ce "glitch" graphique en consultant les fenêtres d'information, (les permissions sont pour autant correctes quand on les vérifie en passant par le Terminal), je vais laisser ainsi.

 

[Membre supprimé 1060554]

je crains qu'une migration depuis le clone de mon ancien iMac recrée le probleme en re-migrant à nouveau le compte Root de l'ancien Mac (et dans l'assistant migration, il n'y a rien pour demander à exclure Root des utilisateurs à faire migrer)

Le "compte root" c'est 2 choses : le fichier root.plist (at: /private/var/db/dslocal/nodes/Default/users/ root.plist) qui institue l'Identité d'Utilisateur : root pour le Système et le répertoire root (at: /private/var/root) qui constitue le dossier de départ de l'utilisateur root.

Par défaut > le dossier de départ root est incomplet (pas de sous-dossiers Desktop etc.) > mais constitué (principalement par la Library) > car à la fermeture de session d'utilisateur (admin ou standard) avant extinction du Mac ou re-démarrage > et avant l'ouverture de session d'un utilisateur (admin ou standard) > les instructions de préférences recelées dans la Library sont lues et prises en compte par le Système (par exemple touchant le LoginWindow).

C'est seulement si un utilisateur admin a choisi d'ouvrir un session graphique root (avec un mot-de-passe de session spécifiquement défini pour ce faire) > qu'en préambule de cette première ouverture de session le dossier de départ root se trouve complété des sous-dossiers manquants (Desktop, par exemple) > d'après le patron de dossier de départ résidant at: /System/Library/User\ Template/French.lproj. Ce qui doit être le cas dans le clone à partir duquel tu opères une migration.

La solution possible pour toi alors serait la suivante :

- a) tu fais une clean install de «Sierra» dans le volume de ton nouvel iMac.

- b) tu opères une double copie (dans le volume d'une clé USB par exemple) des 2 constituants du "compte root" de la clean install par un jeu de commandes du «Terminal». Je suppose pour mes exemples que tu as nommé le volume de la clé CLE - sans accent -->

sudo cp /private/var/db/dslocal/nodes/Default/users/root.plist /Volumes/CLE
sudo cp -a /private/var/root /Volumes/CLE

- c) tu effectues ta migration d'après le clone de ton ancien iMac > ce qui édite le root.plist et le dossier de départ root.

- d) tu désactives le SIP en mode Recovery par la commande :

csrutil disable

(au cas où - même si /private/var n'est pas a priori verrouillé).

- e) tu démarres sur ton clone attaché à ton nouvel iMac. Je suppose dans mes exemples que le nom du volume de ton nouvel iMac s'intitule Macintosh HD (par défaut) --> mais il faudrait pour qu'il n'y ait pas de confusion de noms de volumes que le nom du volume de ton clone soit différent (genre iMac-clone) > tu sauvegardes par renommage le root.plist et le dossier root édités par la migration via les commandes -->

sudo mv /Volumes/Macintosh\ HD/private/var/db/dslocal/nodes/Default/users/root.plist /Volumes/Macintosh\ HD/private/var/db/dslocal/nodes/Default/users/root.plist-BACK
sudo mv /Volumes/Macintosh\ HD/private/var/root /Volumes/Macintosh\ HD/private/var/root-BACK

-f) tu recopies les originaux de la clean install recelés dans le volume CLE à leur place dans le volume de l'OS Macintosh HD via les commandes -->

sudo cp /Volumes/CLE/root.plist /Volumes/Macintosh\ HD/private/var/db/dslocal/nodes/Default/users
sudo cp -a /Volumes/CLE/root /Volumes/Macintosh\ HD/private/var

=> tu re-démarres sur le volume Macintosh HD de ton nouvel iMac et tu vérifies si tu as toujours un affichage "Récupération..." dans les fenêtres d'info du Finder. En cas d'ennuis > les ressources de la migration sont préservées (fichier root.plist-BACK & dossier root-BACK) et récupérables.

 

[r e m y]

Les grands esprits se rencontrent Maitre Maco... car j'étais justement en train d'imaginer un tel procédé pour substituer un root de souche à ce root immigré de mon ancien iMac.

Je ferai ça quand j'aurai du temps devant moi, car en ce moment j'ai mille autres tâches qui m'attendent.

Je ne manquerai pas de revenir sur ce fil, le moment venu, pour vous donner des nouvelles de la suite des evenements!

Merci à tous!

 

[r e m y]

Pour info que te renvoie un :
cat /etc/group | grep 80

voilà:
[iMac-Famille:~] famille% cat /etc/group | grep 80
admin:*:80:root

 

[FrançoisMacG]

Je pense qu'une clean install permettrait de retrouver un compte Root non affecté de cette anomalie, mais ensuite, je crains qu'une migration depuis le clone de mon ancien iMac recrée le probleme en re-migrant à nouveau le compte Root de l'ancien Mac (et dans l'assistant migration, il n'y a rien pour demander à exclure Root des utilisateurs à faire migrer).

Comme tout fonctionne normalement et que je n'ai que ce "glitch" graphique en consultant les fenêtres d'information, (les permissions sont pour autant correctes quand on les vérifie en passant par le Terminal), je vais laisser ainsi.

Comme macomaniac, je pense que c'est un fichier annexe qui empêche le compte Root d'être correctement répertorié dans les droits de ton système.
Comme toi et lui, je ne suis pas certain qu'une migration garde intact ce fichier.

Mais comme tu le dis ensuite, à quoi bon s'escrimer ?! Autant profiter de ce week-end ailleurs que devant un écran… :angelic:



@ macomaniac : ditto à la copie et/ou rsync à la restauration seraient peut-être plus pointus que cp ?
Ou faudrait-il ajouter des suffixes à ces commandes ??
= on ne sait pas où réside le problème, et ces commandes ont de ces options !