Problèmes d'autorisations

[Macoupc]

Bonjour,

J'ai reçu hier un MacBook Pro avec un DVD de mise à jour pour Leopard.

Je me suis empressé de l'installer (avec toutes les langues etc... pas le choix )

J'ai ensuite transféré les données de mon "vieux" mac powerbook G4 mais impatient, je crois avoir fait une bêtise : en effet, j'ai défini un autre nom d'utilisateur pour distinguer l'ancien et le nouveau mais du coup ça a dupliqué les dossiers utilisateurs et même créé un utilisateur en plus sur le MBP qu'on pourrait appeler PWB.

C'est peut-être pas plus mal pour faire le tri mais du coup, une fois que j'ai transféré tous les dossiers et fichiers utiles, j'ai effacé "l'utilisateur récupéré (PWB)". Le problème c'est que je me retrouve avec des autorisations complètement chamboulées, il y a pas mal de fichiers avec les autorisations de PWB qui, comme il a été effacé, se transforment en "unknown"

ce que je voudrais faire, c'est transférer toutes les autorisations "unknowm" vers "MOI (MBP)" car en écriture, c'est super complexe, je rentre 15 fois par heure mon mot de passe admin...

Si vous avez un moyen de m'aider... Je me demande s'il faudrait passer en "FCK user" ou un truc comme ça, root.... Merci

(autorisations réparées...)

C'est quand même bizarre, parfois les autorisations existent en double (cf capture ci-jointe...)


Parfois un message apparaît mais je ne sais pas ce que ça veut dire...

Personne ne connaît un site qui répertorierait toutes les "erreurs" système de mac os X ? Savoir ce que ça veut dire au moins...


Merci de votre aide

Croyez-vous qu'une réparation des autorisations à partir du DVD va régler le problème ??? Là c'est assez agaçant.

Ce message a été modifié par Macoupc - 8 Nov 2007, 16:24.

[Macoupc]

Croyez-vous qu'une réparation des autorisations à partir du DVD va régler le problème ??? Là c'est assez agaçant.

Ça ne marche toujours pas... Après 20min de réparations d'autorisations depuis le DVD d'installation, rien n'a changé. Je dois pour chaque dossier, changer l'utilisateur, mettre le mot de passe. C'est saoûlant !

[jujuhtst]

La réparation des autorisations n'y est pour rien, il faut que tu te réattribue tes fichiers ...

CODE

sudo chown -R ton_nom_unix:ton_nom_unix ~/

ça permet de te définir comme proprio de toute ton arborescence "perso".

[_Panta]

CODE

sudo chown -R ton_nom_unix:ton_nom_unix ~/

