89 votes

Pourquoi chown rapporte "Operation not permitted" sous OS X ?

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

sudo chown myusername:wheel ./entries

mais Unix/Mac renvoie "Operation not permitted". Lorsque je ls -lash le fichier coupable, ça ressemble à ça :

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

J'ai essayé sudo y 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 mon ancienne boîte Ubuntu. La plupart des fichiers ont réussi à chmod mais celui-ci est bloqué et je ne comprends pas pourquoi.

106voto

Old Pro Points 2099

Oui, Mac a beaucoup d'améliorations par rapport à Unix dans le domaine des fichiers. En ignorant l'ensemble fourchette de ressources chose qui n'est plus guère utilisée, il y en a :

  • le site permissions standard d'Unix ugo rwx et ainsi de suite. Les outils Unix normaux s'appliquent.
  • ACL qui peuvent être visualisées avec ls -le et modifiable avec chmod [ -a | +a | =a ] .
  • drapeaux de fichiers consultable avec ls -lO (Capital oh, pas zéro) et modifiable avec chflags .
  • attributs étendus consultable avec ls -l@ (clés d'attribut uniquement) et visualisable et modifiable avec xattr . (Utiliser 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 apportées par des processus ordinaires, même lorsque l'on utilise sudo pour fonctionner comme root . Les fichiers protégés par SIP seront listés par ls -lO comme ayant le restricted et/ou être listé par ls -l@ comme ayant le com.apple.rootless attribut.

Les opérations sur un fichier peuvent vous être refusées à cause des permissions Unix, des ACL, des drapeaux de fichier ou du 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 y sudo xattr -d com.apple.rootless renverra également une erreur "Operation not permitted". Pour effacer l'indicateur et/ou l'attribut, vous devez démarrer en mode Récupération de macOS et exécutez les commandes depuis un terminal (vous devrez peut-être utiliser l'utilitaire de disque pour déverrouiller et monter votre disque de démarrage, puis rappelez-vous que vos fichiers seront sous /Volumes/Macintosh HD ou quel que soit le nom de votre lecteur de démarrage) ou désactiver complètement SIP puis redémarrez et les commandes devraient alors fonctionner. Sachez cependant que les futures mises à jour du système d'exploitation rétabliront probablement la fonction restricted et com.apple.rootless à tous les fichiers dont vous l'avez supprimé.

La désactivation de SIP n'est pas recommandée car cela supprime une grande partie de la protection contre les logiciels malveillants et les dommages accidentels, et ce n'est pas nécessaire lorsque vous pouvez simplement supprimer la protection sur une base par fichier. Si vous désactivez SIP, réactivez-le lorsque vous avez terminé vos modifications.

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

20voto

bendalton Points 301

J'ai eu le même problème. Il s'avère que les fichiers incriminés étaient marqués comme "verrouillés" par le système d'exploitation. J'ai trouvé cette solution qui a résolu le problème en quelques secondes :

http://explanatorygap.net/2005/07/10/unlocking-files-recursively-from-the-command-line/

Il semble que le rm a été modifiée dans Tiger de sorte que si vous utilisez la commande rm -Rf avec des privilèges élevés, il 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/

En outre, même après OS X 10.4, il peut y avoir des drapeaux de métadonnées de fichiers tels que uchg y uappnd qui empêchent toute modification des autorisations ou de la propriété des fichiers. chflags peut retirer les drapeaux. Voici quelques-uns des attributs/métadonnées de fichiers et la façon dont ils sont traités par les différents outils de copie aquí .

12voto

ruffy Points 121

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

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

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

Faites cela pour voir quels drapeaux sont 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, faites ce qui 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 !

12voto

André Neves Points 3080

Dans OS X 10.11 (El Capitan), ce problème peut également être causé par la nouvelle fonctionnalité Sans racines caractéristique. Voir cette réponse pour une explication.

En bref, pour certains répertoires importants, il n'y a aucun moyen de les modifier - que vous utilisiez la fonction sudo , chown o chmod . Cela affecte le /usr (bien que vous soyez autorisé à modifier /usr/local ).

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

5voto

OMA Points 619

Après avoir beaucoup lutté, voici ce que j'ai dû faire pour régler le problème :

  • Déplacement du 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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X