sudo chown échoue avec une opération non autorisée

J'ai trouvé des questions similaires ici, mais les réponses fournies à ces questions ne résolvent pas mon problème.

Si je fais:

sudo chown <username> main.m

J'obtiens une opération non autorisée.

La solution générale aux erreurs antérieures était:

sudo chflags nouchg main.m

pour effacer un indicateur de verrouillage. Cependant, après avoir fait cela, je ne peux toujours pas afficher le fichier. J'ai aussi essayé:

chflags noschg main.m

en mode mono-utilisateur sans aucune chance - je reçois une opération non autorisée erreur.

Si quelqu'un a des pensées, je serais intéressé.

— ericg
source

Quelle est la chose sous-jacente que vous essayez de faire? Il y a peut-être une raison à ce que ce fichier ait un verrou.

— Tamara Wijsman

Je peux donc l'utiliser comme données de test sans placer le code dans un outil d'assistance sécurisé, ce qui nécessite un travail supplémentaire pour déboguer - pas impossible, mais assez ennuyeux que si je peux changer les attributs du fichier, un outil d'assistance sécurisé n'est pas nécessaire, cela rendrait les choses un peu plus faciles. Étant donné que ce ne sont que des données de test qui ont été créées, il n'y a plus de bonne raison pour qu'elles aient un verrou.

— ericg

Sur quel type de système de fichiers se trouve le fichier? Vous n'essayez pas d'utiliser chownsur un système de fichiers NTFS / FAT, n'est-ce pas?

— Zoredache

@ericgorr: La plupart de cela est au-dessus de ma tête; Je ne sais pas exactement ce qu'est un outil d'aide sécurisé. Mais comme vous le dites, ce ne sont que des données de test qui ont été créées; avez-vous correctement fermé le fichier de test dans votre code?

— Tamara Wijsman

@Tom un outil d'assistance est la façon dont OS X accorde à une application des privilèges élevés tout en conservant des privilèges - donc si une application souhaite modifier un fichier sécurisé, par exemple, elle indique à l'outil d'assistance (autorisé) de modifier le fichier à sa place. Je suppose qu'ericgorr veut éviter d'élever son application ou quelque chose pour éviter le débogage rigoureux qui l'accompagne.

— Vervious

Fichiers Mac peuvent être protégés en ~~quatre~~ trois façons différentes que je connais:

Les propriétés et autorisations Unix standard comme r / w / x pour l'utilisateur / groupe / autres que vous voyez ls -let corrigez avec chown(1)et chmod(1).
Drapeaux de fichiers comme uchget schgque vous voyez ls -lOet corrigez avec chflags(1).
Les anciennes métadonnées du Finder "Lock bit" que vous voyez avec GetFileInfo filename. Vous pouvez également voir la présence des métadonnées du Finder, mais pas sa signification, avec ls -l@. Vous pouvez le réparer avec SetFile(1). Peu importe, cela est mappé au uchgdrapeau maintenant.
Listes de contrôle d'accès (ACL) que vous voyez avec ls -leet corrigez avec les arguments liés aux ACL chmod(1).

Voyons donc ce qui se passe avec votre fichier en combinant tous ces indicateurs pour ls:

ls -lO@e main.m

Il semble que vous sachiez déjà comment gérer les problèmes n ° 1 et n ° 2.

Si vous voyez une ACL (# 4), vous pouvez la corriger avec les arguments liés à l'ACL à chmod(1).

Si vous êtes toujours perplexe, mettez à jour votre réponse avec la sortie de cette lscommande combinée que j'ai suggérée ci-dessus, afin que nous puissions voir ce qui se passe.

— Spiff
source

Le problème semble être lié aux ACL. Je trouve intéressant que sudo ne contourne pas ces verrous. De plus, chmod -R -a # 0 * a supprimé les ACL de la plupart des fichiers de la hiérarchie, mais n'a pas réussi à les supprimer de certains - l'utilisation de sudo avec le chmod n'a pas aidé.

— ericg