Ce qui pour les allergiques à la ligne de commande donne en langage humain après traduction (et là tout s'éclaire):

sudo (le super user root) chown (change owner, modifie le propriétaire) -R (récursivement, donc tous les dossiers et sous-dossiers) ton_nom_unix:ton_nom_unix (du nom de l'ancien propriétaire vers le nouveau propriétaire) pour le dossier ~/ (le repertoire /Users/ton_nom_unix).

C'est un souci classique de tranfert de droit qu'on retrouve souvent dans les systemes unix quand on garde ou importe son ancien répertoire /home

Simple, pratique et rapide la ligne de commande, non ? Il n'y a qu'a lui parler gentiment et votre machine vous le rendra bien

[jujuhtst]

ton_nom_unix:ton_nom_unix (du nom de l'ancien propriétaire vers le nouveau propriétaire) pour le dossier ~/ (le repertoire /Users/ton_nom_unix).

Euh non c'est "nom:groupe", par défaut sur Unix et Linux chaque utilisateur appartient au groupe qui porte son nom (genre un utilisateur qui s'appelle "moi" appartient au groupe "moi" )

Donc on attribut la possession du dossier "HOME" (alias ~/, alias la petite maison ) à l'utilisateur et au groupe "ton_nom_unix".

Autrement c'est vrai que j'aurai pu faire une explication un peu plus "user friendly"

Mais bon mon léo (peut-être de la faute de Onyx... vait plus l'utiliser ce truc ) m'a pêté un cable hier soir et ce matin j'ai du passer en mode single user pour activer le root, vu que j'avais plus aucun administrateur sur ma bécane vu que mon compte (seul et unique de la bécanne) a perdu "malencontreusement" le statut administrateur ...

[radioman]

Parfois un message apparaît mais je ne sais pas ce que ça veut dire...

Personne ne connaît un site qui répertorierait toutes les "erreurs" système de mac os X ? Savoir ce que ça veut dire au moins...

Ben directement chez dieu le père:
http://docs.info.apple.com/article.html?artnum=9804-fr
http://docs.info.apple.com/article.html?artnum=9805-fr
http://docs.info.apple.com/article.html?artnum=9806-fr

[Macoupc]

Parfois un message apparaît mais je ne sais pas ce que ça veut dire...

Personne ne connaît un site qui répertorierait toutes les "erreurs" système de mac os X ?

Ben directement chez dieu le père:
http://docs.info.apple.com/article.html?artnum=9804-fr
http://docs.info.apple.com/article.html?artnum=9805-fr
http://docs.info.apple.com/article.html?artnum=9806-fr

Merci, là, c'est -50 =

paramErr Error in user parameter list

Pas étonnant. Pourquoi ce n'est pas traduit directement ? Parce que c'est très rare ?

CODE

sudo chown -R ton_nom_unix:ton_nom_unix ~/

sudo (le super user root) chown (change owner, modifie le propriétaire) -R (récursivement, donc tous les dossiers et sous-dossiers) ton_nom_unix:ton_nom_unix (du nom de l'ancien propriétaire vers le nouveau propriétaire) pour le dossier ~/ (le repertoire /Users/ton_nom_unix).

C'est un souci classique de tranfert de droit qu'on retrouve souvent dans les systemes unix quand on garde ou importe son ancien répertoire /home

Simple, pratique et rapide la ligne de commande, non ? Il n'y a qu'a lui parler gentiment et votre machine vous le rendra bien

Merci beaucoup de votre aide, si je l'avais sollicitée plus tôt, je n'aurais pas tapé 1000 fois mon code admin sans parvenir à régler le problème... Et en réinitialisant le mot de passe avec clavier US (heureusement ça m'était déjà arrivé ce genre de truc) !

Il me fait un peu flipper quand même votre terminal qui peut tout effacer en un mot. Je vous fais confiance, pas de problème, mais quand il me dit

WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type "man sudo" for more information.

Ça fait peur. Mon problème avant de me lancer, c'est que l'utilisateur qui aurait les autorisations (je l'avais appelé Powerbook, je l'ai effacé. Du coup, c'est un utilisateur en grisé qui s'appelle unknown. Je mets ça ?

Un dernier truc si vous savez, pourquoi il y a 2 fois everyone mais avec des autorisations d'accès différentes ?
Merci encore

Ce message a été modifié par Macoupc - 7 Nov 2007, 02:21.

[jujuhtst]

Il me fait un peu flipper quand même votre terminal qui peut tout effacer en un mot. Je vous fais confiance, pas de problème, mais quand il me dit

WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type "man sudo" for more information.

Ça fait peur.

Bah oui tu peux tout bousiller si tu fais des bétises mais tu n'as pas besoin du terminal pour foutre aussi en l'air ton système, cf le "cheval de troie" de ces derniers jours ... Si l'utilisateur ne fait pas de connerie et que le système n'a pas de bug sur l'élément en question y a pas de raison que ça crash

Mon problème avant de me lancer, c'est que l'utilisateur qui aurait les autorisations (je l'avais appelé Powerbook, je l'ai effacé. Du coup, c'est un utilisateur en grisé qui s'appelle unknown. Je mets ça ?

Non tu mets l'utilisateur actuel, pour être sur de comment tu t'appelles en "unix" tu tappes ça dans le terminal :

CODE

whoami

C'est la commande "Who am I ?" (qui suis-je ?) donc là t'auras le nom à utiliser dans la commande chown.

Un dernier truc si vous savez, pourquoi il y a 2 fois everyone mais avec des autorisations d'accès différentes ?

C'est peut-être que tu as des partages différents selon si c'est du partage windows, mac ... ou bien c'est un bug

[Macoupc]

J'ai donc mis 2 fois mon nom unix et entrée...

C'est super puissant quand même ! Ça prend 5 secondes...

Pour certains dossiers ça n'a pas fonctionné mais c'est pas super grave. Ces dossiers étaient tous verrouillés et déverrouillables depuis la fenêtre "lire les informations". Mais je crois qu'ils ont les bonnes autorisations.

/Users/~/Library/Preferences/Graphisoft/AC 10.0/WorkEnvironment/User Preferences/Standard User Prefs 10.bin: Operation not permitted

En ce qui concerne les 2 "everyone" il me semble que c'est un bug, car je n'ai pas encore activé de partage.

J'aimerais bien faire la même chose pour les applications qui ne se laissent pas jeter à la poubelle alors que j'y fais le tri en ce moment... Pour ne pas faire de bêtises, je vous demande avant : si je mets "applications" à la place de "~" cad "users" ça marchera aussi ? Merci en tous cas.

[jujuhtst]

si je mets "applications" à la place de "~" cad "users" ça marchera aussi ? Merci en tous cas.

"~" correspond au "home", tu peux mettre le chemin vers n'importe quoi, attention c'est des chemins "unix" avec écriture "shell" (codage des accents, espaces ...) donc à utiliser avec précaution.

Si tu attribue les mauvais "propriétaire" à certains fichiers (genre système) tu vas complètement bousiller ton système...

[Macoupc]

si je mets "applications" à la place de "~" cad "users" ça marchera aussi ? Merci en tous cas.

"~" correspond au "home", tu peux mettre le chemin vers n'importe quoi, attention c'est des chemins "unix" avec écriture "shell" (codage des accents, espaces ...) donc à utiliser avec précaution.

Si tu attribue les mauvais "propriétaire" à certains fichiers (genre système) tu vas complètement bousiller ton système...

donc pour redéfinir les autorisations du dossier "applications", je mets quoi ? Car en effet, je ne veux pas toucher à toutes les autorisations du dossier "Macintosh HD" mais plus loin juste applications.

imaginons que mon nom unix soit "macoupc" si je mets

CODE

sudo chown -R macoupc:macoupc Macintosh HD/Applications/

ça ne modifiera que les autorisations du dossier "Applications" et pas le dossier "Bibliothèque" ou "Système" ???

[jujuhtst]

donc pour redéfinir les autorisations du dossier "applications", je mets quoi ? Car en effet, je ne veux pas toucher à toutes les autorisations du dossier "Macintosh HD" mais plus loin juste applications.

Tu ne le fais pas, le dossier Applications appartient à "root:admin" pour des raisons de sécurité. Si tu as envie de flinguer ton système vas-y mais ne te plains pas ensuite ...

imaginons que mon nom unix soit "macoupc" si je mets

ça te sortira une erreur ... Car ton chemin est faux et si tu ne fais pas gaffe un jour tu vas te retrouver vraiment avec ton système HS ...
Les "espaces" des noms de fichiers doivent être précédés d'un backslash sinon le terminal considère que ce qu'il y a après est un nouvel élément de la commande.

De plus "Applications" ne se trouve pas là ... :
Chez toi c'est :

CODE

/Volumes/Macintosh\ HD/Applications/

ou (chez tout le monde normalement) :

CODE

/Applications/

C'est une erreur de penser que tous les fichiers "doivent" nous appartenir, si ce n'est pas le cas c'est qu'il y a une raison (Unix inside ...)

[Macoupc]

Merci de ta réponse. Ce n'est pas spécialement que je veux m'approprier mes applications même si elles m'appartiennent. Mais je me souviens que je pouvais en disposer facilement sous tiger et c'était plus simple.
Je vais donc rien faire, mais est-ce normal que si je glisse un fichier d'application vers la corbeille, il me demande mon mot de passe d'admin ?

Sinon je ne peux toujours pas modifier le nom d'un fichier dans le dossier "documents". Même message : "vous ne possédez pas les autorisations requises pour modifier (...)" Pour tous les fichiers que j'ajoute ça va mais pas pour ceux qui étaient là et que j'ai transféré depuis mon ancien ordi.

Ce qui m'étonne, c'est qu'il y a un utilisateur inconnu (ancien "powerbook" à mon avis) qui ne veut pas se laisser effacer avec le "-". Il ne me dérange pas mais il ne sert à rien.

Je viens de faire un test : sur certains fichiers dans "documents", il y a deux fois "everyone" dont un qui dit "personnalisé" et c'est en le changeant avec le menu déroulant vers "lecture et écriture" qu'on peut enfin changer le nom.

Bref, je vous embête et ça m'embête.

[jujuhtst]

est-ce normal que si je glisse un fichier d'application vers la corbeille, il me demande mon mot de passe d'admin ?

Est ce que tu as le statut "administrateur" ? C'est des "anciennes" applications issues de Tiger ?

Et est ce dérangeant ? C'est une sécurité supplémentaire ...

Sinon je ne peux toujours pas modifier le nom d'un fichier dans le dossier "documents".

Il est où ce dossier ? Dans ton espace utilisateur ou ailleurs ?

mais pas pour ceux qui étaient là et que j'ai transféré depuis mon ancien ordi.

Avec le chown si tu fais le bon truc c'est OK. T'as bien utilisé yoann:yoann ?
Et le bon dossier ? (cf où est "documents")

et c'est en le changeant avec le menu déroulant vers "lecture et écriture" qu'on peut enfin changer le nom.

Normalement le chown doit changer ça sans utiliser le Finder...
Ensuite peut-être qu'il faudrait aussi faire un "chmod" pour modifier les droits, mais déjà marque clairement où sont tes documents et les commandes que tu as tappée dans le terminal

[Macoupc]

est-ce normal que si je glisse un fichier d'application vers la corbeille, il me demande mon mot de passe d'admin ?

Est ce que tu as le statut "administrateur" ? C'est des "anciennes" applications issues de Tiger ?

Et est ce dérangeant ? C'est une sécurité supplémentaire ...

Oui, ce sont des applis transférées avec l'application "Assistant migration" en disque cible. Comme pour tout le reste d'ailleurs.

J'ai essayé de faire la commande suivante dans le terminal pour me "redonner les droits" pour les applications, que je puisse en disposer sans taper mon mot de passe admin à chaque fois

CODE

sudo chown -R yoann:yoann /Volumes/MacBook\ Pro/Applications/

Mais je pense que c'est intéressant, ça m'a donné ça quand j'ai essayé de nouveau de supprimer une application et que le finder m'a demandé mon mdp :

mais pas pour ceux qui étaient là et que j'ai transféré depuis mon ancien ordi.

Avec le chown si tu fais le bon truc c'est OK. T'as bien utilisé yoann:yoann ?
Il est où ce dossier "documents" ? Dans ton espace utilisateur ou ailleurs ?

Oui, j'ai bien utilisé yoann:yoann et le dossier "documents" est dans le dossier "MacBook Pro/users/yoann/documents" donc dans le dossier "utilisateurs" normal.

et c'est en le changeant avec le menu déroulant vers "lecture et écriture" qu'on peut enfin changer le nom.

Normalement le chown doit changer ça sans utiliser le Finder...
Ensuite peut-être qu'il faudrait aussi faire un "chmod" pour modifier les droits, mais déjà marque clairement où sont tes documents et les commandes que tu as tappée dans le terminal

Je viens de refaire la commande

CODE

sudo chown -R yoann:yoann ~/

pour voir avec le dossier "documents" mais je ne peux toujours pas changer le nom d'un fichier dans le dossier "documents" sauf en changeant les autorisations "à la main" dans le finder "lire les infos" qui me donnent Il y a un "everyone" et un "inconnu" impossibles à supprimer...

[jujuhtst]

Je viens de refaire la commande

CODE

sudo chown -R yoann:yoann ~/

pour voir avec le dossier "documents" mais je ne peux toujours pas changer le nom d'un fichier dans le dossier "documents" sauf en changeant les autorisations "à la main" dans le finder "lire les infos" qui me donnent Il y a un "everyone" et un "inconnu" impossibles à supprimer...

Le dossier documents est où ? Dans ton dossier perso ou ailleurs ?

Pour les modif : clique sur le petit cadenas qui est en dessous des autorisations. Puis sélectionne le truc à virer et tu clique sur le "-"

[Macoupc]

Le dossier documents est où ? Dans ton dossier perso ou ailleurs ?

Pour les modif : clique sur le petit cadenas qui est en dessous des autorisations. Puis sélectionne le truc à virer et tu clique sur le "-"

Désolé, je croyais avoir répondu... Mais la nouvelle organisation du forum en "explorateur windows" n'aide pas à se repérer dans les différents messages

- Le dossier documents est dans mon dossier perso dans utilisateurs.

- En ce qui concerne le cadenas, c'est ce que j'appelais "à la main", à chaque fois on me demande mon mdp et c'est usant.

- impossible de cliquer sur le "-", il est soit désélectionné, soit cliquer dessus ne fait rien...

[jujuhtst]

Désolé, je croyais avoir répondu... Mais la nouvelle organisation du forum en "explorateur windows" n'aide pas à se repérer dans les différents messages

Tu peux changer ce mode sur le bouton "Options" en haut de la page et tu choisis la vue standard

- En ce qui concerne le cadenas, c'est ce que j'appelais "à la main", à chaque fois on me demande mon mdp et c'est usant.

T'as cliqué aussi sur la petie roue crantée et choisi "Appliquer aux éléments inclus" ?

- impossible de cliquer sur le "-", il est soit désélectionné, soit cliquer dessus ne fait rien...

Pour "inconnu" il me semble que c'est pour le compte "invité".
Vire juste le "everyone" qui est au dessus...

[Macoupc]

Merci pour l'organisation du forum, c'est peut-être moi qui ai changé par erreur... Mais c'est bien qu'on puisse changer si facilement.

T'as cliqué aussi sur la petie roue crantée et choisi "Appliquer aux éléments inclus" ?

oui oui oui

En ce qui concerne le "everyone" juste au dessus, impossible à virer; Je peux en revanche changer les autorisations de cet "everyone" de personnalisé à lecture et écriture et je peux alors changer le nom du fichier mais je ne vais pas faire ça pour chaque fichier !

Pour le dossier "documents", les utilisateurs sont "Moi", "inconnu" (en grisé) et "everyone"... Mais ça ne l'applique pas à tous les fichiers quand je clique sur la roue crantée.

Merci de ton aide, c'est vraiment agaçant ce problème.

Ce message a été modifié par Macoupc - 12 Nov 2007, 19:17.

[footix82]

Bonjour,

Après des années de lutte acharnée sur Windows, la sortie de Léo a été l'occasion de retourner au bercail et mon premier message ici:).

Je suis donc en train de récupérer mes fichiers Windows par un répertoire partagé (je l'ai créé j'ai pas pris la boîte de dépôt) dans /Users/footix/ donc dans le dossier utilisateur et après je copie ces fichiers vers documents, image, etc... Mon problème rejoins celui de Macoupc, à savoir l'impossiblité de supprimer un fichier sans mot de passe et impossibilité de le renommer. J'ai beau avoir effectué
sudo chown - R footix:footix ~/
sudo chown - R footix:footix / Users/footix/
Seul le changement manuel fonctionne.

Mon dossier utilisateur s'appelle footix alors que le propriétaire du compte admin est "Xavier-Nicolas" (mon prénom... que j'avais choisi pour le nom de la machine), rien n'y fait.
Les changements de propriétaires ne sont pas effectués et j'ai toujours everyone avec un statut personnalisé en premier bien que footix (admin) soit en lecture / écriture.
En outre j'ia un problème (bug ? ) récurent. Lorsque je clique sur le "+"pour rajouter un utilisateur après avoir cliqué sur le cadenas dans les informations d'un fichier, la fenêtre d'information du fichier et la fenêtre finder crash et se ferment...
Y a-t-il une raison à ce comportement et une réparation des permissions est-elle à effectuer ?

Merci !

Footix

[Macoupc]

Je retrouve tout à fait dans le comportement du système décrit par footix les symptômes de la maladie féline que je subis. A mon avis, c'est facile à reproduire. Pour une fois que le message correspond tout à fait au sujet... Belle performance pour un premier message. !

Bienvenue sur Macbidouille ! ;-)

[darenzana]

Bonjour,
j'ai mené ma petite enquête, parce que j'ai deja rencontré des problèmes similaires avec Leopard : "entité" (utilisateur ou groupe) "Inconnu" dans la fenêtre d'infos, et plantage du Finder quand on essaye de modifier les permissions du fichier.

Je viens juste de comprendre le problème, et c'est un bug du Finder visiblement. Tous les fichiers qui ont un groupe provenant de Tiger posent problème. Mais ce n'est qu'un problème d'affichage dans le Finder, les commandes UNIX fonctionnent bien, et les permissions sont correctes. Donc, pour les problèmes d'utilisateur "Inconnu" de ce type, il faudra attendre que le bug soit corrigé.

Les fichiers dans ce cas sont la quasi-totalité des fichiers utilisateurs. Pour vérifier qu'un fichier est dans ce cas; dans le terminal, tapper "ls -l" puis espace, puis glisser/déplacer le fichier du finder vers la fenêtre du terminal, puis tapper entrée. ça donne le résultat suivant:

CODE

ordinateur-de-didier:~ didier$ ls -l /Users/didier/Modif\ iPhoto.txt
-rw-r--r--  1 didier  didier  907 26 aoû 00:33 /Users/didier/Modif iPhoto.txt

l'utilisateur du fichier est didier, le groupe didier. Cet utilisateur a été importé de Tiger (j'ai fait une install "Archive & install").
Apparement, dans Leopard, quand on créé un nouvel utilisateur, il n'a pas de groupe à son nom. Il appartient au groupe staff, et ses fichiers ne posent pas problème au Finder.

Edit : Après plus de recherche et apprentissage de ma part, j'ai définitivement cerné le problème.
Il s'agit des groupes qui n'ont pas d'entrée "RealName" dans le "DirectoryService" de Mac OS X.
Ce sont des notions que je ne maitrise pas trop, mais a tatons, j'ai réussi à comprendre ça:
Lorsque le finder veut afficher le nom du groupe dans les permissions d'un fichier, il utilise cette propriété. Et pour le groupe "didier" dans mon cas, cette clef n'existait pas.

Je vous donne ci-dessous les commandes que j'ai utilisées pour corriger le pb; attention avec ces commandes on modifie des valeurs dans le coeur même de Mac OS, on peut faire de gros dégats en tripatouillant...

Pour lire la valeur en question, et vérifier si elle existe ou non:

CODE

dscl . -read Groups/<nomdugroupe>

Pour mon exemple de fichier ci dessus, ça donnait le résultat suivant:

CODE

bash-3.2# dscl . -read Groups/didier RealName
No such key: RealName

donc, la clef en question n'existe pas. On va donc la créer, et lui donner la valeur "Didier" <= Le nom que je veux voir s'afficher dans le Finder

CODE

dscl . -create Groups/didier RealName Didier

Après cette manip, si je demande au Finder les infos sur mes fichiers "problematiques" dans mon repertoire, plus de probleme, je n'ai plus de (Inconnu) et plus de crash du Finder en tentant de changer les permissions
On peut vérifier le résultat de la commande read :

CODE

bash-3.2# dscl . -read Groups/didier RealName
RealName: Didier

Ce message a été modifié par darenzana - 13 Nov 2007, 02:33.

[girafe]

Bonjour,
sur MacFixit, il y ça: http://www.macfixit.com/index.php?date=2007-11-12

PS1: Je m'excuse mais je n'ai pas le temps matériel de traduire (ni les compétences).
PS2: C'est long mais ça va vite disparaître si l'on n'est pas abonné à MacFixit.
PS3: Je ne sais pas faire les Tab en BB Code, j'ai fait au mieux.

How to change the group id of files and folders

The problem Since upgrading to Leopard, many users have been experiencing permissions problems. Some of these are connected with Group access to their files. A typical symptom is this: you select a file in the Finder and choose File > Get Info to examine its permissions. Permissions are listed at the bottom of the Get Info window, under "Sharing and Permissions". The Group here is listed as "Unknown". And then, possibly, when you click the lock (to authorize) and then try to change the Group setting, the Finder crashes.

Files and folder with the "Unknown" group are causing other problems as well. There is some evidence that Spotlight might not index them correctly, and perhaps Time Machine may not even back them up properly. And these incorrect groups might be at least partly to blame for the slowness of Repair Permissions on some people's machines. It isn't entirely clear what all the ramifications are.

Nor is it obvious why having an "Unknown" group should make much difference. Groups is Unix are not usually a big deal. The usual way in which groups come into place is when you're the admin user; this fact is expressed by your being a member of the admin group, and it is that that gives you write access to the top-level Applications folder, whose owner is root (which is not you) but whose group is admin (of which you're a member, and so the read-write group permissions on the Applications folder apply to you).

Funny things happen with groups all the time, and you never even notice. For example, in Tiger, when I save a new TextEdit file to my Desktop, it has gid 501, which is correct, but when I create a file with Preview (by copying a selection from an existing Preview window and choosing File > New From Clipboard) and save it to my Desktop, it has gid 0, which is wrong. So Mac OS X itself assigns things the wrong group quite frequently. This has no ill effects, though.

But it seems that an incorrect group such as this "Unknown" group which people are seeing does make a difference in Leopard. Why would this be? Quite honestly, that isn't clear. Perhaps it has something to do with the new implementation of the file sharing system, which depends very heavily on groups. For example, on my Leopard machine, my user is a member of the com.apple.access_screensharing group, because I've got screen sharing turned on for that user, and of the com.apple.access_ssh group, because I've got remote login turned on for that user. That's a completely new mechanism for marking who gets what kind of shared access to the computer, so perhaps that's why Leopard is so touchy about groups, in a way that Mac OS X never was before.

The cause Where are these "Unknown" group settings coming from? In a sense, the answer is very clear: it's that between Tiger and Leopard, Apple has changed its group policy for users.

*In Tiger, a user was associated primarily with a group with the same name and number as the user. To see this, in Tiger, give the id command in the Terminal. What you'll see will start something like this:

uid=501(cooluser) gid=501(cooluser) groups=501(cooluser)

*In Leopard, a user is associated primarily with the "staff" group. To see this, in Leopard, give the id command in the Terminal. What you'll see will start something like this:

uid=501(cooluser) gid=20(staff) groups=20(staff)

("uid" means user id; "gid" means group id. The id has both a number and a name.)

And there is one other point, which is equally important:

* In Leopard, for some people at least, there is no 501 group (or whatever your old group number might be).

It's the combination of these two things - the 501 user used to be a member of the 501 group, but in Leopard there is no 501 group - that is causing a file or folder with group id 501 to have its group described as "Unknown".

Another part of the cause is that, for some people at least, the Leopard installation process is not compensating for this change. It should be. Changing group values is not all that uncommon; it happens all the time. It happens, for instance, when a file or folder is copied from one user to another. For example, when I use File Sharing to connect my Tiger machine to my Leopard machine and copy a file from the one to the other, the file has uid 501 and gid 501 on Tiger, but when it is copied to Leopard it takes on uid 501 and gid 20. In other words, the system compensates for the fact that group 501 doesn't exist on the Leopard machine; the target user on the Leopard machine has group 20, so the copied file is assigned group 20.

The trouble is that this is not happening for some users during the upgrade process, and so there are a lot of files and folders hanging around whose group id is 501. Since there is no Leopard group whose gid is 501, Leopard calls this group "unknown".

Fixing the group id, the Finder way Some readers have found that they can correct permissions on a migrated folder merely by copying it (not moving it) to the Deskop, and then moving it back into place, replacing the troublesome copy of the folder.

Perhaps that technique would have come in handy during the upgrade to Leopard. For example, let's say you did an Archive and Install where your old stuff has ended up the Previous Systems folder. When you move a folder of your old stuff back into place, it might make a difference whether you move it or copy it (by holding down the Option key). Using the latter technique might cause group ids to be changed properly. That point is tentative, though, and probably needs further investigation.

Fixing the group id, the Unix way. Using a simple Unix command in the Terminal, you can correct the group id of all the files and folders within your Home directory, changing only those group ids that are specifically incorrect. (We're going to stay inside the Home directory because messing with permissions outside it is a completely different kettle of fish, and is not recommended unless you really know what you're doing.) If you want to try this, you should be aware that things could backfire very seriously, so make sure you've got a backup before doing anything else, and make sure you mentally sign the MacFixIt Total Indemnification Form in advance. (Having said that, I did run this on my machine before telling you about it, and it did work.)

1.Use the Spotlight preference pane to exclude your entire hard disk from Spotlight. The reason is that you are about to make a lot of changes, and while you are making them, you don't want Spotlight to be running along behind you, trying to note them all down. This will slow down the whole process considerably. So effectively you want to turn Spotlight off temporarily.
2.For the same reason, turn off Time Machine temporarily. Oh, by the way, every file whose gid gets changed by this process is going to count as a changed file, so it is going to get copied the next time you perform a Time Machine backup. That could be a long, large backup.
3.Next, make sure that your group id is 20. The id command in the Terminal, as shown above, should demonstrate this. If your group id is not 20 you're going to need to change it. To do so, use the Accounts system preference pane. Click the lock (to authorize yourself) and then control-click on your user account in the list of accounts and choose Advanced Options. In the resulting dialog, if your Group ID isn't 20, make it so and dismiss with OK.
4.Now, in Terminal, you need to know the number of the gid that is wrong. So first, find yourself a file or folder whose group is showing up as "unknown" in the Finder's Get Info window, and navigate to its containing folder. In the Terminal, type

ls -aln

followed by a space, and then drag the folder containing the problematic file or folder right from the Finder into the Terminal window, and hit Return in the Terminal. You'll see something like this:

drwx------ [number] 501 501 [number] [date] myFolder

The key thing is that pair of numbers in the middle, which I've shown as 501 501. The first is the uid of this item; the second is the gid of this item. It is the second number, here 501, that should be changed to 20.
5.Okay, I'm going to pretend that the troublesome group number is in fact 501. Then, in the Terminal, do this. First, type

cd

followed by Return. That's to bring you into your Home folder. Now, very very carefully, triple-checking everything before you dare to hit Return, type

sudo find . -group 501 -exec chgrp 20 {} \;

Because of the pesky CMS used here at MacFixIt, I can't be sure how that is going to come out on your machine, so I'm going to recite it in words: "sudo", space, "find", space, dot, space, hyphen-"group", space, "501", space, hyphen-"exec", space, "chgrp", space, "20", open-curly-brace-close-curly-brace, space, backslash-semicolon. I'm particularly worried about that backslash.

To explain all of that:
* "sudo" means "Let me do this even if permissions would normally stop me."
* "find" means "Locate the files matching the following description and perform the following operation on them."
* dot means "Start in the folder where we are now," which is your Home folder because of the previous cd command.
* "-group 501" means "Look for files and folders whose group id is 501." If your troublesome group id is different (e.g. 502), the number here will need to be different.
* "-exec" means "And here's what I want you to do when you find one."
* "chgrp 20" means "Change its group id to 20".
* {} means "When I say 'it', I mean the file or folder you just found."
* backslash-semicolon means "That's the end of what I want you to do."

If you're happy with all that, press Return. This command is going to take quite a long time to execute, so don't be discouraged. Don't do anything with the computer, either. Just let it run. There isn't going to be any feedback until it's all over, at which time your prompt will appear in the Terminal (and, if you computer is like mine, your fans will spin back down!).
6.You can now use ls -al in the Terminal, or use the Finder's Get Info window, to check that things went as expected. When you're satisfied, restart the computer (just for luck), and remove the hard disk from the Spotlight excluded items. Spotlight will reindex the hard drive. When that's all over, you can turn Time Machine back on and resign yourself to a large backup next time it runs.

Conclusions The change between Tiger and Leopard where a user's group number is now 20 instead of a number matching the original user number is a big change, and it seems that Apple didn't prepare for it as well as it might have. And pulling the rug out from under users by invalidating the previously existing 501 group is really not very nice. However, what's most distressing about the current situation is, as usual, the lack of information and the lack of tools.

* Apple gave no warning that this change was coming.
* Apple has never, since the dawn of Mac OS X, supplied a decent GUI utility for fully dealing with Unix ownership and permissions.
* Apple has never provided clear information on what the correct ownership and permissions for various files and folders should be.

There is thus a tendency on Apple's part to obscurity verging on silence when it comes to technical matters, even when those technical matters are quite important. This might be to some extent denial ("Mac OS, it just works") and partly a desire not to burden users with technical concerns. But when you're knee-deep in the frustration of the situation that the Leopard installation has left you with, Apple's attitude may feel more like plain arrogance. In any case, the irony is this: thanks to the lack of decent official GUI tools and information, users are burdened with those technical concerns anyway, and have no recourse but to grapple with the underlying Unix data in the Terminal, and are left to a combination of deduction and guesswork to figure out what the goal is and how to achieve it.

Ce message a été modifié par girafe - 13 Nov 2007, 17:52.

[darenzana]

Merci pour ces explications de MacFixit.
Sauf que dans mon cas, après migration des données de Tiger, le groupe d'ID 501 a bien été créé. Il manquait juste la clef RealName.
=>

CODE

dscl . -search Groups PrimaryGroupID 501
didier        PrimaryGroupID = (
    501
)

De plus, mes utilisateurs importés ne font pas partie du groupe 'staff' (qui a l'ID 20).

Mais la solution donnée de changer le groupe pour staff peut marcher quand même, dans la mesure où l'utilisateur garde ses droits sur ces fichiers via l'uid. Mais en faisant cette manip, il est possible qu'on donne des droits d'écriture sur certains fichiers/répertoires à l'ensemble des utilisateurs de la machine.

On peut aussi ajouter les utilisateurs manquants au groupe staff... Par exemple pour ajouter "didier" au groupe staff :

CODE

dscl . append Groups/staff GroupMembership didier

Pour vérifier :

CODE

dscl . read Groups/staff GroupMembership
GroupMembership: root Guest test didier

on peut aussi taper la commande "id", en étant connecté en tant que "didier" :

CODE

id
uid=501(didier) gid=501(didier) groups=501(didier),98(_lpadmin),20(staff)

On voit que staff apparaît dans la liste des groupes.

Ce message a été modifié par darenzana - 13 Nov 2007, 20:27.

[footix82]

Bonsoir,

j'ai essayer la méthode darenzana mais j'obtiens l'erreur ci-dessous (d'ailleurs j'aurais mêmpas eu besoin de faire le su non ?) :

CODE

Xavier-Nicolas:~ footix$ su -l footix
Password:
Xavier-Nicolas:~ footix$ dscl . -create Groups/footix RealName footix
<main> attribute status: eDSPermissionError
<dscl_cmd> DS Error: -14120 (eDSPermissionError)
Xavier-Nicolas:~ footix$

Merci pour votre aide.

Footix.

[darenzana]

Effectivement, j'ai oublié de préciser que pour les commandes de modification, il faut faire 'sudo' devant.
Pour ton exemple :

CODE

sudo dscl . -create Groups/footix RealName footix

Auparavant, vérifie quand même que le groupe footix existe bien avec la commande

CODE

dscl . -read Groups/footix

qui doit te lister l'ensemble des attributs du groupe.

[footix82]

Oui là ça fonctionne par contre je ne vois pas de différence..; il faut redémarrer ?

-> Affreux réflexe Windowsien

Merci en tout cas !

Ce message a été modifié par footix82 - 13 Nov 2007, 23:00.

[darenzana]

Oui là ça fonctionne par contre je ne vois pas de différence..; il faut redémarrer ?

-> Affreux réflexe Windowsien

Merci en tout cas !

Chez moi l'effet a été immédiat: en refaisant pomme-I sur un fichier, je n'ai plus eu de groupe "(Inconnu)". Mais peut-être qu'il faut fermer puis rouvrir ta session.

[footix82]

Ca marche à moitié. Certes cela ne plante pas lorsque je veux modifier les droits mais les droits des fichiers ne sont pas changés. En fait je n'arrive pas à supprimer le everyone (qui est avant mon utilisateur dans la liste des utilisateurs avec leurs droits) seuls les répertoires changent de propriétaires... (chown).

Ce message a été modifié par footix82 - 13 Nov 2007, 23:58.

[darenzana]

Tu pourrais mettre une capture d'écran de la fenêtre Infos sur un fichier ou un répertoire problématique?
également, que donne la commande

CODE

ls -led

sur un fichier problématique?
Cette commande va lister l'ensemble des droits étendus (ACL) qui sont appliqués au fichier/répertoire donné en argument.

Ce message a été modifié par darenzana - 14 Nov 2007, 21:12.

[Macoupc]

edit : Bon, je me suis plongé plus longuement dans les posts la citation macfixit plombe tout quand même)
et j'ai réussi à obtenir ça dans le terminal sur un fichier "bloqué" dans le dossier "documents"

CODE

MBP:~ yoann$ ls -l /Users/yoann/Documents/arbre\ de\ ouf.png
-rwxrwxr-x@ 1 yoann  yoann  1429711 14 déc  2006 /Users/yoann/Documents/arbre de ouf.png

Sachant que je ne veux pas faire de dégâts dans mon système, est-ce que qu'une bonne âme pourrait me guider un peu plus ? Je ne vois pas dans quel "groupe" je suis... Il me semble que c'est "yoann"

CODE

MBP:~ yoann$ dscl . -read Groups/yoann
AppleMetaNodeLocation: /Local/Default
GeneratedUID: 794D038D-FAE3-4FBC-80DB-49A299CF91CE
Password: *
PrimaryGroupID: 501
RecordName: yoann
RecordType: dsRecTypeStandard:Groups
MBP:~ yoann$

après je suis paumé,

CODE

-bash: syntax error near unexpected token `('

Merci de votre aide

Ce message a été modifié par Macoupc - 15 Nov 2007, 15:05.

[footix82]

Voila j'ai fait des captures d'écran que voici :




Dans le dernier terminal, sur le ls -l je ne sait pas comment supprimer le "+" (-rwxr-x---+ 1 footix footix ...) qui me demande les mots de passe pour déplacer supprimer.

[footix82]

...

Ce message a été modifié par footix82 - 21 Nov 2007, 09:35.

[darenzana]

@footix82: le '+' indique que des droits étendus (autorisations ou interdictions) sont appliqués. Avant d'essayer de les supprimer, il faut savoir ce que sont ces droits. Pour les lister, il faut utiliser la commande 'ls -le comme je l'ai demandé colle le résultat ici, et on va réfléchir à la légitimité de ces droits.

@Macoupc: le groupe propriétaire du fichier "/Users/yoann/Documents/arbre de ouf.png" est 'yoann' d'après le résultat de ta première commande.
Au vu du résultat de ta 2eme commande, l'enregistrement du groupe 'yoann' n'a pas de clef "RealName", ce qui explique pourquoi le Finder t'indique (Inconnu) dans les propriétés de ce fichier.
Pour corriger le problème, il faut donc ajouter la clef RealName aux informations du groupe, en utilisant la commande:

CODE

sudo dscl . -create Groups/yoann RealName yoann

[footix82]

Hello,

Après avoir récupéré la propriété de mes fichiers avec un chown récursif, j'ai essayé de changer les droits pour ne plus à avoir à mettre un mot de passe à chaque déplacement/suppression de répertoire (les fichiers sont ok). Tous mes fichiers (répertoires compris) ont mon compte en lecture/écriture, nobody en écriture seulement (boite de dépôt) et everyone en accès interdit.

J'ai donc fait un man chmod pour arriver à la commande

CODE

sudo chmod -a "group:everyone deny, delete" lenomdurepertoire

et je n'ai plus de pb sur le répertoire. Je cherche donc à savoir d'une part si c'est propre et si oui comment rendre la commande récursive, car j'ai pas trouvé.

Ci-dessous l'exemple d'un ls -le sur un dossier, que je croyais avoir posté...



J'en déduis qu'il faut un truc du genre chmod +a "group:footix allow delete, write, read" lenomdurepertoire ?

Merci pour ton aide !

Footix

Ce message a été modifié par footix82 - 23 Nov 2007, 13:07.

[darenzana]

Ok, j'ai compris ton problème, et je pense avoir trouvé la cause.

Le probleme: Comme tu l'as remarqué, il y a, sur tous tes fichiers et répertoires, une ACL "everyone deny delete", qui indique que personne, ni meme le propriétaire du fichier, ne peut effacer ce fichier ou répertoire.

La cause: Cette ACL est normalement positionnée uniquement sur les répertoires suivants, dans le répertoire home de chaque utilisateur : Desktop, Documents, Dowloads, Library, Movies, Music, Pictues, Sites, et le home lui-même. C'est probablement un "garde-fou" mis en place pour que l'utilisateur n'efface pas un de ces répertoires essentiels lors d'une fausse manipulation. Je suppose que tu as utilisé la fenêtre infos du Finder pour modifier les permissions sur un de ces répertoires, et utilisé l'option "Appliquer aux éléments inclus". J'ai fait le test, dans ce cas le Finder "recopie" bêtement les droits du répertoire sélectionné à l'ensemble des fichiers et répertoires contenus, donc tout le monde se retrouve avec un "everyone deny delete", ne permettant plus qu'aux administrateurs d'effacer ces fichiers.

Pour résoudre le problème, la comande que tu proposes peut marcher, mais il vaut mieux supprimer l'ACL "deny delete" la ou elle est inutile, ce qui te rendra effectivement le droit de faire ce que tu veux des fichiers qui t'appartienent

Donc je te propose la commande suivante:
Dans le terminal, tappes "cd" sans arguments, pour te placer a la racine de ton home.
ensuite, on va utiliser chmod en mode recursif pour supprimer l'ACL qui nous embête, sur l'ensemble du contenu de ton home:

CODE

chmod -R -a "everyone deny delete" .

ce qui signifie:
-a on supprime une entrée de l'ACL
everyone deny delete l'entree a supprimer
-R mode récursif: appliquer au répertoire en argument, et a tous ses sous répertoires.
. le répertoire auquel appliquer le chmod '.' est le répertoire courant.

edit : en fait il faut utiliser find pour passer dans tous les répertoires :

CODE

find . -exec chmod -a "everyone deny delete" {} \;

Ensuite, on va re-postionner l'ACL "deny delete" sur le répertoire home et Desktop, Documents, etc. Ce n'est pas obligatoire, c'est juste pour remettre en place le "garde-fou" mis en place par Mac OS à la base:

CODE

chmod +a "everyone deny delete" .
chmod +a "everyone deny delete" Desktop

et ainsi de suite avec les autres répertoires que j'ai donné plus haut.

Normalement, les fichiers et répertoires t'appartiennent tous, donc tu ne devrais pas avoir à utiliser "sudo".

Ce message a été modifié par darenzana - 4 Feb 2008, 22:57.

[Rigodon]

Alors oui il y a un problème en cas de mise à jour(ou archiver et installer) vers leopard. C'est à dire que le groupe d'un utilisateur est 20 ou staff maintenant. Donc tous les groupes 501 donc nom_user créés par Tiger apparaissent comme inconnus.

Pour changer ça, il faut aller dans comptes, puis clique droit sur le nom d'utilisateur, puis changer le numéro du groupe pour 20.

Après on exclut ses disques durs dans spotlight et on tape dans le terminal:

CODE

sudo find . -group 501 -exec chgrp 20 {} \;

À la place du point on peut mettre le dossier /Applications par exemple. Le point signifie que la recherche part du répertoire courant.

On le laisse bosser jusqu'au retour du prompt.

Ce message a été modifié par Rigodon - 25 Nov 2007, 21:29.

[darenzana]

Rigodon, non, pas forcément. Relis l'ensemble du fil, j'ai tout expliqué en long, en large, et en travers.

[Rigodon]

Oui ta méthode est bonne aussi ou complémentaire mais dans la mesure ou Leopard après une clean install place les utilisateurs dans staff, je préfère le truc de macfixit.

[darenzana]

Oui, d'accord, je n'avais pas lu la partie 'changer le numéro de groupe pour 20'.

[Rigodon]

On a parfois un @ à côté des droits d'un fichier ou dossier avec la commande ls -l . Je sais que le + c'est pour les ACL.
J'aimerai savoir pourquoi, si tu le sais je suis preneur ?

Ce message a été modifié par Rigodon - 24 Nov 2007, 17:55.

[jujuhtst]

Un fil instructif là :
http://discussions.apple.com/thread.jspa?messageID=5929881
(en anglais ...)

[darenzana]

le @ indique que le fichier a des attributs étendus. On peut voir les attributs avec ls -l@ et ls -lO , et voir leur contenu avec xattr.

[Rigodon]

Merci ! il affiche com.apple.finderinfo mais je ne sais pas à quoi ça correspond.

[Macoupc]

Alors oui il y a un problème en cas de mise à jour(ou archiver et installer) vers leopard. C'est à dire que le groupe d'un utilisateur est 20 ou staff maintenant. Donc tous les groupes 501 donc nom_user créés par Tiger apparaissent comme inconnus.

Pour changer ça, il faut aller dans comptes, puis clique droit sur le nom d'utilisateur, puis changer le numéro du groupe pour 20.

Après on exclut ses disques durs dans spotlight et on tape dans le terminal:

CODE

sudo find . -group 501 -exec chgrp 20 {}\;

À la place du point on peut mettre le dossier /Applications par exemple. Le point signifie que la recherche part du répertoire courant.

On le laisse bosser jusqu'au retour du prompt.

Avec ta solution, en laissant 501 pour l'identifiant utilisateur et en mettant 20 pour l'identifiant du groupe, ça me met dans le terminal

CODE

find: -exec: no terminating ";" or "+"

Tout ça c'est du chinois pour moi... Dès que je me mets à ces problèmes, j'y passe des heures pour ne pas aboutir...

@Macoupc: le groupe propriétaire du fichier "/Users/yoann/Documents/arbre de ouf.png" est 'yoann' d'après le résultat de ta première commande.
Au vu du résultat de ta 2eme commande, l'enregistrement du groupe 'yoann' n'a pas de clef "RealName", ce qui explique pourquoi le Finder t'indique (Inconnu) dans les propriétés de ce fichier.
Pour corriger le problème, il faut donc ajouter la clef RealName aux informations du groupe, en utilisant la commande:

CODE

sudo dscl . -create Groups/yoann RealName yoann

Merci pour ta solution mais la commande n'aboutit sur rien, les autorisations du fichier "arbre de ouf" ne changent pas...

[jujuhtst]

Tout ça c'est du chinois pour moi... Dès que je me mets à ces problèmes, j'y passe des heures pour ne pas aboutir...

C'est ça :

CODE

sudo find . -group 501 -exec chgrp 20 {} \;

Attention à l'espace entre "}" et "\"

Par contre faut bien être sûr que le groupe est 501, car chez moi c'était 502 ...

[Rigodon]

Tout ça c'est du chinois pour moi... Dès que je me mets à ces problèmes, j'y passe des heures pour ne pas aboutir...

C'est ça :

CODE

sudo find . -group 501 -exec chgrp 20 {} \;

Attention à l'espace entre "}" et "\"

Par contre faut bien être sûr que le groupe est 501, car chez moi c'était 502 ...

Oui désolé pour l'espace, et 501 c'est pour le premier utilisateur créé, après il faut incrémenter de 1.

[footix82]

Donc je te propose la commande suivante:
Dans le terminal, tappes "cd" sans arguments, pour te placer a la racine de ton home.
ensuite, on va utiliser chmod en mode recursif pour supprimer l'ACL qui nous embête, sur l'ensemble du contenu de ton home:

CODE

chmod -R -a "everyone deny delete" .

ce qui signifie:
-a on supprime une entrée de l'ACL
everyone deny delete l'entree a supprimer
-R mode récursif: appliquer au répertoire en argument, et a tous ses sous répertoires.
. le répertoire auquel appliquer le chmod '.' est le répertoire courant.

Ensuite, on va re-postionner l'ACL "deny delete" sur le répertoire home et Desktop, Documents, etc. Ce n'est pas obligatoire, c'est juste pour remettre en place le "garde-fou" mis en place par Mac OS à la base:

CODE

chmod +a "everyone deny delete" .
chmod +a "everyone deny delete" Desktop

et ainsi de suite avec les autres répertoires que j'ai donné plus haut.

Normalement, les fichiers et répertoires t'appartiennent tous, donc tu ne devrais pas avoir à utiliser "sudo".

Merci pour ta réponse

J'ai fait la commande pour supprimer l'ACL mais il me répond qu'il n'y a pas d'ACL présent...

chmod:no ACL present

et cela que je me place sur home, Documents, Séquences, ..., ou sur un dossier perso
d'ailleurs chose encore plus bizarre si je mets la commande pour un seul répertoire il me met le même message mais supprime l'ACL, alors que dans le cas du récursif il ne fait rien !

Enfin c'est bizarre...

Footix

[Macoupc]

Tout ça c'est du chinois pour moi... Dès que je me mets à ces problèmes, j'y passe des heures pour ne pas aboutir...

C'est ça :

CODE

sudo find . -group 501 -exec chgrp 20 {} \;

Attention à l'espace entre "}" et "\"

Par contre faut bien être sûr que le groupe est 501, car chez moi c'était 502 ...

Sans espace :

CODE

MBP:~ yoann$ sudo find . -group 501 -exec chgrp 20 {}\;
Password:
find: -exec: no terminating ";" or "+"
MBP:~ yoann$

Je crois que c'est bon pour 501 et pas 502 car il n'y a qu'un utilisateur

[jujuhtst]

Sans espace :

Il en faut justement un !

Je crois que c'est bon pour 501 et pas 502 car il n'y a qu'un utilisateur

Pas forcément, par exemple si un utilisateur a été viré (le cas sur ma machine)

[Macoupc]

Sans espace :

Il en faut justement un !

Ok j'avais essayé mais c'était peut être sans espace la première fois, j'ai corrigé la correction...
Maintenant ça marche, "inconnu" est passé à "staff" mais l'exemple que j'avais pris, dans les documents n'est toujours pas jetable à la poubelle si facilement... Il faut toujours faire un code.

[Rigodon]

ça vient du "everyone deny delete" donc c normal.
chmod -a "everyone deny delete" foldername

[Macoupc]

ça vient du "everyone deny delete" donc c normal.
chmod -a "everyone deny delete" foldername

C'est à dire ? Je tape ça dans le terminal pour régler le problème ?

[Rigodon]

Oui tu peux voir les ACL avec :

CODE

ls -le

Si tu vois des everyone deny delete c'est qu'une acl t'empêche d'effacer un dossier.
donc pour supprimer l'acl du dossier Documents par exemple(il faut respecter les majuscules dans les dossiers) :

CODE

sudo chmod -a "everyone deny delete" Documents

Ce message a été modifié par Rigodon - 27 Nov 2007, 00:28.

[Macoupc]

Oui tu peux voir les ACL avec :

CODE

ls -le

Si tu vois des everyone deny delete c'est qu'une acl t'empêche d'effacer un dossier.
donc pour supprimer l'acl du dossier Documents par exemple(il faut respecter les majuscules dans les dossiers) :

CODE

sudo chmod -a "everyone deny delete" Documents

Merci !!! De traduire tous ces codes très obscurs encore.
Je peux enfin disposer de mes fichiers dans le dossier "Documents"
Les ACL, c'est les trucs impossibles à réparer avec une réparation des autorisations ?

Voilà ce que me donne la commande

CODE

ls -le

CODE

MBP:~ yoann$ ls -le
total 88
drwxrwxr-x+  43 yoann  staff   1462 26 nov 14:32 Desktop
0: group:everyone deny delete
drwxrwxr-x  325 yoann  staff  11050 27 nov 00:47 Documents
drwxrwxr-x+  12 yoann  staff    408 26 nov 13:41 Downloads
0: group:everyone deny delete
-rwxrwxr-x@   1 yoann  staff      0 31 oct 23:25 Icon?
drwxrwxr-x+  44 yoann  staff   1496 17 nov 01:41 Library
0: group:everyone deny delete
drwxrwxr-x@  39 yoann  staff   1326 19 nov 21:55 Malaquais
0: user:yoann allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxr-x@  41 yoann  staff   1394 15 nov 14:33 Movies
0: group:everyone deny delete
drwxrwxr-x+   9 yoann  staff    306 12 nov 00:47 Music
0: group:everyone deny delete
drwxrwxr-x@   8 yoann  staff    272 12 nov 03:35 PROJETS
drwxrwxr-x@  13 yoann  staff    442  6 nov 02:54 Photos
drwxrwxr-x+ 775 yoann  staff  26350 17 nov 14:09 Pictures
0: group:everyone deny delete
drwxrwxr-x+   4 yoann  staff    136 31 oct 23:02 Public
0: group:everyone deny delete
drwxrwxr-x+   4 yoann  staff    136 31 oct 23:27 Sites
0: group:everyone deny delete
drwxrwxr-x@  26 yoann  staff    884 26 sep 18:20 logement
0: user:yoann allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity
drwxrwxr-x@  43 yoann  staff   1462 28 aoû 23:42 un jour peut-être
-rw-r--r--    1 yoann  staff   6136 26 nov 13:43 vpd.properties

Sur certains dossiers, il y a 2 fois "Yoann" et impossible d'en supprimer un.
Mes quelques essais de changement des autorisations n'ont pas été très concluants...
J'arrive au bout, grâce à vous.

[darenzana]

J'ai fait la commande pour supprimer l'ACL mais il me répond qu'il n'y a pas d'ACL présent...

chmod:no ACL present

et cela que je me place sur home, Documents, Séquences, ..., ou sur un dossier perso
d'ailleurs chose encore plus bizarre si je mets la commande pour un seul répertoire il me met le même message mais supprime l'ACL, alors que dans le cas du récursif il ne fait rien !

Enfin c'est bizarre...

Footix

Effectivement, il a l'air assez capricieux chmod en recursif.. Si on le lance sur un repertoire qui n'a pas d'ACL il ne va pas aller chercher plus loin. J'avais fait le test sur un repertoire dont tout le contenu correspondait bien. J'ai l'impression qu'il s'arrête des qu'il trouve un répertoire sans ACL.

Pour résoudre le pb de manière radicale, et être sur de ne rien oublier, on peut faire la chose suivante dans un répertoire :

CODE

find . -exec chmod -a "everyone deny delete" {} \;

ce qui va lancer la commande chmod sur chaque fichier et sous repertoire du repertoire courant. On aura plein de messages "chmod: No ACL present" ; mais on est sur que pour les fichiers/repertoires qui avaient cette entrée dans leur ACL, elle sera supprimée .

Ce message a été modifié par darenzana - 27 Nov 2007, 01:21.

[Rigodon]

Mais cette entrée est là pour des raisons de sécurité, donc il faut bien penser à la restaurer. De toute façon elle n'est présente que sur les dossiers à la racine de ton dossier de départ je crois, et elle ne t'empêche pas de supprimer leur contenu.

Pour les dossiers comprenant deux fois ton nom je n'ai pas bien compris ta question. Mais il existe une ACL "deny delete_child" qui empêche la suppression des sous-dossiers. D'après ce que je vois, il y a surtout des "allow".

Réparer les autorisations ne sert qu'à restaurer les autorisations par défaut des dossiers "système et bibliothèques", il se base sur le dossier receipts dans /Bibliothèques je crois. Cette fonction n'aurait aucune utilité si il n'y avait pas des logiciels comme adobe flash player qui modifient n'importe quoi. A partir du moment où tu rentres ton mot de passe administrateur, un programme d'installation peut tout bousiller dans une arborescence.

Sinon, tes dossiers sont en 775 ce qui n'est pas terrible car les membres du groupe staff ont tous accès à tes dossiers personnels. La plupart des miens sont en 700. Pour éviter les problèmes c'est mieux de limiter les droits que de les ouvrir à tout le monde.

Ce message a été modifié par Rigodon - 27 Nov 2007, 11:43.

[Macoupc]

J'ai fait le code

CODE

MBP:~ yoann$ find . -exec chmod -a "everyone deny delete" {} \

;
pour les ACL et un fichier texte a été créé sur le bureau (Audit report.txt), je ne sais pas si c'est ça :

3395 objects audited
Total errors found during audit 0, fixed 0

Mais la liste était longue... Ça mettait deux choses seulement

chmod: Entry not found when attempting delete
chmod: No ACL present

Il y a toujours 2 fois "Yoann" dans des dossiers. Mais je ne sais pas si c'est grave.

[Rigodon]

Tu as sûrement restauré le groupe yoann donc ce n'est pas grave. De toute façon, le but des droits et ACL est d'administrer un ordinateur. Pour un utilisateur simple en session unique tu n'as même pas de notion de groupe. Donc, pour ta culture personnelle tu peux creuser mais au quotidien tu n'en auras pas l'utilité.

http://www.multios.com/linhelp/droits.html

As-tu pensé à mettre sudo devant ta commande ?

Ce message a été modifié par Rigodon - 27 Nov 2007, 13:46.

[darenzana]

Le sudo ne devrait pas être nécessaire, l'utilisateur yoann s'est deja approprié l'ensemble de ses fichiers (Message 9).

Le fichier "audit Report.txt" n'a rien a voir avec la commande chmod; il doit venir d'ailleurs.

ça veut dire quoi "il y a 2 fois Yoann"? Dans les infos du finder, ou dans un ls -l? Comme l'indique Rigodon, certains dossiers doivent toujours avoir comme groupe Yoann. Mais normalement il devraient tous être dans le groupe satff, vu la commande chgrp effectuée auparavant...

Au final, tu peux effacer tes fichiers come tu veux?

Pour approfondir ces notions, pas forcément évidentes, Apple a mis en ligne un dossier très complet sur ce sujet et d'autres : "File Services Administration" (en anglais). Le chapitre 2 "setting up file service permissions" est très instructif.
Le fichier pdf : http://images.apple.com/server/macosx/docs...Admin_v10.5.pdf
La page d'Apple sur Mac OS X Server, qui contient plein de docs intéressantes pour qui veut savoir ce qui se passe au coeur du système : http://www.apple.com/server/macosx/resources/

[footix82]

Pour résoudre le pb de manière radicale, et être sur de ne rien oublier, on peut faire la chose suivante dans un répertoire :

CODE

find . -exec chmod -a "everyone deny delete" {} \;

ce qui va lancer la commande chmod sur chaque fichier et sous repertoire du repertoire courant. On aura plein de messages "chmod: No ACL present" ; mais on est sur que pour les fichiers/repertoires qui avaient cette entrée dans leur ACL, elle sera supprimée .

Merci Darenzana, ca marche du tonnerre

[Macoupc]

Le sudo ne devrait pas être nécessaire, l'utilisateur yoann s'est deja approprié l'ensemble de ses fichiers (Message 9).
ça veut dire quoi "il y a 2 fois Yoann"? Dans les infos du finder, ou dans un ls -l? Comme l'indique Rigodon, certains dossiers doivent toujours avoir comme groupe Yoann. Mais normalement il devraient tous être dans le groupe staff, vu la commande chgrp effectuée auparavant...

Grâce à la commande "everyone any delete" la plupart des fichiers sont dans le groupe staff.

Il y a 2 fois yoann dans les infos du finder pour quelques applications... Ça fait pas propre. Et quand j'essaie "à la main" dans le finder d'ajouter le groupe "staff" par exemple, ça ne marche pas et ça relance le finder sans que j'ai rien demandé...


Je peux "disposer" de mes fichiers mais je dois pour les applications par exemple, taper mon mot de passe admin si je veux les supprimer. Ça pose des problèmes aussi pour certaines mises à jour qui refusent de s'installer, sûrement car le protocole "demander mot de passe" n'a pas été programmé.

[Perklo]

Bonjour,

Voilà l'ignorant de service...

J'aimerais savoir à quoi correspond le groupe "staff" exactement. Quels sont les utilisateurs qui lui appartiennent? Quels sont les prérogatives de ce groupe?

Merci :-)

[steenux]

Bonjour,

J'ai ouvert un autre fil sur le même sujet avant de trouver celui là :
http://forum.macbidouille.com/index.php?showtopic=246963#

Je pense avoir trouvé les réponses pour copier les fichiers récalcitrants et enfin récupérer mes bibliothèques.
Je les essayes dès a\que je rentre chez moi.

Toute cette lecture est très interressante et instructive, mais attention, on peut faire plus de dégat que de réparation

[Macoupc]

Bonjour,

J'ai ouvert un autre fil sur le même sujet avant de trouver celui là :
http://forum.macbidouille.com/index.php?showtopic=246963#

Je pense avoir trouvé les réponses pour copier les fichiers récalcitrants et enfin récupérer mes bibliothèques.
Je les essayes dès que je rentre chez moi.

Toute cette lecture est très interressante et instructive, mais attention, on peut faire plus de dégat que de réparation

C'est étrange, t'as la même image d'avatar qu'un autre membre du forum (que je ne connais pas plus que ça) mais les questions que tu poses paraissaient un peu trop évidentes pour ce membre... Enfin voilà, remarque inutile.

[steenux]

Désolé pour l'avatar, mais quand je me suis inscrit sur le site, il me plaisait bien et était dispo sur le site...

[steenux]

Bonsoir,

En cherchant des infos sur l'utilisation des ACL, j'ai lu sur un site que de faire une archive .tar enlevait les ACL sur les fichiers et dossiers.

Je ne sais pas si c'est exact, mais j'ai enfin pu récupérer mes photos et musiques sauvegardées sur un disque externe en créant un .tar.gz sur le disque interne et réimportations dans les bibliothèques iTunes et iPhotos sans problème.

Si sa peut en aider d'autre...

EDIT : Voici le lien <http://www.commentcamarche.net/faq/sujet-3773-securite-les-access-control-lists-acls>

Ce message a été modifié par steenux - 9 Dec 2007, 15:28.

[Joël Pierre]

J’ai aussi des problème bizarres avec les autorisations de Leopard. Tous le contenu de mes dossiers utilisateur privés (Bibliothèque, Documents, Images, Musique, Séquences) ne peuvent être mis à la corbeille que si je donne mon mot de passe de session (je suis administrateur). Les nouveaux fichiers créés dans ces dossiers peuvent en revanche être mis à la corbeille sans autorisation. J’ai réparé à plusieurs reprises les autorisations (avec Utilitaire de disque et Terminal) sans aucun changement. J’ai aussi des problème avec les préférences de Photoshop (en quittant, un message me dit que les préférences n’ont pu être enregistrées, faute de droit suffisants). J’ai déjà supprimé les fichiers de préférences de Photoshop (les nouveaux fichiers se laissant modifier). Mais après quelques temps, rebelote.

Comment devraient être les droits sur ces dossiers ?

[Rigodon]

Si le système te demande ton mot de passe c'est que tu n'es pas propriétaire des fichiers, donc il te faut des droits root(que tu as en étant dans le groupe admin). Décris-nous ta méthode d'installation de Leopard.

[Joël Pierre]

Si le système te demande ton mot de passe c'est que tu n'es pas propriétaire des fichiers, donc il te faut des droits root(que tu as en étant dans le groupe admin). Décris-nous ta méthode d'installation de Leopard.

Mais si je suis propriétaire des fichiers et dossiers (un cmd I sur chacun me le confirme). Et c'est justement pour cela qu'il me demande de confirmer mes droits (comme les installateurs de logiciels).

J’ai fait mon installation de manière très orthodoxe avec le DVD d’installation sur une partition effacée au préalable.

J’ajoute que j’ai eu les même soucis sur une autre partition qui ne possède pas de système et dont les droits ne sont théoriquement pas gérés. Puisque que le système (Utilitaire de disque ou Terminal sont incapables de rétablir des droits conformes, je vous demande comment le faire manuellement avec Batchmod.

Quels devraient donc être théoriquement les R W X pour le Possesseur (Moi), Groupe (staff) et Tous (everyone) ?

Ce message a été modifié par Joël Pierre - 2 Jan 2008, 22:57.

[darenzana]

Bonjour,
je pense que ton problème est lié aux droits étendus, et Batchmod ne pourra pas t'aider dans ce cas.
Ouvre un Terminal, et tape dedans la commande:

CODE

ls -le Documents

et colle le résultat ici.

si tu vois des "everyone deny delete" ton probleme est bien lié aux ACL, et il te faudra utiliser la commande find que je donne en haut de cette page.
Pour les détails tu peux lire ce message.

Ce message a été modifié par darenzana - 2 Jan 2008, 23:15.

[Joël Pierre]

Je pense que ton problème est lié aux droits étendus, et Batchmod ne pourra pas t'aider dans ce cas.
Ouvre un Terminal, et tape dedans la commande:

CODE

ls -le Documents

et colle le résultat ici. Si tu vois des "everyone deny delete" ton probleme est bien lié aux ACL, et il te faudra utiliser la commande find que je donne en haut de cette page.

C’est bien cela . J’ai fait find . -exec chmod -a "everyone deny delete" {} \; comme préconisé et j’ai les 0: group:everyone deny delete

En faisant find . -exec chmod -a "everyone deny delete" {} \;, j’ai plein de chmod: No ACL present et quelques chmod: Failed to set ACL on file './Documents/xxxxxx.xxx': Operation not permitted sur des fichiers verrouillés. Et un chmod: Entry not found when attempting delete

Tout semble apparement revenu à la normale.

Merci.

J’ai refais ensuite une réparation des autorisations avec Utilitaire de disque.

Voici ce qu’il trouve :

ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.
Le groupe est différent sur « Library/PreferencePanes », il devrait être 0 au lieu de 80.
Les autorisations sont différentes sur « Library/PreferencePanes », elles devraient être drwxr-xr-x au lieu de drwxrwxr-x .
ACL trouvé mais non prétendu sur « Library ».
Pour ARDAgent, cela semble un bug d’Apple, mais les pour Preferences Panes ?
Et un ACL trouvé mais non prétendu. Qu’est-ce ?



Ce message a été modifié par Joël Pierre - 3 Jan 2008, 10:29.

[darenzana]

Il me semble que la réparation des autorisations ne touche pas aux fichier de ton dossier utilisateur, mais uniquement aux fichiers système, donc je pense que les messages que tu obtiens ne sont pas liés au problème précédent...

Tu as probablement installé un logiciel qui ajoute un module dans les préférences, et qui a modifié les droits sur le répertoire "/Library/PrerencePanes" ce faisant. Et donc la réparation des autorisations a corrigé ce point.

Pour le "ACL trouvé mais non prétendu" je ne sais pas trop.. Que donne 'ls -led /Library' ?

[Joël Pierre]

Pour le "ACL trouvé mais non prétendu" je ne sais pas trop.. Que donne 'ls -led /Library' ?

G5:~ joel$ ls -led /Library
drwxrwxr-t@ 65 root admin 2210 2 jan 15:31 /Library
0: group:everyone deny delete

[darenzana]

J'ai les mêmes droits sur /Library... On va dire que c'est pas grave non plus.

[steenux]

Moi, je n'ai pas exactement les mêmes droits que vous, par contre, OK pour les ACL.

Voila le résultat d'un ls -le sur mon répertoire home :
iMac:~ steve$ lle
rwx------+ 4 steve staff 136 2 jan 12:13 Desktop/
0: group:everyone deny delete
drwx------+ 51 steve staff 1734 30 déc 17:01 Documents/
0: group:everyone deny delete
drwx------+ 22 steve staff 748 5 jan 09:53 Downloads/
0: group:everyone deny delete
drwx------+ 47 steve staff 1598 30 déc 17:05 Library/
0: group:everyone deny delete
drwx------+ 7 steve staff 238 29 déc 18:35 Movies/
0: group:everyone deny delete
drwx------+ 5 steve staff 170 9 déc 11:05 Music/
0: group:everyone deny delete
rwx------+ 6 steve staff 204 22 déc 14:44 Pictures/
0: group:everyone deny delete
drwxr-xr-x+ 6 steve staff 204 6 déc 23:44 Public/
0: group:everyone deny delete
drwxr-xr-x+ 5 steve staff 170 6 déc 17:00 Sites/
0: group:everyone deny delete

A part "Sites" et "Public", les autres répertoires ont des droits à 700+ alors que les vôtres sont à 77?@

Apparemment, les miens sont plus restrictifs mais je ne connais pas la signification du "t@" à la fin de tes droits.

--EDIT--

Après une recherche sur le net, le "t" à la fin des droits indique qu'un "Sticky bit" est positionné sur le répertoire. Il permet d'interdire à tout utilisateur (sauf le root) de supprimer un fichier dont il n'est pas le propriétaire, quelque soient ses droits.
Je trouve que c'est un peu redondant avec les ACL qui indiquent que personne du groupe ne peut supprimer de fichiers ...

Mon répertoire Library/Preferences à les mêmes droits que mes autres répertoires :
rwx------+ 141 steve staff 4794 5 jan 17:54 Preferences/
0: group:everyone deny delete


Je retourne faire une recherche sur la signification du "+" et "@". Je crois que ça va avec les ACL mais je n'en suis pas sure.

Ce message a été modifié par steenux - 5 Jan 2008, 18:19.

[darenzana]

Moi, je n'ai pas exactement les mêmes droits que vous, par contre, OK pour les ACL.

Voila le résultat d'un ls -le sur mon répertoire home :

A part "Sites" et "Public", les autres répertoires ont des droits à 700+ alors que les vôtres sont à 77?@

Apparemment, les miens sont plus restrictifs mais je ne connais pas la signification du "t@" à la fin de tes droits.

Tu parles des répertoires de ton home, alors qu'on parlait du répertoire /Library, situé à la racine, et pas dans un home utilisateur.
Les droits sont effectivement plus restreints dans les répertoires utilisateurs.
Le 't' indique que le 'sticky-bit' est positionné, ce qui change le comportement lors de l'effacement d'un fichier,
et le @ indique des attributs positionnés (par le Finder en général).

[steenux]

Exact, j'avais mal lu, je possède bien les mêmes droits que vous sur /Library.

Désolé pour le bruit

[Rigodon]

Le + veut dire qu'une acl existe sur le fichier ou dossier. Par défaut Leo met les droits du home sur 700 en everyone deny delete. Donc tu es ok.

[darenzana]

Après une recherche sur le net, le "t" à la fin des droits indique qu'un "Sticky bit" est positionné sur le répertoire. Il permet d'interdire à tout utilisateur (sauf le root) de supprimer un fichier dont il n'est pas le propriétaire, quelque soient ses droits.
Je trouve que c'est un peu redondant avec les ACL qui indiquent que personne du groupe ne peut supprimer de fichiers ...

Ce n'est pas redondant, l'ACL 'everyone deny delete' est positionnée sur le répertoire /Library, et pas sur les fichiers qui sont dedans (elle n'est pas héritée). Donc elle interdit juste à tout le monde d'effacer le répertoire /Library, mais pas ses fichiers. Un membre du groupe admin pourrait effacer n'importe quel fichier ou répertoire à l'intérieur de /Library (sans utiliser sudo) si le bit t n'était pas positionné. Et si on faisait hériter l'ACL everyone deny delete au contenu de /Library, on n'aurait pas non plus le comportement voulu, puisque même le propriétaire d'un fichier ne pourrait pas l'effacer.

[steenux]

OK, merci pour ces explications.

Je pense comprendre un peu mieux les ACL. Si je me résume, une ACL agit sur le répertoire et uniquement lui, alors que le sticky bit agit sur les fichiers contenus dans ce répertoire ?


Je cherche toujours la signification du @ et + à la fin de l'information sur les droits.
J'ai bien trouvé que le + indiquait que le fichier ou le répertoire avait des droits étendus.
En lisant le man ls de léo, je crois comprendre que le @ veut dire qu'il y a des attributs étendus alors que le + indique une information de sécurité étendu ???

Je ne comprends pas bien la différence. Je vois bien la signification du + mais Darenzana m'indique que le @ indique des attributs positionnés (par le Finder en général). Et là, je ne comprends pas bien à quoi ça correspond ?

[darenzana]

Je pense comprendre un peu mieux les ACL. Si je me résume, une ACL agit sur le répertoire et uniquement lui, alors que le sticky bit agit sur les fichiers contenus dans ce répertoire ?

En ce qui concerne le répertoire /Library, oui.
Dans le cas général, une ACL peut contenir des droits qui seront hérités par les fichiers contenus dans le répertoire, tout dépend de ce qu'on veut faire. Apple a mis en ligne un dossier très complet sur ce sujet et d'autres : "File Services Administration" (en anglais). Le chapitre 2 "setting up file service permissions" est très instructif.
Le fichier pdf : http://images.apple.com/server/macosx/docs...Admin_v10.5.pdf

Je ne comprends pas bien la différence. Je vois bien la signification du + mais Darenzana m'indique que le @ indique des attributs positionnés (par le Finder en général). Et là, je ne comprends pas bien à quoi ça correspond ?

Par exemple, quand un répertoire doit être invisible dans le Finder, le système positionne le flag 'hidden' sur ce répertoire. Ce flag est stocké dans l'attibut "com.apple.FindeInfo" qui est alors attribué au fichier. Si on prend le cas de /usr, on peut le voir comme ça :

CODE

$ ls -led /usr
drwxr-xr-x@ 13 root  wheel  442 13 déc 02:28 /usr/

Le '@' m'indique des attributs étendus. Quels sont ils?

CODE

ls -l@d /usr
drwxr-xr-x@ 13 root  wheel  442 13 déc 02:28 /usr/
    com.apple.FinderInfo     32

Il y a donc un attribut "com.apple.FinderInfo" de taille 32. Continuons les recherches:

CODE

ls -lOd /usr
drwxr-xr-x@ 13 root  wheel  hidden 442 13 déc 02:28 /usr/

On voit que le flag hidden est positionné.
Pour aller plus loin, on peut aussi utiliser xattr:

CODE

$ xattr -l /usr
com.apple.FinderInfo:
0000   00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00    ........@.......
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

xattr "dumpe" le contenu de l'attribut. On peut conclure des résulats précédents que le flag hidden est situé à l'octet numero 8 dans l'attribut com.apple.FinderInfo.

Un autre exemple:
Je créé dans mon répertoire Documents un fichier toto.txt, avec TextEdit:

CODE

ls -l@ toto.txt
-rw-r--r--@ 1 didier  didier  6  6 jan 13:50 toto.txt
    com.apple.TextEncoding    15

Mon fichier contient déja un attribut "com.apple.TextEncoding", de taille 15. Cet attribut contient le contenu du champ "Encodage format Texte" que l'on renseigne au moment de l'enregistrement.

CODE

xattr -l toto.txt
com.apple.TextEncoding: UTF-8;134217984

On voit que j'ai choisi "UTF-8" comme encodage.
Maintenant, je fais pomme-I sur le fichier dans le Finder, et lui attribue une étiquette rouge.
de retour dans le Terminal, je regarde à nouveau mon fichier :

CODE

$ ls -l@ toto.txt
-rw-r--r--@ 1 didier  didier  6  6 jan 13:50 toto.txt
    com.apple.FinderInfo    32
    com.apple.TextEncoding    15

Il y a toujours l'attribut com.apple.TextEncoding, et un attribut com.apple.FinderInfo a été ajouté. Voyons son contenu:

CODE

$ xattr -pl com.apple.FinderInfo toto.txt
com.apple.FinderInfo:
0000   00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00    ................
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Donc l'étiquette 'Rouge' correspond à la valeur '0C' stockée dans l'octet numero 9 de l'atribut com.apple.FinderInfo.

Ce message a été modifié par darenzana - 6 Jan 2008, 14:02.

[stefhan]

Bonjour,

Je viens poster ici parce que je n'ai pas réussi à résoudre un soucis qui affecte mon mac depuis mon passage en 10.5.1. En effet :

- je ne peux plus lancer des applications ne peuvent plus se mettre à jour dont WoW : "Le fichier "/Applications/World of Warcraft/Background Downloader.app/Contents/MacOS/Blizzard Downloader" est en lecture seule et ne peut pas être mis à jour." alors qu'il a tous les droits "Lecture et écriture" !

- je ne peux plus sauver mes documents : CSSEdit ne peut plus sauver les fichiers CSS sur lesquels je travaille, il me propose sans cesse "Do you want to overwrite it anyway?" et "You do not have appropriate access privileges to save file “prismavilla.css” in folder “css”. To view or change access privileges, select the item in Finder and choose File > Get Info."

- à chaque suppression de fichiers, Finder me demande systématiquement le mot de passe de la session.


Ayant vu de rares réponses traitant de ce problème sur les forums mac :
- j'ai réparé les autorisations
- j'ai réinstallé la 10.5.1 via le site d'Apple

Je ne souhaiterai pas en arriver à formater mon mac !
Mac livré sous Leopard donc pas de problème de migration.
Problème uniquement apparu depuis la MAJ en 10.5.1 (avant je bossais très bien sous CSSEdit !).

Merci !

[steenux]

@darenzana:
Merci beaucoup pour cette explication détaillée

Je comprends mieux maintenant la différence entre le "@" et le "+", "Attributs étendus" et "ACL" qui sont deux choses complètements différentes.

[el Charlot]

Bonjour, je post ici mon problème, similaire, des ACL, sauf que c'est sur le dossier /private, et que je n'arrive pas a faire vos manips dessus, quelqu'un peut me donner un conseil ? merci

CODE

ACL trouvé mais non prétendu sur « private/var/root/Library/Preferences ».
ACL trouvé mais non prétendu sur « private/var/root/Library ».
ACL trouvé mais non prétendu sur « private/var/root ».

[darenzana]

Bonjour, je post ici mon problème, similaire, des ACL, sauf que c'est sur le dossier /private, et que je n'arrive pas a faire vos manips dessus, quelqu'un peut me donner un conseil ? merci

CODE

ACL trouvé mais non prétendu sur « private/var/root/Library/Preferences ».
ACL trouvé mais non prétendu sur « private/var/root/Library ».
ACL trouvé mais non prétendu sur « private/var/root ».

La manip que j'ai donnée à Joël Pierre face au même problème est : "on va dire que c'est pas grave non plus." Comment tu fais pour ne pas réussir à ne rien faire?
Tu as constaté des problèmes à l'utilisation?

Ce message a été modifié par darenzana - 10 Jan 2008, 20:50.

[Rigodon]

J'ai un problème étrange. J'ai effacé le groupe hérité de tiger qui a le même nom que l'utilisateur mais en installant perian je me suis aperçu qu'il avait créé des fichiers avec ce groupe comme propriétaire. Comment savoir si il en reste encore une trace?

[Rigodon]

Je viens de remarquer que l'utilisateur n'est pas dans le groupe staff. Quelle est la commande pour le mettre dans ce groupe ?

Apparemment ça a marché avec :
sudo dscl . create /groups/staff GroupMembership user

[darenzana]

Je viens de remarquer que l'utilisateur n'est pas dans le groupe staff. Quelle est la commande pour le mettre dans ce groupe ?

Apparemment ça a marché avec :
sudo dscl . create /groups/staff GroupMembership user

mmm pas bien ça, il fallait faire append, et non create. La tu as supprimé la liste des utilisateurs du groupe, en mettant juste le tien à la place. Tu devrais à nouveau ajouter l'ensemble des utilisateurs avec append.

J'ai un problème étrange. J'ai effacé le groupe hérité de tiger qui a le même nom que l'utilisateur mais en installant perian je me suis aperçu qu'il avait créé des fichiers avec ce groupe comme propriétaire. Comment savoir si il en reste encore une trace?

Tu avais bien modifié les propriétés de ton utilisateur pour le mettre dans le groupe staff, puis redémarré?
Tu as cherché avec 'find' si il n'existait plus aucun fichier avec le groupe en question?

Sinon, autre hypothèse, l'installateur de Perian est peut-être mal fichu et créé des fichiers avec le groupe d'id 501 de toutes façons...

[Rigodon]

Je crois que le problème vient de perian effectivement. Sinon pour create ce n'est pas grave car je n'ai qu'un utilisateur dans staff. J'ai trouvé append après.

[Rigodon]

Quel est l'intérêt de rajouter GroupMembers ?

[Joël Pierre]

J’ai un nouveau problème d’autorisations bizarre et pénible :

Sans que je modifie quoi que ce soit (je n’ai pas touché aux autorisations), mon volume de démarrage m’est interdit et les autorisations ne sont pas modifiables et réparables (ni par le Finder, ni par Utilitaire de disque, ni par Terminal (sudo diskutil repairPermissions /). Utilitaire de disque ou Terminal ne trouvent rien d’anormal.





Je n’ai accès qu’à ma session. Tout fonctionne normalement à l’intérieur de celle-ci.

Comment retrouver l’état initial des autorisations ?

[Rigodon]

Dans le terminal :
sudo chmod 775 (glisser-déposer le disque de démarrage puis valider puis mot de passe)

[Joël Pierre]

Dans le terminal :
sudo chmod 775 (glisser-déposer le disque de démarrage puis valider puis mot de passe)

Grand merci. C’est merveilleux. Tout semble revenu à la normale avec cette formule magique.

Mais qu’est-ce qui a bien pu se passer qui modifie ainsi les autorisations et pourquoi Utilitaire de disque est incapable de les réparer ?

[stefhan]

C'est de pire en pire chez moi : dès que je fais un déplacement ou que je tente d'écraser un fichier, Finder me demande à tout bout de champs mon mot de passe. C'est usant...

Vais formater bientôt mon mac : j'espère qu'en recopiant les dossiers sur un autre disque, le problème disparaîtra...

[Rigodon]

Dans le terminal :
sudo chmod 775 (glisser-déposer le disque de démarrage puis valider puis mot de passe)

Grand merci. C’est merveilleux. Tout semble revenu à la normale avec cette formule magique.

Mais qu’est-ce qui a bien pu se passer qui modifie ainsi les autorisations et pourquoi Utilitaire de disque est incapable de les réparer ?

Utilitaire de disque rétablit certaines autorisations mais pas toutes heureusement, sinon on ne pourrait pas faire d'exceptions. Je ne sais pas ce qui a pu faire ça par contre.

C'est de pire en pire chez moi : dès que je fais un déplacement ou que je tente d'écraser un fichier, Finder me demande à tout bout de champs mon mot de passe. C'est usant...

Vais formater bientôt mon mac : j'espère qu'en recopiant les dossiers sur un autre disque, le problème disparaîtra...

Donne-nous plus de détails ça t'évitera sûrement de reformater. Où se trouve ces fichiers ou dossiers par exemple?

[darenzana]

Pareil que la?

[stefhan]

Pareil que la?

Ok je fais ça tout de suite.
J'ai quitté toutes les applications sauf Terminal et Safari.
Je reviens...



RAAAAAAH MERCI !!
Tout est revenu dans l'ordre !
Il faut épingler ton sujet de toute urgence pour tout le monde.

Mon problème était venu du fait que je bossais sur mes sites dans le dossier ~/Sites : arrivé un jour que je ne pouvais plus rien renommer ou déplacer voire supprimer sans devoir mettre le mot de passe de ma session... Et pensant bien faire, j'ai attribué tout mes "droits" au dossier ~/Sites ; ce qui est visiblement une bêtise...

Autre question : je dois faire de même sur les autres Volumes ? J'ai 3 disques durs externes et un iPod que je branche de temps en temps...

Je termine en posant la même question que Joël Pierre :

Mais qu’est-ce qui a bien pu se passer qui modifie ainsi les autorisations et pourquoi Utilitaire de disque est incapable de les réparer ?

Merci pour votre réponse...
Et encore merci pour la solution !

[Rigodon]

La réponse est dans son post :

"Notament, le dossier "Claude" (qui si j'ai bien compris, est ta "petite maison", /Users/Claude), est affublé d'une ACL interdisant à quiconque de le supprimer. En "appliquant à tous les éléments inclus", tu as propagé cette propriété à l'ensemble des fichiers et répertoires de ton home, ce qui fait que tu ne peux plus supprimer aucun fichier sans donner le mot de passe administrateur."

Donc pas besoin de le faire sur les autres volumes.

Ce message a été modifié par Rigodon - 11 Feb 2008, 01:17.

[stefhan]

J'avais pas tout compris...
Merci !