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

[r e m y]

Je suis passé à Sierra récemment (avec l'arrivée d'un nouvel iMac 27").

Tout se passe bien mais je note un affichage curieux dans les fenêtres d'information des fichiers ou dossiers.

Dans Partage et Permissions, là où devrait apparaitre "Système", il est mentionné, en grisé, "Récupération...".

C'est le cas sur TOUS les fichiers et dossiers, voire sur la racine du disque dur ou sur les dossiers /System, /Library...

Pour autant je ne note aucune anomalie de fonctionnement ou de blocages particuliers.

Les autorisations pour le dossier /Utilitaires par exemple, sont les suivantes:
[iMac-Famille:~] famille% ls -dale /Applications/Utilities
drwxr-xr-x+ 57 root admin 1938 22 déc 18:50 /Applications/Utilities
0: group:everyone deny delete

Est-ce "normal"?
Y a-t-il quelque chose à vérifier?
Dois-je faire quelque chose pour restaurer l'affichage habituel dans les fenêtres d'info à la place de ce "Récupération"?

 

[Membre supprimé 1060554]

Attention : facéties de fin d'année !
​

Je suis passé à Sierra récemment (avec l'arrivée d'un nouvel iMac 27").

Tout se passe bien mais je note un affichage curieux dans les fenêtres d'information des fichiers ou dossiers.

Ce message de r e m y n'a trouvé aucun interlocuteur - posté qu'il était une veille de Noël où l'on préfère déboucher des flacons de spiritueux à domicile que repêcher des bouteilles dans la mer des forums...

Mais voici qu'après coup il offre un document savoureux à l'amateur de « méta-psychologie ». r e m y (je le sais) est un récidiviste des permissions dévoyées --> en Juillet dernier déjà, il faisait état d'un tel problème dans l'OS «Yosemite» : ☞Permissions des dossiers Applications et Utilitaires☜. Il semble, par ailleurs, que l'OS «Sierra» induise un « effet de complexité » (ou de perplexité ?) sur son entendement --> ☞Gérer le stockage icloud et mac☜ & ☞L'Utilitaire disque Sierra est-il buggué?☜. Mais voici désormais que ces 2 motifs en viennent à se combiner en un problème composite de permissions dévoyées dans l'OS «Sierra» - ce que noux pourrions appeler un « complexe » [psycho]logique

il est mentionné, en grisé, "Récupération..."... Pour autant je ne note aucune anomalie de fonctionnement ou de blocages particuliers. Les autorisations pour le dossier /Utilitaires par exemple, sont les suivantes:
[iMac-Famille:~] famille% ls -dale /Applications/Utilities
drwxr-xr-x root admin /Applications/Utilities
0: group:everyone deny delete

Est-ce "normal"?

En cette période de Fêtes > il doit être normal que l'utilisateur root ait besoin d'une petite « récupération » - non ? (aurais-je bien envie de glisser facétieusement)

Plus sérieusement : quand tu dis que tu es « passé à Sierra » avec l'arrivée d'un nouvel iMac --> est-ce que tu veux dire que «Sierra» était installé d'usine sur le disque du Mac (ou en clean install par tes soins) > et tu as opéré ensuite la « récupération » d'une sauvegarde par l'«Assistant de Migration» ?

Si tel est le cas > il semble que tu aies un petit problème d'affichage graphique (en mode Finder) de l'actuel user = root (System Administrator) bien inscrit pourtant sur l'arborescence des répertoires-Système.

Je n'ai pas de représentation claire & distincte (avouerai-je) de ce qui peut produire cette déformation de la présentation graphique. Il serait bien sûr possible d'appeler dans le «Terminal» en mode récursif l'utilitaire chown (change_owner) > avec le seul user root comme option (sans mention du groupe principal) > et en objets-cibles autant de répertoires-Système glissés-déposés à propos desquels tu as constaté un problème d'affichage graphique des permissions --> genre : taper la séquence initiale :

sudo chown -R 0

[0 = l'identifiant de root en valeur octale] > sauter un espace > puis glisser-déposer des répertoires incriminés les uns après les autres (un espace se créant automatiquement après chaque glisser-déposer créateur d'une adresse)...

Mais ce genre de rectification à la mimine risquerait d'oublier des répertoires frappés d'invisibibilité graphique (genre : /private etc.) > mais bien plus de buter sur des répertoires in-modifiables en écriture (de droits ici) dès lors que le SIP est activé (genre : /System > /usr etc.) - voire même de ne rien changer du tout à la donne (s'il est vrai que root est déjà inscrit comme user sur l'arborescence des répertoires en question - sans que cela ne s'exprime dans la présentation graphique des permissions).

=> en résumé : je serais toi > je démarrerais en mode Recovery OS par ⌘R > et je choisirais l'option : "Ré-installer macOS" à destination du volume Macintosh HD. Et tant pis si l'anomalie graphique constatée ne trouve pas d'explication suffisante...

 

[r e m y]

C'est bien un Sierra installé d'usine sur lequel ont été récupérés mes anciens "users" via l'assistant migration lors du premier allumage.

En fait tous les dossiers et fichiers installés d'usine présentent cette particularité d'affichage dans la fenêtre d'informations.

Les dossiers récupérés de mon ancien Mac ont un affichage normal des permissions.

N'ayant noté aucune anomalie de fonctionnement, je suis convaincu que ce n'est qu'un problème d'affichage.

Je pense effectivement refaire une installation du système par dessus celui installé d'usine.

 

[Deleted member 1099514]

Salut

Perso j'aurai tenté une réindexation avant :
sudo mdutil -E /

 

[r e m y]

Tu penses que Spotlight pourrait être la cause de cet affichage curieux??

 

[Deleted member 1099514]

C'est le fait que tu penses à une erreur d'affichage qui me fait penser à ça. Mais sans certitude.

 

[bompi]

Tu penses que Spotlight pourrait être la cause de cet affichage curieux??

Il faudrait que le Finder appelle Spotlight pour la simple lecture des droits de fichiers et ce n'est pas le rôle de Spotlight. Les droits sur les fichiers sont conservés dans le système de fichiers ; les indications nominatives sont, elles, conservées dans l'annuaire : je verrais plutôt cette anomalie d'un côté (FS) ou de l'autre (directory service).

J'ai vérifié sur mon MBA, passé à Sierra par mise à jour de El Capitan, et je n'ai pas cette anomalie, ni en anglais ni en français (on ne sait jamais). Ça donne quoi, en anglais, sur ta machine ?

 

[r e m y]

l'anomalie de la fenêtre d'info est présente sur tous les fichiers et dossiers pré-installés d'usine...

Par exemple le disque dur (et en étant passé en anglais):

Quand j'aurai un peu de temps je réinstallerai le système par dessus celui pré-installé...
(pas d'urgence car je n'ai noté aucune anomalie de fonctionnement et en passant par le Terminal, ces fichiers et dossiers ont bien les bonnes permissions)

 

[r e m y]

Pour ce qui est de l'Utilitaire d'annuaire, je ne vois rien d'anormal pour Root

 

[r e m y]

Quoi qu'il en soit, l'idée de Bompi de passer en anglais m'a permis de trouver les bons critères de recherche pour Google.

En tapant "macos sharing & permissions fetching" dans Google, on trouve des infos sur cet affichage "fetching".

Je n'ai pas encore tout lu, mais c'est visiblement un probleme de lien entre user et group ...

Par contr la plupart des liens trouvés évoquent ce probleme plutôt sur des dossiers home migrés depuis un autre Mac (surtout si migré depuis SnowLeopard), or chez moi, ce sont les dossiers d'origine qui semblent poser problème.

 

[bompi]

Juste pour une petite précision ; peux-tu nous afficher ce que te retourne la commande suivante :

ls -dn /Applications/Utilities

 

[Membre supprimé 1060554]

Petite contribution guère technique.

Le verbe Anglais « Fetching... », au participe présent, inscrit dans la colonne "Name" d'une fenêtre d'informations du Finder à l'entrée : Partage & permissions --> doit se laisser traduire par : « en train de chercher à récupérer le nom de l'utilisateur ». Ce détour par l'Anglais clarifiant le sens de l'affichage Finder en Français : « Récupération... » --> « processus en cours de récupération du nom de l'utilisateur ».

Il ne s'agit donc absolument pas d'un problème de nom de l'utilisateur intrinsèquement inscrit sur les objets (dossiers & fichiers) de l'OS > le retour d'une commande ls avérant qu'il s'agit bien de l'utilisateur root (comme attendu). Il s'agit d'un problème de « récupération de ce nom à fin d'affichage graphique dans une fenêtre d'information du Finder ».

----------

c'est visiblement un probleme de lien entre user et group

Régulièrement, le groupe wheel (ou "Groupe-Système") ne comporte qu'un seul et unique membre = root (à moins de customisation ayant promu un admin membre collatéral de root dans le groupe wheel - comme par exemple je le fais personnellement en ma faveur par pure perversité). Il ne paraît donc pas qu'il puisse exister la moindre ambiguïté concernant les relations root & wheel > root étant le seul participant par défaut de wheel.

Tu peux toujours, r e m y, passer dans le «Terminal» la commande (simplement informative) :

dscacheutil -q group -a name wheel

qui va te retourner un court tableau avec une entrée finale "users" listant les participants actuels de wheel > ça m'étonnerait que soit listé un autre membre que root.

S'il en est ainsi > je vois mal en quoi « récupérer en vue d'affichage graphique le nom de l'user » d'un objet sur lequel on a fait un ⌘I impliquerait comme condition logique de vérifier s'il est aussi membre du groupe principal associé à l'objet - mais sait-on jamais ?

----------

Alternative : s'agit-il d'un problème de récupération du nom de l'user (= root) inhérent au compte de l'utilisateur dont la session est actuellement ouverte (l'utilisateur collectif : famille) ? Ou bien le problème de récupération du nom de l'user root se manifeste-t-il quelque soit l'utilisateur dont la session est ouverte ?

- si tu crées un autre utilisateur (admin ou staff) > ouvres sa session > ouvres une fenêtre d'information sur un objet-Système > est-ce que tu vois affiché : système (nom Finder de root) ou toujours Récupération... ? Tu peux même te payer le luxe d'ouvrir une session graphique root pour vérifier.​

=> selon que le problème n'existe que dans la session famille ou est général (pour tous utilisateurs) > le champ d'investigation se placerait dans un compte ou dans le Système.

 

[r e m y]

Je ferai ces différents tests ce soir en rentrant à la maison (j'ai du mal à transporter ce 27" avec moi....) mais je peux deja confirmer que ce "récupération" ou "fetching" apparaît quelle que soit la session utilisateur (la copie d'écran de la fenetre d'infos en anglais, c'est dans une session Root que je l'ai réalisée...)

 

[r e m y]

Pour ce qui est de l'Utilitaire d'annuaire, je ne vois rien d'anormal pour Root

Au fait... le nom "System Administrator" pour Root, est bien le bon?
Il ne devrait pas s'appeler juste "system" ?
Ou bien system est-il le nom abrégé de system administrator, mais dans ce cas, ce nom abrégé ne devrait-il pas être précisé dans l'utilitaire d'annuaire?

 

[Membre supprimé 1060554]

Si le problème d'affichage est général > on peut conjecturer que le problème relève de l'Open Directory ou Service d'Annuaire du Système. L'ennui avec ledit Open Directory > est que son fonctionnement est carrément ésotérique > et ce n'est pas le logiciel «Utilitaire d'Annuaire» destiné à l'utilisateur qui va clarifier le fonctionnement d'arrière-plan de ce service.

Mais ce que je sais est que : la Base de Données de l'Open Directory est localisée at: /private/var/db/dslocal/nodes/Default - dossier Default graphiquement verrouillé incluant (notamment) les sous-dossiers groups & users. Le sous-dossier users est la base de données des utilisateurs pour l'Open Directory et contient autant de fichiers .plist que d'utilisateurs (réels ou assimilés). Il y a donc un fichier root.plist qui est la Carte d'Identité de l'utilisateur root dans l'OS.

Par la commande :

sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist

tu vas récupérer un affichage du plist de l'utilisateur root. La majeure partie en est inscrutable > mais tout à la fin > tu récupères un pied de fichier lisible que tu pourrais poster ici.

Une conjecture serait que le fichier Carte d'Identité de root soit partiellement corrompu > ce qui causerait un problème de « récupération du Nom Propre de l'utilisateur dont le nom court est root » > mais ce n'est là qu'une conjecture de ma part.

=> si tel était le cas > il n'y aurait qu'une restauration totale du Système pour régler le problème d'affichage graphique.

 

[r e m y]

Je regarderai ça ce soir.... mais uniquement par souci de comprendre l'origine de ce petit bug, car je suis convaincu que la solution passera par une reinstallation du Systeme (de memoire, j'ai toujours dû réinstaller le systeme par dessus celui pré installé par Apple sur chaque Mac que j'aie eu)

Cela dit, si le problème réside dans une corruption de la carte d'identité de Root, c'est peut être la migration de mon ancien iMac qui en est la cause.
Root étant activé sur l'ancien iMac, peut-être le processus de migration a-t-il mis à jour cette carte d'identité, ne serait-ce que pour y recopier le mot de passe que je lui avais attribué, causant la corruption...

 

[bompi]

Dans un shell, pour lire le contenu de l'annuaire (et le modifier, aussi), on utilise la commande dscl.

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

renvoie :

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

Ici, le principe est de donner la source (localhost), l'action (-read), le chemin vers l'objet qui nous intéresse (/Local/Default/Users/root) et les clefs que l'on souhaite lire (RealName RecordName UniqueID _writers_realname).
Cela répond au passage à ta question en #14.

La dernière clef (_writers_realname) n'est visiblement définie que pour les utilisateurs créés après l'initialisation du système.

 

[bompi]

Par ailleurs, la commande dscl peut se révéler pratique en mode interactif (on la lance sans paramètres).
On se balade dans l'arborescence de l'annuaire avec la commande cd, comme pour le shell.

Ce qui ne l'est pas, pratique, ce sont les éléments de type binaire, comme les avatars, qui prennent beaucoup de place et font se dérouler l'affichage (exemple : JPEGPhoto). D'où l'intérêt de cibler les clefs que l'on veut lire.

 

[r e m y]

Juste pour une petite précision ; peux-tu nous afficher ce que te retourne la commande suivante :

ls -dn /Applications/Utilities

[iMac-Famille:~] famille% ls -dn /Applications/Utilities

drwxr-xr-x+ 56 0 80 1904 24 déc 12:11 /Applications/Utilities

 

[r e m y]

Régulièrement, le groupe wheel (ou "Groupe-Système") ne comporte qu'un seul et unique membre = root (à moins de customisation ayant promu un admin membre collatéral de root dans le groupe wheel - comme par exemple je le fais personnellement en ma faveur par pure perversité). Il ne paraît donc pas qu'il puisse exister la moindre ambiguïté concernant les relations root & wheel > root étant le seul participant par défaut de wheel.

Tu peux toujours, r e m y, passer dans le «Terminal» la commande (simplement informative) : dscacheutil -q group -a name wheel
qui va te retourner un court tableau avec une entrée finale "users" listant les participants actuels de wheel > ça m'étonnerait que soit listé un autre membre que root.

[iMac-Famille:~] famille% dscacheutil -q group -a name wheel
name: wheel
password: *
gid: 0
users: root