Bonjour, suite a une mauvaise manipulation j'ai accidentellement interdit les droits d'écriture et de lecture de tous les utilisateurs du coup mon mac s'est bloqué et je ne pouvais plus rien faire. J'ai redémarré, la pomme est bien apparu mais après l'écran est resté noir, j'ai beau redémarrer mais rien y fait. Auriez-vous une solution svp ? Merci bcp de votre aide.
Mac mini Utilisateur interdit en lecture/écriture
- Créateur du sujet math87
- Date de début
D
Deleted member 1099514
Invité
Salut, en faisant clic droit sur l'icone du disque interne puis "lire les informations" et en modifiant les paramètres de permissions qu'il y a plus bas dans la fenêtre, j'ai au préalable déverrouillé le cadenas. C'est du osx 10.9.5, si il s'agit bien de la version sinon je ne saurai pas dire.. Merci de votre aide.
D
Deleted member 1099514
Invité
Pas très cool.
Tente de démarrer en mode Recovery (cmd+r lors du boot) puis tu ouvres l'utilitaire de disques et tu sélectionnes la partition système (en général Macintosh HD) puis tu fais "Réparer les autorisations".
Si ça ne suffit pas, tu redémarres en mode Recovery, tu ouvres un terminal (Menu/Utilitaires/Terminal) et là tu donnes le retour de la commande :
ls -l /Volumes/*/Users
Tente de démarrer en mode Recovery (cmd+r lors du boot) puis tu ouvres l'utilitaire de disques et tu sélectionnes la partition système (en général Macintosh HD) puis tu fais "Réparer les autorisations".
Si ça ne suffit pas, tu redémarres en mode Recovery, tu ouvres un terminal (Menu/Utilitaires/Terminal) et là tu donnes le retour de la commande :
ls -l /Volumes/*/Users
M
Membre supprimé 1060554
Invité
Salut math
Voici la solution si tu n'as pas étendu récursivement cette interdiction d'accès du everyone :
Voici la solution si tu n'as pas étendu récursivement cette interdiction d'accès du everyone :
- a) tu démarres ton Mac avec ⌘R en mode Recovery.
- b) tu négliges la fenêtre des 4 Utilitaires OS X > pour aller à la barre de menus supérieure de l'écran > menu Utilitaires > pour lancer le «Terminal» > une fenêtre s'ouvre avec une invite de commande -bash-3.2#.
- c) tu saisis la commande :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour, tu vois s'afficher la liste des volumes montés dont celui de ton OS. Le nom est Macintosh HD par défaut > mais tu pourrais l'avoir renommé. Cette commande a juste pour fonction de te mettre sous les yeux le nom actuel de ton volume-Système.
- d) tu saisis alors la commande :
et ↩︎ en respectant les 2 espaces libres entre chmod et 755 et entre 755 et /Volumes/"Macintosh HD". Si le nom de ton volume est bien Macintosh HD > mets entre "" cet intitulé ainsi : "Macintosh HD" pour neutraliser l'espace libre central. Sinon, remplace mon Macintosh HD par le nom dont tu as renommé ton volume, et par prudence, mets-le entre "". Si c'était : le Mac de Michu > "le Mac de Michu".
=> cela fait > tu quittes le «Terminal» par ⌘Q > tu vas au Menu > tu choisis l'option "Redémarrer" et... ton Mac démarre jusqu'à l'ouverture de ta session.
[J'en parle d'expérience puisque je viens d'infliger au volume de mon OS la même interdiction d'accès du everyone que toi > plantage au re-démarrage > déplantage après la commande ad hoc dans le «Terminal» de la Recovery.]
Jean
Cette déclaration de math :
combinée à celle de son premier message :
montre que la modification des permissions n'a pas été faite sur le répertoire des /Users > mais sur le répertoire du volume-Système complet /. Il y a des chances qu'elle n'ait pas été étendue récursivement.
Le terme : "tous les utilisateurs" doit alors se comprendre, relativement au volume-Système, comme le secondary_group everyone ("n'importe quel utilisateur").
Il doit s'agir du basculement des permissions de ce groupe, de 5 (r-w) à 0 (---) donnant un 750 actuellement sur le volume-Système global > par suite un re-basculement de 0 (---) à 5 (r-w) par un 755 sur le même volume-Système global doit régler le problème en restaurant l'état originel des permissions, comme ça a été le cas pour moi dans mon expérimentation.]
- b) tu négliges la fenêtre des 4 Utilitaires OS X > pour aller à la barre de menus supérieure de l'écran > menu Utilitaires > pour lancer le «Terminal» > une fenêtre s'ouvre avec une invite de commande -bash-3.2#.
- c) tu saisis la commande :
Bloc de code:
ls /Volumes- d) tu saisis alors la commande :
Bloc de code:
chmod 755 /Volumes/"Macintosh HD"=> cela fait > tu quittes le «Terminal» par ⌘Q > tu vas au Menu > tu choisis l'option "Redémarrer" et... ton Mac démarre jusqu'à l'ouverture de ta session.
[J'en parle d'expérience puisque je viens d'infliger au volume de mon OS la même interdiction d'accès du everyone que toi > plantage au re-démarrage > déplantage après la commande ad hoc dans le «Terminal» de la Recovery.]
JeanCette déclaration de math :
combinée à celle de son premier message :
montre que la modification des permissions n'a pas été faite sur le répertoire des /Users > mais sur le répertoire du volume-Système complet /. Il y a des chances qu'elle n'ait pas été étendue récursivement.
Le terme : "tous les utilisateurs" doit alors se comprendre, relativement au volume-Système, comme le secondary_group everyone ("n'importe quel utilisateur").
Il doit s'agir du basculement des permissions de ce groupe, de 5 (r-w) à 0 (---) donnant un 750 actuellement sur le volume-Système global > par suite un re-basculement de 0 (---) à 5 (r-w) par un 755 sur le même volume-Système global doit régler le problème en restaurant l'état originel des permissions, comme ça a été le cas pour moi dans mon expérimentation.]
Dernière édition par un modérateur:
La réparation des autorisations n'a pas suffit et je n'ai aucun retour sur la commande juste une flèche qui pointe vers la droite.
Salut math
Voici la solution si tu n'as pas étendu récursivement cette interdiction d'accès du everyone :
- a) tu démarres ton Mac avec ⌘R en mode Recovery.
- b) tu négliges la fenêtre des 4 Utilitaires OS X > pour aller à la barre de menus supérieure de l'écran > menu Utilitaires > pour lancer le «Terminal» > une fenêtre s'ouvre avec une invite de commande -bash-3.2#.
- c) tu saisis la commande :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour, tu vois s'afficher la liste des volumes montés dont celui de ton OS. Le nom est Macintosh HD par défaut > mais tu pourrais l'avoir renommé. Cette commande a juste pour fonction de te mettre sous les yeux le nom actuel de ton volume-Système.Bloc de code:ls /Volumes
- d) tu saisis alors la commande :
et ↩︎ en respectant les 2 espaces libres entre chmod et 755 et entre 755 et /Volumes/"Macintosh HD". Si le nom de ton volume est bien Macintosh HD > mets entre "" cet intitulé ainsi : "Macintosh HD" pour neutraliser l'espace libre central. Sinon, remplace mon Macintosh HD par le nom dont tu as renommé ton volume, et par prudence, mets-le entre "". Si c'était : le Mac de Michu > "le Mac de Michu".Bloc de code:chmod 755 /Volumes/"Macintosh HD"
=> cela fait > tu quittes le «Terminal» par ⌘Q > tu vas au Menu > tu choisis l'option "Redémarrer" et... ton Mac démarre jusqu'à l'ouverture de ta session.
[J'en parle d'expérience puisque je viens d'infliger au volume de mon OS la même interdiction d'accès du everyone que toi > plantage au re-démarrage > déplantage après la commande ad hoc dans le «Terminal» de la Recovery.]
Cette déclaration de math :
combinée à celle de son premier message :
montre que la modification des permissions n'a pas été faite sur le répertoire des /Users > mais sur le répertoire du volume-Système complet /. Il y a des chances qu'elle n'ait pas été étendue récursivement.
Le terme : "tous les utilisateurs" doit alors se comprendre, relativement au volume-Système, comme le secondary_group everyone ("n'importe quel utilisateur").
Il doit s'agir du basculement des permissions de ce groupe, de 5 (r-w) à 0 (---) donnant un 750 actuellement sur le volume-Système global > par suite un re-basculement de 0 (---) à 5 (r-w) par un 755 sur le même volume-Système global doit régler le problème en restaurant l'état originel des permissions, comme ça a été le cas pour moi dans mon expérimentation.]
Merci infiniment @macomaniac !! Ça a marché !!!!
D
Deleted member 1099514
Invité
M
Membre supprimé 1060554
Invité
Ne te réjouis pas trop vite, math, car tu tombes sur un facétieux bateleur (le nommé macomaniac) que rien n'amuse plus, le dimanche, que d'exercer sa rhétorique oiseuse autant qu'oisive
Il se trouve que ton cas de figure (virer sur le volume-Système les permissions de everyone à "accès interdit" > induisant un plantage du démarrage logique du Mac) - cas de figure qui a eu nombre de précurseurs sur les forums - a toujours piqué ma curiosité.
Alors voici un petit exercice d'herméneutique à ce sujet.
Réglementairement > l'état de choses est le suivant sur le volume-Système de l'OS :
Comme tu le vois >
=> donc en opérant dans une fenêtre d'information du Finder ouverte sur ce répertoire du volume de ton OS > tu as opéré une modification des permissions concernant le troisième accédant : le secondary group everyone > en sélectionnant l'option graphique disponible : accès interdit => ce qui signifie que tu as transformé les permissions r-x (= 5) de ce groupe en --- (ni lecture, ni écriture, ni exécution de l'entrée au répertoire) càd. encore 0 en valeur octale. Les permissions sur le répertoire global du volume-Système sont donc --> drwxr-x--- soit 750 root wheel everyone.
Permets-moi à partir de là un exercice spéculatif tendant éclairer la « raison des effets ».
Le raisonnement sous-jacent à ton geste n'avait rien d'aberrant à la base : en effet, tu t'es dit que les 3 accédants répertoriés (système [root] > wheel > everyone) étaient des entités séparées > donc interdire tout accès aux répertoires du volume de l'OS au groupe des « n'importe qui » > laissait intactes les permissions d'accès pour les 2 autres : root et wheel .
Mais c'est là que tu as commis une erreur logique > parce que les 3 accédants répertoriés ne sont pas des entités cloisonnées comme tu l'as imaginé (3 billes dans un sac). En effet root (système) non seulement est identique à lui-même > mais fait partie (seul par défaut) du groupe wheel > et encore fait partie du groupe everyone. Et en ce qui concerne wheel > il fait a priori partie aussi du groupe de everyone. On a donc affaire à un emboîtage de l'ordre des ensembles > pas à une coexistence d'objets discrets.
Quelle est alors la conséquence, d'un point de vue emboîtage ensembliste ? C'est qu'une contradiction logique de permissions est générée, telle que si root et wheel gardent, in se et per se, la permission d'exécuter l'entrée au répertoire du Volume-Système et de lire ses contenus (et pour root d'y écrire) > en tant que membres simultanément du groupe des everyone ils sont interdits d'exécution de l'entrée au répertoire et de lecture de ses contenus.
Cette contradiction logique > a la conséquence suivante du point de vue du boot du Mac (ici je revendique le droit spéculatif à l'erreur de détail - car mon entendement n'est pas loggé par défaut dans le Système et avisé par là du moindre acte logique) =>
Il se trouve que ton cas de figure (virer sur le volume-Système les permissions de everyone à "accès interdit" > induisant un plantage du démarrage logique du Mac) - cas de figure qui a eu nombre de précurseurs sur les forums - a toujours piqué ma curiosité.
Alors voici un petit exercice d'herméneutique à ce sujet.
Réglementairement > l'état de choses est le suivant sur le volume-Système de l'OS :
Bloc de code:
drwxr-xr-x root wheel /- le d initial (abrégé de directory) désigne la nature de l'objet : un dossier (un volume ayant la nature d'un espace de répertoire)
- la première triplette correspond aux permissions du premier accédant, l'user (= root : le System Administrator) = rwx (read + write + execute --> lecture + écriture + exécution de l'entrée au répertoire) ou 7 en valeur octale.
- la deuxième triplette correspond aux permissions du deuxième accédant, le primary group (= wheel : le groupe à privilèges Système) = r-x (read + write + execute --> lecture + pas d'écriture + exécution de l'entrée au répertoire) ou 5 en valeur octale.
- la troisème triplette correspond aux permissions du troisème accédant, le secondary group (= everyone : le groupe de tous les utilisateurs quels qu'ils soient) = r-x (read + write + execute --> lecture + pas d'écriture + exécution de l'entrée au répertoire) ou 5 en valeur octale.
- la première triplette correspond aux permissions du premier accédant, l'user (= root : le System Administrator) = rwx (read + write + execute --> lecture + écriture + exécution de l'entrée au répertoire) ou 7 en valeur octale.
- la deuxième triplette correspond aux permissions du deuxième accédant, le primary group (= wheel : le groupe à privilèges Système) = r-x (read + write + execute --> lecture + pas d'écriture + exécution de l'entrée au répertoire) ou 5 en valeur octale.
- la troisème triplette correspond aux permissions du troisème accédant, le secondary group (= everyone : le groupe de tous les utilisateurs quels qu'ils soient) = r-x (read + write + execute --> lecture + pas d'écriture + exécution de l'entrée au répertoire) ou 5 en valeur octale.
=> donc en opérant dans une fenêtre d'information du Finder ouverte sur ce répertoire du volume de ton OS > tu as opéré une modification des permissions concernant le troisième accédant : le secondary group everyone > en sélectionnant l'option graphique disponible : accès interdit => ce qui signifie que tu as transformé les permissions r-x (= 5) de ce groupe en --- (ni lecture, ni écriture, ni exécution de l'entrée au répertoire) càd. encore 0 en valeur octale. Les permissions sur le répertoire global du volume-Système sont donc --> drwxr-x--- soit 750 root wheel everyone.
--------------------
Permets-moi à partir de là un exercice spéculatif tendant éclairer la « raison des effets ».
Le raisonnement sous-jacent à ton geste n'avait rien d'aberrant à la base : en effet, tu t'es dit que les 3 accédants répertoriés (système [root] > wheel > everyone) étaient des entités séparées > donc interdire tout accès aux répertoires du volume de l'OS au groupe des « n'importe qui » > laissait intactes les permissions d'accès pour les 2 autres : root et wheel .
Mais c'est là que tu as commis une erreur logique > parce que les 3 accédants répertoriés ne sont pas des entités cloisonnées comme tu l'as imaginé (3 billes dans un sac). En effet root (système) non seulement est identique à lui-même > mais fait partie (seul par défaut) du groupe wheel > et encore fait partie du groupe everyone. Et en ce qui concerne wheel > il fait a priori partie aussi du groupe de everyone. On a donc affaire à un emboîtage de l'ordre des ensembles > pas à une coexistence d'objets discrets.
Quelle est alors la conséquence, d'un point de vue emboîtage ensembliste ? C'est qu'une contradiction logique de permissions est générée, telle que si root et wheel gardent, in se et per se, la permission d'exécuter l'entrée au répertoire du Volume-Système et de lire ses contenus (et pour root d'y écrire) > en tant que membres simultanément du groupe des everyone ils sont interdits d'exécution de l'entrée au répertoire et de lecture de ses contenus.
Cette contradiction logique > a la conséquence suivante du point de vue du boot du Mac (ici je revendique le droit spéculatif à l'erreur de détail - car mon entendement n'est pas loggé par défaut dans le Système et avisé par là du moindre acte logique) =>
- cela n'empêche en rien, quand tu appuies sur le bouton "Power" du Mac, l'EFI (le Programme Interne du Mac) d'exécuter le pré-boot > puis d'aller exécuter le boot_loader : boot.efi (at: /System/Library/CoreService/boot.efi ) qui est le fichier démarreur du Système Logique - car (me le figuré-je) le processus de l'EFI est un processus précurseur des utilisateurs et donc possédant un passe-droit à l'arborescence du volume indifférent aux permissions d'utilisateurs fixées sur son répertoire parent.
- je présume aussi que le boot_loader boot.efi, en tant qu'il exécute aussi un processus précurseur de tout utilisateur (en qualité d'application immédiate de l'EFI) posséde également un passe-droit à l'arborescence du volume indifférent aux permissions d'utilisateurs fixées sur son répertoire parent qui ne concernent que des processus d'utilisateurs > il peut donc charger le prelinkedkernel (ou cache de démarrage incluant le kernel et l'adressage des kexts ou extensions du noyau). Ce qui signifie qu'il lance le kernel > et l'injection des kexts dans le kernel sans qu'aucune permission de niveau "utilisateur" ne puisse encore jouer le moindre rôle, car il n'y a pas encore d'utilisateur, mais des processus précurseurs d'utilisateurs.
- mais (me figuré-je encore) > lorsque le processus dit "intra_kernel" de l'injection des kexts est accompli > la tâche du kernel est d'initier le processus "extra_kernel" d'activation du Système de l'OS > pour ce faire le kernel doit initier le processus launchd (at: /sbin/launchd) en tant que processus relevant d'un premier utilisateur : l'utilisateur root. Alors, je conjecture que le launchd daemon (dit aussi processus INIT = d'initialisation-Système) doit adresser l'arborescence logique du Système à activer à partir du point de montage de son répertoire de fichiers, càd. à partir de /.
Or le processus launchd en tant que processus de l'utilisateur root > rencontre alors des permissions fixées contradictoires dans son accès par la racine à l'arborescence de fichiers du volume-Système : à savoir des permissions plénières d'accès à l'utilisateur root dont relève launchd / mais à une interdiction totale de permissions d'accès en tant que ce même utilisateur root est compris dans le secondary_group everyone.
=> je pense qu'à ce stade de non activation du Système de l'OS > le kernel n'a pas les moyens d'arbitrer cette contradiction logique d'un accès root autorisé / interdit au répertoire du volume-Système et pas non plus le processus_parent launchd qui se trouve autorisé / interdit en même temps d'accéder par la racine à l'arborescence du répertoire du volume-Système. Par conséquent > si launchd plante face à cette contradiction > alors le kernel récursivement plante (kernel_panic) ; ou si launchd reste en suspension temporelle indéfinie d'une résolution de la contradiction > alors tout tourne en boucle indéfiniment sans plantage mais sans non plus initialisation du Système (cercle vicieux).
- je présume aussi que le boot_loader boot.efi, en tant qu'il exécute aussi un processus précurseur de tout utilisateur (en qualité d'application immédiate de l'EFI) posséde également un passe-droit à l'arborescence du volume indifférent aux permissions d'utilisateurs fixées sur son répertoire parent qui ne concernent que des processus d'utilisateurs > il peut donc charger le prelinkedkernel (ou cache de démarrage incluant le kernel et l'adressage des kexts ou extensions du noyau). Ce qui signifie qu'il lance le kernel > et l'injection des kexts dans le kernel sans qu'aucune permission de niveau "utilisateur" ne puisse encore jouer le moindre rôle, car il n'y a pas encore d'utilisateur, mais des processus précurseurs d'utilisateurs.
- mais (me figuré-je encore) > lorsque le processus dit "intra_kernel" de l'injection des kexts est accompli > la tâche du kernel est d'initier le processus "extra_kernel" d'activation du Système de l'OS > pour ce faire le kernel doit initier le processus launchd (at: /sbin/launchd) en tant que processus relevant d'un premier utilisateur : l'utilisateur root. Alors, je conjecture que le launchd daemon (dit aussi processus INIT = d'initialisation-Système) doit adresser l'arborescence logique du Système à activer à partir du point de montage de son répertoire de fichiers, càd. à partir de /.
Or le processus launchd en tant que processus de l'utilisateur root > rencontre alors des permissions fixées contradictoires dans son accès par la racine à l'arborescence de fichiers du volume-Système : à savoir des permissions plénières d'accès à l'utilisateur root dont relève launchd / mais à une interdiction totale de permissions d'accès en tant que ce même utilisateur root est compris dans le secondary_group everyone.
=> je pense qu'à ce stade de non activation du Système de l'OS > le kernel n'a pas les moyens d'arbitrer cette contradiction logique d'un accès root autorisé / interdit au répertoire du volume-Système et pas non plus le processus_parent launchd qui se trouve autorisé / interdit en même temps d'accéder par la racine à l'arborescence du répertoire du volume-Système. Par conséquent > si launchd plante face à cette contradiction > alors le kernel récursivement plante (kernel_panic) ; ou si launchd reste en suspension temporelle indéfinie d'une résolution de la contradiction > alors tout tourne en boucle indéfiniment sans plantage mais sans non plus initialisation du Système (cercle vicieux).
--------------------
Dernière édition par un modérateur:
Sujets similaires
MacBook Pro
MacBook Pro 15" mi-2014 qui ne démarre plus
