Symptômes
Au travail, nous avons installé OSX 10.7.3 et de temps en temps je verrai les comportements suivants:
Si l'écran est verrouillé, plusieurs tentatives du même utilisateur / passe ne sont pas acceptées.
Si l'écran est déverrouillé, l'ouverture d'un nouveau terme bash peut générer des invites telles que:
`I have no name$`ou
lkyrala$ ssh lkyrala@ah-lkyrala2u You don't exist, go away!
Même lorsque nos Mac fonctionnent normalement, tout le monde ici doit se connecter deux fois. La première fois après le démarrage échoue toujours , mais la deuxième fois (avec le même mot de passe, sans rien changer, en appuyant à nouveau sur Entrée) réussit. Bizarre?
Solutions de contournement
Il existe des solutions de contournement qui résolvent le problème immédiat, mais ne l'empêchent pas de se reproduire:
attendez (peut-être une heure ou deux) et les problèmes disparaissent parfois d'eux-mêmes.
tuez 'opendirectoryd' et laissez-le redémarrer. (dans les communautés d'assistance Apple: l'ID utilisateur (et non les données) a été supprimé soudainement? )
maintenez le bouton d'alimentation pour réinitialiser l'ordinateur
MISE À JOUR 10/04/2012
Nos administrateurs réseau soupçonnent que lockd est impliqué. lockd utilise apparemment UDP et lorsque le réseau est encombré, les paquets sont perdus, ce qui entraîne le blocage. Ils envisagent des mesures pour réduire la congestion. Si l'accès au fichier en question se trouve être le handle d'authentification Active Directory, alors toutes ces différentes pièces commencent à s'emboîter.
Discussion
Maintenant, les preuves ci-dessus m'indiquent quelque chose de délirant avec le répertoire ouvert et les informations de connexion. D'autres personnes signalent avoir ces problèmes de connexion, mais il est difficile de déterminer où se situe le problème réel (Mac ou environnement réseau?).
Je dois ajouter que la plupart du réseau sont des machines Windows, mais nous avons également quelques machines Mac et Linux, mais je ne suis pas sûr des détails de la façon dont l'authentification réseau est mappée de divers domaines à d'autres ... tous Je sais que nos informations d'identification réseau fonctionnent dans les domaines Windows ainsi que dans les connexions Mac et Linux - donc quelque chose connecte des systèmes distincts ou utilise le même système d'authentification global.
Détails supplémentaires
Malheureusement, je n'ai pas configuré ce Mac, notre département informatique l'a fait, donc je ne suis pas entièrement sûr du fonctionnement de l'authentification. Je sais que c'est une connexion réseau (ce qui est inhabituel dans mon expérience avec les Mac, ils ont généralement des comptes locaux qui se connectent à des ressources externes) mais ici, notre dossier personnel est sur le réseau, pas local. Sous mes installations Linux, la connexion au réseau implique yp / NIS, (ce qui nous permet de monter automatiquement des parties de notre système de fichiers réseau depuis n'importe quelle machine), et le opendirectoryd.log semble confirmer que cela est impliqué ...
/var/log/opendirectoryd.log* spectacles:
2012-04-04 01:29:12.370 EDT - ddddd.dddddd.dddddd.dddddd - Client: automount, UID: 0, EUID: 0, GID: 0, EGID: 0
2012-04-04 01:29:12.370 EDT - ddddd.dddddd.dddddd.dddddd, Node: /NIS/Domain, Module: nis - could not determine map for rectype 'mounts' attribute 'byname'
2012-04-04 01:32:04.504 EDT - failed to get YP map list
Il semble que le domaine «Domain» soit en quelque sorte perdu. Pourquoi l'UID == 0 est-il ici? Cela semble mauvais, non?
Je sais que sous Linux il y a quelque temps, j'ai découvert que la diffusion NIS avait été désactivée ou bloquée, j'ai donc rassemblé les adresses IP de quelqu'un et défini manuellement les adresses IP ypserver /etc/yp.confet corrigé les baisses dans Linux. Peut-être que quelque chose de similaire se passe ici?
J'ai essayé de rechercher des informations dans les pages de manuel yp de Mac:
Et puis trouvé ce post détaillant où les serveurs existants sont définis:
Cependant, la vérification des paramètres ypserver a montré que les deux IP de serveur étaient correctement définies pour NIS.
Vérification /var/log/system.logmontre:
Aug 28 00:30:08 mymac ypbind[22991]: direct: sendto: No route to host
Aug 28 00:30:08 mymac ypbind[22991]: direct: sendto: No route to host
Aug 28 00:30:08 mymac ypbind[22991]: Can't contact any servers listed in /var/yp/binding/Domain.ypservers. Aborting
Aug 28 00:30:08 mymac com.apple.launchd[1] (com.apple.nis.ypbind[22991]): Exited with code: 1
Aug 28 00:30:08 mymac com.apple.launchd[1] (com.apple.nis.ypbind): Throttling respawn: Will start in 10 seconds
Aug 28 00:30:08 mymac xpchelper[22990]: getpwuid_r() failed for UID: uuuu, ret: 0, errno: 0
Cela me fait donc soupçonner les paramètres nfs.conf, etc. Certains pensent que cela est dû à quelque chose dans lockd.
Recherche
10.6 Serveur: comment faire fonctionner correctement le disque NFS
mount_nfs - "Un serveur NFS ne doit pas monter en boucle ses propres systèmes de fichiers exportés car il est fondamentalement sujet à un blocage."
rpc.lockd - "L'implémentation actuelle sérialise les demandes de verrouillage qui pourraient être partagées."
Rapports de problèmes similaires
la source
Réponses:
Avez-vous lié le mac à un serveur OSX ou à Active Directory? Si ce dernier vérifie si le domaine se termine par .local. Si c'est le cas, il existe des problèmes connus d'interférence de multidiffusion sur OSX. Le processus ici peut fonctionner pour vous: http://www.macwindows.com/TIP-Lion-dot-local-AD-disable-multicast.html
Certains Mac ne sont tout simplement pas satisfaits d'un réseau AD. J'ai eu plusieurs iMac avec des spécifications essentiellement identiques et la plupart étaient bien, mais 2 ont continué à perdre la connectivité avec le contrôleur de domaine et avaient des problèmes constants liés aux tickets Kerberos. Dans ce cas, la rupture du mac du domaine puis sa reconnexion à l'aide de Centrify Express ont résolu le problème. Vous pouvez trouver l'agent sur leur site Web ici: http://www.centrify.com/express/free-active-directory-tools-for-linux-mac.asp#agents
la source