Mac Server app : Les utilisateurs du réseau disposent des autorisations appropriées, mais les groupes du réseau ne peuvent pas modifier les fichiers.

De https://discussions.apple.com/thread/3288643

"Voici donc ce que j'ai fait de mal. J'ai changé le groupe par défaut qui était déjà défini pour le point de partage. Il est cependant IMPORTANT d'AJOUTER un nouveau groupe ou un nouvel utilisateur si vous voulez conserver l'héritage. Pour autant que je sache, les permissions par défaut ne sont responsables que pour posix et non pour ACL. Veillez à ajouter ce nouveau groupe en plus des autres et à propager ensuite les autorisations."

Il y a deux choses en jeu ici, les permissions de type POSIX (basées sur *nix) et les ACL (Access Control Lists) de NFSv4 utilisées sur votre serveur.

Vous les avez réglés sur AFP après avoir rencontré des problèmes persistants avec SMB. Les choses semblent se gâter lorsqu'on utilise l'AFP et Apple a beaucoup modifié SMB après avoir rompu les liens avec SAMBA et mis en œuvre sa propre version de SMB, même si elle est moins performante (vous, les geeks Mac, corrigez-moi si je me trompe - je veux savoir...).

Extrait d'un article sur TechRepublic J'ai trouvé cette excellente explication :

La plupart des systèmes UNIX utilisent les autorisations standard POSIX (Portable Operating System Interface) pour gérer l'accès aux fichiers. Les autorisations POSIX standard sont indépendantes du système de fichiers sur lequel elles sont utilisées (à condition que le système les prenne en charge), et toute personne familiarisée avec Linux ou UNIX les connaît, car elles constituent le moyen standard de définir un contrôle d'accès très basique sur les fichiers et les répertoires.

Essentiellement, vous pouvez définir le propriétaire d'un fichier ou d'un répertoire, le groupe qui en est propriétaire et "autre" (toute personne qui n'est pas l'utilisateur propriétaire ou un membre du groupe propriétaire). Vous pouvez également définir si chacun de ces utilisateurs dispose ou non d'une autorisation de lecture, d'écriture ou d'exécution sur le fichier ou le répertoire. Dans le cas d'un fichier, ces autorisations signifient que l'utilisateur peut lire le fichier, y écrire, le modifier, le supprimer ou l'exécuter en tant que programme. Pour les répertoires, ces autorisations signifient que l'utilisateur peut lire le contenu d'un répertoire (mais pas nécessairement le contenu des fichiers du répertoire), écrire dans le répertoire (créer et supprimer des fichiers) ou exécuter (permet à l'utilisateur de parcourir l'arborescence du répertoire afin d'accéder aux fichiers ou aux sous-répertoires, bien que cela n'autorise pas en soi à voir le contenu du répertoire).

La plupart des systèmes d'exploitation prennent également en charge une forme ou une autre de liste de contrôle d'accès (ou ACL). Souvent, cela dépend également du système de fichiers utilisé ou de l'implémentation qui peut être utilisée sur tel ou tel système de fichiers (les deux principaux types d'ACL sont les ACL POSIX.1e et les ACL NFSv4). Mac OS X n'est pas différent et, depuis OS X 10.4, il prend en charge les ACL NFSv4 lorsqu'elles sont utilisées avec le système de fichiers HFS+. L'utilisation de ces ACL sous OS X est assez simple ; il se peut même que vous les utilisiez sans le savoir.

Les ACL sont constituées d'ACE (Access Control Entries) et chaque ACL peut contenir plusieurs ACE. Les ACL offrent beaucoup plus de flexibilité et un contrôle plus fin sur les permissions des fichiers et des répertoires que les permissions POSIX standard. Par exemple, les ACL permettent de gérer les fichiers en lecture, écriture, exécution et ajout (l'ajout ne permet que de compléter un fichier existant, et non d'en modifier le contenu ou de le supprimer). Pour les répertoires, il est possible de lister les entrées, de les rechercher, d'ajouter un fichier, d'ajouter un sous-répertoire ou de supprimer le contenu. Une autre fonctionnalité intéressante des ACL est appelée "héritage" : vous pouvez définir une permission d'héritage de sorte que le contenu des fichiers d'un répertoire puisse hériter d'un ensemble d'ACL, tandis que les répertoires héritent d'un autre ensemble.

