2011-05-04 20:42:49 +0000 2011-05-04 20:42:49 +0000
69
69

Pourquoi chown signale-t-il "Operation not permitted" sur OS X ?

J'essaie de faire ce qui suit sur mon Mac (10.6.7) :

sudo chown myusername:wheel ./entries

mais Unix/Mac renvoie “Opération non autorisée”. Quand je ls -lash le fichier coupable, cela ressemble à ceci :

8 -rwxrwxrwx 1 myusername staff 394B Apr 26 23:26 entries

J'ai essayé sudo et sudo su ; rien ne fonctionne. Une idée de ce qui se passe ?

J'essaie de chmod des fichiers que j'ai copiés de ma vieille boîte Ubuntu. La plupart des fichiers ont réussi à faire chmod récursivement ; seul celui-là est bloqué et je ne comprends pas pourquoi.

Réponses (7)

91
91
91
2012-12-12 21:58:23 +0000

Oui, Mac a apporté de nombreuses améliorations à Unix dans le domaine des fichiers. Si l'on ignore tout le resource fork chose qui n'est plus très utilisée, il y en a :

  • les permissions Unix standard ugo rwx et ainsi de suite. Les outils Unix normaux s'appliquent.
  • les ACL, visibles avec ls -le et modifiables avec chmod [-a | +a | =a].
  • drapeaux de fichiers, visibles avec ls -lO (majuscule oh, pas zéro) et modifiables avec chflags.
  • attributs étendus, visibles avec ls -l@ (clés d'attributs uniquement) et visibles et modifiables avec xattr. (Utilisez xattr -h pour obtenir de l'aide si man xattr ne vous donne rien)
  • À partir de OS X 10.11 “El Capitan”, * Protection de l'intégrité du système ** (SIP) protège davantage certains fichiers contre les modifications des processus ordinaires, même lorsque vous utilisez sudo pour exécuter root. Les fichiers protégés par SIP seront répertoriés par ls -lO comme ayant le drapeau restricted et/ou seront répertoriés par ls -l@ comme ayant l'attribut com.apple.rootless.

Vous pouvez vous voir refuser des opérations sur un fichier à cause des autorisations Unix, des ACL, des drapeaux de fichiers ou de SIP. Pour déverrouiller complètement un fichier :

sudo chmod -N file # Remove ACLs from file
sudo chmod ugo+rw file # Give everyone read-write permission to file
sudo chflags nouchg file # Clear the user immutable flag from file
sudo chflags norestricted file # Remove the SIP protection from file
sudo xattr -d com.apple.rootless file # Remove SIP protection from file

Si la protection de l'intégrité du système (SIP) est activée, sudo chflags norestricted et sudo xattr -d com.apple.rootless renverront également une erreur “Opération non autorisée”. Pour effacer le drapeau et/ou l'attribut, vous devez démarrer dans macOS Recovery et soit exécuter les commandes depuis le terminal (vous devrez peut-être d'abord utiliser l'utilitaire de disque pour déverrouiller et monter votre lecteur de démarrage, puis vous rappeler que vos fichiers seront sous /Volumes/Macintosh HD ou quel que soit le nom de votre lecteur de démarrage), soit désactiver complètement SIP et ensuite redémarrer et les commandes devraient alors fonctionner. Sachez toutefois que les futures mises à jour du système d'exploitation restaureront probablement l'indicateur restricted et l'attribut com.apple.rootless pour tous les fichiers dont vous l'avez supprimé.

_ La désactivation de SIP n'est pas recommandée _ car elle supprime beaucoup de protection contre les logiciels malveillants et les dommages accidentels, et elle n'est pas nécessaire lorsque vous pouvez simplement supprimer la protection par fichier. Si vous désactivez le SIP, réactivez-le lorsque vous avez fini de faire des modifications.

Notez que si ls -lO indique que le drapeau schg est activé, vous devez passer en mode mono-utilisateur pour le désactiver. Je ne vais pas aborder ce sujet ici, car il y a de plus grandes questions sur la raison pour laquelle ce drapeau est activé dans le fichier et pourquoi vous essayez de le modifier et quelles en seront les conséquences.

