Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Mac OS Autres OS Mac OS X [El Capitan] Réparation des permissions

[El Capitan] Réparation des permissions

31 réponses
Avatar
michel.vauquois
Hello,
Juste un compte rendu d'une petite expérience concernant la réparation
des permissions d'une partition sous El Capitan.

Sur mon MBP, j'ai, entre autres, deux partitions de démarrage : l'une -
Laptop MV - avec Yosemite (à jour) et l'autre - Laptop MV2 - avec El
Capitan (installation de 10.11.3 faite sur partition vierge puis
récupération via Assistant Migration de mes données perso et
applications depuis la partition sous Yosemite).

Chacun sait maintenant que, avec El Capitan, on ne peut plus réparer les
permissions avec Utilitaire de disque.

Je démarre depuis Yosemite et je tente, avec Utilitaire de disque, une
réparation des permissions de Laptop MV2... Marche pas :
<https://www.dropbox.com/s/q3dtane1fqcchce/Ecran%202016-02-03%2013.59.37.jpg?dl=0>
Effectivement, dans /System/Library/Receipts, nulle trace de
l'installation de 10.11.3, juste
com.apple.pkg.OSX1011IncompatibleAppList.bom et
com.apple.pkg.OSX1011IncompatibleAppList.plist
mais c'est tout autre chose.