Comme vous pouvez le constater, les ACL sont très puissantes. Par exemple, si vous disposez d'un répertoire contenant des manuels destinés aux développeurs, vous pouvez rendre ce répertoire accessible en écriture aux développeurs et en lecture seule aux commerciaux. Vous pourriez également vouloir donner aux stagiaires l'accès à certains fichiers, mais vous ne voulez pas qu'ils fassent partie du groupe des développeurs ou des vendeurs parce que ces deux groupes ont accès à trop d'autres fichiers. Dans ce scénario, vous pourriez faire en sorte que le répertoire soit la propriété d'un utilisateur particulier, ou de l'utilisateur Root (administrateur), et qu'il appartienne au groupe des "développeurs", les fichiers et les répertoires étant accessibles en écriture à la fois par le propriétaire et par le groupe. Vous utiliseriez ensuite des ACL pour appliquer des autorisations de lecture seule à certains fichiers pour le groupe "ventes", et vous pourriez également utiliser des ACL pour appliquer un accès en lecture seule aux utilisateurs explicites qui sont des stagiaires (au lieu de créer un nouveau groupe pour les stagiaires). Avec les permissions POSIX standard, cela ne serait pas facile à réaliser.

Si vous avez utilisé la commande Finder Get Info sur un fichier ou un répertoire, vous avez probablement remarqué le volet Partage et autorisations en bas de l'écran. Par défaut, il affiche les entrées de permissions POSIX standard :