18
18
18
2011-06-08 17:47:37 +0000

J'ai eu le même problème. Il s'est avéré que les fichiers incriminés étaient marqués comme “verrouillés” par le système d'exploitation. J'ai trouvé cette solution et cela a résolu les problèmes en quelques secondes : http://explanatorygap.net/2005/07/10/unlocking-files-recursively-from-the-command-line/

Il semble que la commande rm ait changé dans Tiger de telle sorte que si vous utilisez rm -Rf avec des privilèges élevés, elle déverrouillera automatiquement les fichiers.

Dans OS X avant Tiger : find /Volumes/Transit -flags +uchg -print0 | xargs -0 chflags nouchg

Dans OS X après Tiger : sudo rm -Rf foldername/

Aussi, même après OS X 10.4, il peut y avoir des drapeaux de métadonnées de fichier tels que uchg et uappnd, qui empêchent toute modification des autorisations ou de la propriété du fichier. chflags peut supprimer les drapeaux. Certains des attributs/métadonnées de fichier et la manière dont ils sont traités par les différents outils de copie sont ici .

12
12
12
2015-09-30 23:09:40 +0000

Dans OS X 10.11 (El Capitan), cela peut également être causé par la nouvelle fonction Rootless. Voir cette réponse pour une explication.

En bref, pour certains répertoires importants, il est impossible de les modifier - que vous utilisiez sudo, chown ou chmod. Cela affecte le répertoire /usr (bien que vous soyez autorisé à modifier /usr/local).

Pour modifier un répertoire protégé par Rootless-protected, vous devez désactiver Rootless . Et, bien sûr, le réactiver après avoir effectué vos modifications, car il s'agit d'une amélioration importante de la sécurité.

12
12
12
2014-08-21 17:30:15 +0000

J'ai eu le même problème avec le Crashplan.app.

Toutes les solutions énumérées ici ne m'aideraient pas, mais celle-ci a fait l'affaire http://forums.macrumors.com/showthread.php?t=1546163

Vous devez changer les drapeaux immuables du système et de l'utilisateur :

Faites ceci pour voir quels sont les drapeaux actifs sur votre fichier/dossier :

ls -lhdO MyFile

La réponse pourrait ressembler à ceci :

drwxrwxr-x 3 root admin schg,uchg 102B Apr 8 2013 MyFile

schg , uchg sont ces drapeaux immuables. Un pour le système et un pour l'utilisateur. Pour les supprimer, procédez comme suit :

chflags noschg CrashPlan.app # this removes system immutable flag
chflags nouchg CrashPlan.app # this removes the user immutable flags

Ensuite, pour moi du moins, le fichier est déverrouillé et vous pouvez le supprimer !

5
5
5
2011-05-04 21:02:23 +0000

Après de nombreuses difficultés, voici ce que j'ai dû faire pour résoudre le problème :

  • Déplacer le fichier vers ~/Desktop
  • sudo chown myusername:staff ./entries
  • Le déplacement du fichier vers son emplacement d'origine n'a pas fonctionné (opération non autorisée, encore une fois), donc…
  • sudo rm ./entries
  • sudo mv ~/Desktop/entries ./entries
4
4
4
2013-09-19 22:49:53 +0000

J'ai eu le même problème, à propos de mon dossier personnel. A la fin, j'ai juste utilisé le finder comme ça :

Allez -> Ordinateur -> votre disque -> Utilisateurs -> votre nom d'utilisateur -> clic droit -> Obtenir des infos

J'ai trouvé qu'il était verrouillé, probablement que je l'ai fait dans le passé et que j'ai oublié. J'ai décoché la case “verrouillé”, problème résolu.

Je peux vous recommander d'utiliser “Get Info” de finder afin de résoudre ce genre de problème.

(OS X 10.8.3)

1
1
1
2015-03-23 15:28:32 +0000

Assurez-vous que le fichier et son dossier parent sont déverrouillés

J'ai rencontré un problème similaire en essayant de supprimer un fichier de signature de courriel Mac Mail. Je ne pouvais pas le supprimer tant que je n'avais pas déverrouillé le fichier ainsi que son dossier parent.