Je redémarre sur El Capitan et je lance OnyX (nul n'est parfait) et je
demande la réparation des permissions... Le ballon de plage tourne
tourne tourne et j'ai même cru qu'OnyX avait planté et soudain :
<https://www.dropbox.com/s/3t3w9m686ndywg5/Ecran%202016-02-03%2014.11.29.jpg?dl=0>

La réparation des permissions est donc basée sur toute autre chose
qu'avec les versions précédentes de OS X.

Voilà... c'était juste comme ça en passant. ;-)
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
MàJ 2015 : <http://michelvauquois.free-h.fr>
Matière à voir : <http://matiere-a-voir.michelvauquois.free-h.fr>
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
romer
M.V. wrote:

> Bien que les réparations ne soient plus d'actualité avec la 10.11.3,
> AppleJack les fait tout de même sans broncher.

Mauvaise blague de ta part...
AppleJack bronche justement :
«Unable to run because unable to use the DiskManagement framework»
mais s'il dit à la fin qu'il a fait le boulot !
Comme je le pensais, ça ne marche absolument plus avec 10.11.3.
Je n'ai pas testé les autres options de crainte de foutre la merde.
Je l'ai viré naturellement et je ne peux que conseiller à ceux qui
l'auraient sous El Capitan de le dégager...



Sur mes 2 mac avec la 10.11.3, ça fonctionne bien et je n'ai pas ce
message d'erreur.
Bref, tout cela est compliqué...

--
A+
--
Romer
Avatar
JPP
In article <1mi1zzy.10q9cwhwgykgN%,
(M.V.) wrote:

Fleuger wrote:

> J'ai exécuté comme ici :
>
<http://osxdaily.com/2015/11/04/verify-repair-permissions-mac-os-x/>

Pas plus efficace qu'OnyX !
J'ai toujours 3 fichiers soi-disant réparés qui reviennent en boucle !
Mais bon... c'était déjà le cas avant El Capitan.



ll semblerait que El Capitan utilise les ACLs.
Les ACL sont dispos sur OS X depuis 10.5 mais pas activés.

Très brèvement, les ACL (Acces Control List) ajoutent un réglage plus fin aux
permissions Read/Write/None que nous pouvons voir en bas de la fenêtre d'un Get Info
sur un fichier/dossier.
Un outil comm Sandbox permet de voir et gérer ses permisions "étendues".
BatchMod permet de gérer les permissions Posix rw0 et d'activer ou non les ACLs. Ilne
permet pa de les gérer (autriser, interdire, réserver à un utilisateur, à un groupe)

Si on demande à El Capitan de faire des transferts de ou vers un support où les ACLs
ne sont pas actifs, pas utilisés (ex.: disque formaté et n'ayant tourné que sous SL)
il active les ACLs, il "répare" automatiquement et impose les "nouvelles"
permissions sur ce support -SANS RIEN DIRE, SANS PREVENIR-SANS DEMANDER CONFIRMATION.

Une fois qu'il a été utilisé par el Capitan, si on utilise ce même support sous un OS
plus ancien (ex.: SL) celui-ci voitet applique les permissions supplémentaires
instituées par les ACLs de Capitan.
Expériementé sous SL :
El Capitan sur un disque externe a échangé des fichiers avec le disque interne,
disque de boot SL.
Booté en SL sur ce disque interne:
- Poubelliser un fichier demande un mdp admin de même que d'autes actions.
- déplacer un fichier est remplacé par dupliquer le fichier
Le comportement est analogue a celui d'un partage où le destianataire a des droits
restreints sur le fichier qu'il a reçu.

Sous SL:
Ce changement de permissions interdit la modification des prefs. Ex.: changer
l'affichage de Date/Heure. On n'est prévenu de rien mais pas de changement.

sous SL, les calendriers de iCal sont pollués, inutilisables. Des évènements se
dupiquent de façon totalemeny aléatoire. S'ils activent des alertes lail, par
exemple, la boite mail est inondée d'alertes ...

Que El Capitan utilise les ACLs est en soi une bonne chose, sauf qu'il ne devrait pas
pouvoir le faire sur un suport annexe non préparé pour cela SANS AVERTIR et demander
CONFIRMATION vu que la réparation automatique peu détruire des données.
Avatar
c.d
M.V. wrote:

Bernd wrote:


[...]
Ça, ça m'étonne... Les commandes à lancer dans le Terminal sous El
Capitan n'ont tellement plus rien à voir avec celles que l'on utilisait
sous les OS X précédents :
sudo /usr/libexec/repair_packages --repair --standard-pkgs /


Ben j'ai essayé avec
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
et ça répare bien : résultat User differs on "private/var/db/displaypolicyd", should be 0, user is
244.
Group differs on "private/var/db/displaypolicyd", should be 0,
group is 244.
Repaired "private/var/db/displaypolicyd".
ACL found but not expected on 'private/var/root/Library'.
Repaired "private/var/root/Library".
ACL found but not expected on
'private/var/root/Library/Preferences'.
Repaired "private/var/root/Library/Preferences".
Avatar
michel.vauquois
Christian wrote:

Ben j'ai essayé avec
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
et ça répare bien : résultat


Aurais-je dit (ou aurais-tu compris) le contraire ?

--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
MàJ 2015 : <http://michelvauquois.free-h.fr>
Matière à voir : <http://matiere-a-voir.michelvauquois.free-h.fr>
Avatar
c.d
M.V. wrote:

Christian wrote:

> Ben j'ai essayé avec
> sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
> et ça répare bien : résultat >
Aurais-je dit (ou aurais-tu compris) le contraire ?


J'ai compris le contraire :(
Avatar
michel.vauquois
Bernd wrote:

Sur mes 2 mac avec la 10.11.3, ça fonctionne bien et je n'ai pas ce
message d'erreur.



Tu peux photographier l'écran ? Je ne te cache pas que j'ai des sérieux
doutes sur ce que tu dis...
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
MàJ 2015 : <http://michelvauquois.free-h.fr>
Matière à voir : <http://matiere-a-voir.michelvauquois.free-h.fr>
Avatar
michel.vauquois
JPP wrote:

Si on demande à El Capitan de faire des transferts de ou vers un support
où les ACLs ne sont pas actifs, pas utilisés (ex.: disque formaté et
n'ayant tourné que sous SL) il active les ACLs, il "répare"
automatiquement et impose les "nouvelles" permissions sur ce support
-SANS RIEN DIRE, SANS PREVENIR-SANS DEMANDER CONFIRMATION.

Une fois qu'il a été utilisé par el Capitan, si on utilise ce même support
sous un OS plus ancien (ex.: SL) celui-ci voitet applique les permissions
supplémentaires instituées par les ACLs de Capitan. Expériementé sous SL :
El Capitan sur un disque externe a échangé des fichiers avec le disque
interne, disque de boot SL.
Booté en SL sur ce disque interne:
- Poubelliser un fichier demande un mdp admin de même que d'autes actions.
- déplacer un fichier est remplacé par dupliquer le fichier
Le comportement est analogue a celui d'un partage où le destianataire a
des droits restreints sur le fichier qu'il a reçu.

Sous SL:
Ce changement de permissions interdit la modification des prefs. Ex.:
changer l'affichage de Date/Heure. On n'est prévenu de rien mais pas de
changement.

sous SL, les calendriers de iCal sont pollués, inutilisables. Des
évènements se dupiquent de façon totalemeny aléatoire. S'ils activent des
alertes lail, par exemple, la boite mail est inondée d'alertes ...

Que El Capitan utilise les ACLs est en soi une bonne chose, sauf qu'il ne
devrait pas pouvoir le faire sur un suport annexe non préparé pour cela
SANS AVERTIR et demander CONFIRMATION vu que la réparation automatique peu
détruire des données.



Ici, c'est différent : disque SSL externe avec El Capitan et disque
externe traditionnel avec SL.
Je ne note rien de ce que tu dis...
Je suis perplexe.
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
MàJ 2015 : <http://michelvauquois.free-h.fr>
Matière à voir : <http://matiere-a-voir.michelvauquois.free-h.fr>
Avatar
J.P
In article <1mi5trp.1blpvlz1swdmj2N%,
(M.V.) wrote:


Ici, c'est différent : disque SSL externe avec El Capitan et disque
externe traditionnel avec SL.
Je ne note rien de ce que tu dis...
Je suis perplexe.



Fais des transferts entre les disques et redémarre sous SL
Par ailleurs fais un ls -l pour voir si tu as le signe <+>
Peut-être aussi que Capitan ne répare pas en permanence mais seulement
dans des conditions précises.
Ceci dit, depuis que Batchmod a inactivé les <extended permissions> sur
mon disque SL ça va bien mieux.

--
Jean-Pierre
Avatar
J.P
In article <1mi5qg7.pzl0jd1cyjl8aN%,
(Christian) wrote:

M.V. wrote:

> Bernd wrote:
[...]
> Ça, ça m'étonne... Les commandes à lancer dans le Terminal sous El
> Capitan n'ont tellement plus rien à voir avec celles que l'on utilisait
> sous les OS X précédents :
> sudo /usr/libexec/repair_packages --repair --standard-pkgs /
Ben j'ai essayé avec
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
et ça répare bien : résultat > User differs on "private/var/db/displaypolicyd", should be 0, user is
244.
Group differs on "private/var/db/displaypolicyd", should be 0,
group is 244.
Repaired "private/var/db/displaypolicyd".
ACL found but not expected on 'private/var/root/Library'.



El Capitan utilise donc bien les ACLs.
S'il "répare" un disque destiné à booter et être utilisé sous SL ; que
se passe-t-il ?

--
Jean-Pierre
Avatar
michel.vauquois
J.P wrote:

Fais des transferts entre les disques et redémarre sous SL



Je l'avais fait, naturellement, puisque c'était précisé dans la
contribution de JPP.

Par ailleurs fais un ls -l pour voir si tu as le signe <+>



En ayant démarré sur El Capitan ou sur SL ?
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
MàJ 2015 : <http://michelvauquois.free-h.fr>
Matière à voir : <http://matiere-a-voir.michelvauquois.free-h.fr>
1 2 3 4