Ces permissions, sur la ligne de commande, équivaudraient à une propriété de "vdanen:staff" et un mode 0750 (ou 0640 s'il s'agissait d'un fichier). Cela peut être vu sur la ligne de commande comme suit :

drwxr-xr-x 2 vdanen staff 68 Mar 11 22:30 New

Pour ajouter des ACL à ce répertoire, vous pouvez utiliser les commandes chown et chmod, ou le Finder. L'utilisation de chown/chmod offre beaucoup plus de flexibilité, car le Finder vous limite un peu et fait certaines suppositions pour vous. Par exemple, pour donner l'accès à ce répertoire aux membres du groupe admin en lecture seule, vous devez cliquer sur le bouton + dans le volet Partage et autorisations, sélectionner l'utilisateur ou le groupe, puis définir le privilège approprié :

Les membres du groupe admin ont désormais un accès en lecture seule à ce dossier. Pas très difficile à régler dans le Finder, n'est-ce pas ? Nous pouvons également observer les ACL sur la ligne de commande, en utilisant le commutateur -le de la commande ls :

% /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 22:30 New 0: group:admin allow list,search,readattr,readextattr,readsecurity

Le Finder donne plus d'autorisations que les autorisations de "liste" ou de "recherche" ; il permet également au groupe d'administrateurs de lire les attributs étendus et les ACL.

Pour faire la même chose en ligne de commande, vous devez utiliser :

% mkdir New2 % /bin/chmod +a "admin allow read,readattr,readextattr,readsecurity" New2 % /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 23:06 New2 0: group:admin allow list,readattr,readextattr,readsecurity % /bin/chmod +a "admin allow search" New2 % /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 23:06 New2 0: group:admin allow list,search,readattr,readextattr,readsecurity

Comme vous pouvez le constater, la commande chmod initiale a omis une ACL ; il est assez facile d'ajouter une nouvelle entrée ultérieurement. Et si vous avez besoin d'en supprimer une, c'est également facile :

% /bin/chmod -a "admin allow search" New2

Le groupe des administrateurs n'a plus les droits de recherche sur ce répertoire. Vous noterez que dans chaque cas, je spécifie un chemin explicite pour les commandes ls et chmod. C'est parce que j'ai installé Fink, et que les outils GNU qui sont installés via Fink ne comprennent pas les ACL d'OS X, et que ces commandes ne fonctionneront pas avec eux (le PATH par défaut du système place /sw/bin avant /bin/, donc quand je tape "ls", c'est "/sw/bin/ls" qui est exécuté, plutôt que "/bin/ls").

Mac OS X Server (et probablement Lion) dispose d'une interface graphique plus sophistiquée que le Finder pour manipuler les listes de contrôle d'accès, mais pour la plupart des tâches de base, le Finder suffit. Il ne gère cependant pas l'héritage, ce qui est dommage. Il vous permet d'appliquer les permissions définies pour un répertoire aux fichiers et répertoires qui s'y trouvent en utilisant l'entrée de menu "Appliquer aux éléments inclus..." du menu déroulant de l'engrenage, ce qui accomplit sans doute quelque chose de similaire ; cependant, si vous modifiez les permissions du répertoire, vous devez les réappliquer, et aussi si vous avez ajouté de nouveaux dossiers ou de nouveaux fichiers, etc.

La page de manuel chmod ("man chmod") donne une très bonne explication des ACL et de la manière de les appliquer. Les ACEs dans une ACL respectent l'ordre, vous pouvez donc utiliser chown pour spécifier où un ACE spécifique doit être positionné dans l'ACL, et bien sûr vous pouvez être beaucoup plus spécifique que vous ne pourriez l'être avec le Finder.

Les listes de contrôle d'accès sous OS X fonctionnent de manière très similaire aux listes de contrôle d'accès des autres systèmes POSIX, y compris Linux. Les autorisations peuvent différer quelque peu, tout comme le mécanisme de mise en œuvre et de gestion, mais les avantages sont identiques. La prise en charge des ACL sous OS X est également compatible avec certaines versions de Windows et de Windows Server.

Et si cela ne suffit pas, aquí contient de très bonnes informations approfondies sur le partage, y compris le partage et l'affichage des partages à partir de Terminal.

Version courte - pour l'utilisation de Mojave TinkerTool System 6 (à ne pas confondre avec TinkerTool) https://www.bresink.com/osx/TinkerToolSys6.html

Version longue : J'ai eu un problème similaire après avoir mis à jour un Mac Mini Server 5,3 fonctionnant sous El Capitan et Server 5.1 vers un nouveau Mac Mini Server fonctionnant sous Mojave et Server 5.8. Je n'ai pas pu trouver un bon chemin de migration, alors j'ai configuré tous les utilisateurs et groupes à nouveau. Les permissions étaient en désordre, avec de longues listes de "Fetching" apparaissant dans les boîtes Get Info sur les fichiers et les dossiers, et des problèmes avec l'accès des utilisateurs aux fichiers et aux dossiers.

Après avoir lutté pendant des jours, j'ai abandonné Server 5.8, et j'ai configuré les utilisateurs (Utilisateurs en tant que partage uniquement) et les groupes dans l'utilitaire intégré (Préférences système:Utilisateurs et groupes). J'ai ensuite activé le partage de fichiers (Préférences système:Partage:Case à cocher Partage de fichiers) et assigné des groupes aux dossiers auxquels ces groupes devaient pouvoir accéder. On pourrait penser que cela résoudrait les problèmes d'autorisation, mais ce n'est pas le cas. Il en va de même pour la réinitialisation des autorisations dans la boîte "Obtenir des informations" et l'application des autorisations à tous les éléments joints. L'héritage était toujours un problème et les autorisations changeaient automatiquement. J'ai finalement pu réinitialiser toutes les autorisations ET L'HÉRITAGE à l'aide de TinkerTool System en moins d'une heure. Cela aurait été possible en utilisant la ligne de commande, mais pas aussi facilement, et TinkerTool System ne coûte que 14 $.

2 autres conseils que j'ai recueillis.

1. N'attribuez pas l'autorisation "Pas d'accès" au groupe "Tout le monde", car cette autorisation supplantera (ou peut supplanter) les autres autorisations du groupe. Curieusement, l'attribution de l'option "Lecture seule" au groupe "Tout le monde" ne supplante pas les autres autorisations du groupe.

2. Bien que je n'aie pas eu ce problème, c'est ce que le service d'assistance d'Apple soupçonnait et qui l'a gêné pendant longtemps. Conservez les dossiers que vous souhaitez partager avec un groupe dans le répertoire racine du disque, et n'imbriquez pas les uns dans les autres des dossiers dont l'accès est réservé à des groupes différents.