crash ouverture compte mobile pour la première fois

Logiquement un serveur reste allumé 24h/24 mais ton problème ne vient évidemment pas de là…

Essaye de désactiver un routeur pour les tests mais si j'ai de gros doutes la-dessus…

Après il faudrait peut-être faire un test sur un autre poste client afin d'éliminer un problème du poste client…

Après qq tests, voici ce que ça donne:

LAN branché - serveur ON - démar. cpt. Portable -> freeze
LAN branché - serveur ON - démar. cpt. root -> OK
LAN branché - serveur OFF - démar. cpt. Portable ou root -> OK
LAN débranché - démar. cpt. Portable ou root -> OK
Une fois le cpt. Portable ouvert jusqu'au bout, LAN de nouveau branché - réponse du serveur normale, synchro possible.

Lien avec serveur rompu pour le cpt. Portable - LAN branché - serveur ON - démar. cpt. Portable -> freeze. Extinction forcée - redémarrage avec LAN débranché - ouverture cpt. Portable - une fois ce cpt. ouvert jusqu'au bout, LAN de nouveau branché - réponse du serveur normale, proposition de relier le client au serveur - OK, configuration des services OK.

Comme ça marche avec le cpt. root et pas avec le mien (Portable), j'ai comparé les quelques paramètres qui peuvent avoir son importance et ai trouvé 2 choses bizarres:

1. cpt. Portable est sous contrôle parental - je l'ai décoché sous cpt. root, mais ça reviens à l'ouverture. Pourtant sur le serveur, je ne l'ai pas activé du tout (aucun des cpt. sur le serveur n'a le contrôle parental) ?!?!

2. sous cpt. root, il y a 2 routines dans le menu démarrage: deux fois afp:// qui proviennent du serveur - mais dans le cpt. Portable, la première des 2 est notée "Inconnue", la deuxième afp://. Impossible de l'effacer.

Voici ce que j'en déduis:

- Le problème est dans le serveur et pas dans le routeur
- Je suppose qu'au démarrage, lorsque la routine afp "Inconnue" est appelée, elle se bloque et l'ouverture du compte avec. L'activation systématique du contrôle parental est aussi étrange !

Si mes déductions sont justes, je bute sur qqch dont je ne vois pas l'origine.

Ai-je pu te mettre sur une piste ? Passer par Terminal et si oui, comment ?

Donc c'est juste au moment de l'authentification et à l'ouverture de la session que le poste client freeze c'est bien ça ?
C'est bien ton serveur qui fait office de base LDAP et qui va manager le poste client au niveau de l'authentification ?

Oui, c'est ça.

Mais je crois que j'arrive au bout du problème: c'est lié à l'activation de la préférence suivante:

Dans Gestion des groupe de travail - pour une catégorie de clients (dans mon cas "ordinateurs portables") - option Ouverture de session - éléments - ajouter un point de partage - activer Ajouter un point de partage de dossier de départ du réseau.
Ceci ajoute dans le menu du client, dans l'Ouverture un lien afp:// qui dans mon cas bloque l'ouverture à mi-chemin (il y a vraisemblablement un blocage quelque part).

Je ne sais pas si cette activation est nécessaire et si elle apporte un avantage. Ce qu'il me faut. c'est à l'ouverture du compte un accès directe dans les dossiers de partage définis sous AFP (càd que je ne doive pas à l'ouvrir manuellement après l'ouverture de session client).

J'ai trouvé ceci dans un manuel:

Providing Access to a User’s Network Home Folder
Don’t provide access to a user’s network home folder to users with mobile accounts on Mac OS X v10.4 or later. Mac OS X v10.4 and later include portable home directories, which provide a synced subset of the user’s local and network home folders.

C'est peut-être la raison ? Je continue à explorer ce sujet

... et en plus c'est en relation avec les message que je reçois chaque fois que je répare les autorisations et qui revient toujours:

ACL différent sur « Applications/Server ».
« Applications/Server » réparé.
Les autorisations sont différentes sur « usr/share/derby », elles devraient être drwxr-xr-x au lieu de lrwxr-xr-x .
« usr/share/derby » réparé.
ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.
Les autorisations sont différentes sur « Library/Application Support/Apple/ParentalControls », elles devraient être drwxrwxr-x au lieu de drwxr-xr-x .
« Library/Application Support/Apple/ParentalControls » réparé.
....... - voir début de ce post.

On y trouve les 2 problèmes: connexion à un volume partage afp et contrôle parental ......

Et si tu désactives le contrôle parentale pour voir déjà ?

Euh, justement, je ne peux pas le désactiver car il n'est validé nullepart ! Si je me log en root sur le client, je peux le désactiver, mais il revient car c'est surement le serveur qui le dicte.
Sur le serveur, il n'y a pas de contrôle parental activé dans aucune des préférences. J'ignore s'il y a d'autres endroits où l'ont peut le faire ?
Mais toujours est-il que le fichier y relatif (voir dessus), est corrompu et je ne sais pas comment le réparer. Aurais-tu une idée ?

ça c'est balèze !

Tu n'as pas de MCX sur ton serveur ?

Dans les préférences des comptes via la GUI du gestionnaire de groupe de travail (pas ceux du système) ?

J'ai réglé le problème (partiellement je pense) par mettre le dossier Library/applic.support/apple/parental control à la poubelle - malgré tout, le compte mobile sur le client revient toujours comme "contrôlé", mais lors de réparation des permissions n'apparait plus.
A vrai dire, ça n'a jamais gêné. D'ailleurs un compte d'administrateur local qui est contrôlé, ce n'est pas logique .

Pour ce qui est l'autre message qui arrive toujours pendant les réparations des permissions:
Les autorisations sont différentes sur « usr/share/derby », elles devraient être drwxr-xr-x au lieu de lrwxr-xr-x .
« usr/share/derby » réparé.

on peut l'ignorer, également comme les autres messages ACL - voir ce lien: http://discussions.info.apple.com/thread.jspa?messageID=11139158

Pour répondre à ta question: MCX - en fait oui, à travers les préférences. Dans le menu Démarrage du cpt. client, il y a aussi MCXMenuExtraTool

Pour résumer, je m'arrête là avec ce foutu problème - je ne sais pas si je suis arrivé à une solution "100% clean", mais comme on dit: Mieux est l'ennemi du bien !