Acabo de actualizar la Mac Mini que uso como servidor de archivos a la 10.10.4 y la aplicación del servidor a la 4.1.3. Después de actualizar, ya no puedo conectarme al recurso compartido AFP que veo en la barra lateral del Finder en el cliente, una MacBook Pro.
Si reinicio el servicio compartido en la aplicación del servidor, la conexión es exitosa. Después de un rato, si vuelvo a hacer clic en el Mac Mini en la barra lateral de MBP Finder, dice "Conectando..." y luego "Error de conexión".
El servidor web del Mac Mini tampoco responde. Tampoco puedo conectarme con el botón "Compartir pantalla" y, a veces, simplemente desaparece de la barra lateral.
En el MBP cuando falla la conexión compartida, dice:
14/07/15 14:10:23,438 sharingd[174]: SDSharePointBrowser::handleOpenCallBack returned 65
o:
14/07/15 15:14:36,418 NetAuthSysAgent[318]: DNSAddressResolver:Resolve CFNetServiceResolveWithTimeout failed
14/07/15 15:14:36,418 NetAuthSysAgent[318]: ERROR: AFP_GetServerInfo - connect failed 64
14/07/15 15:14:36,419 sharingd[179]: SDSharePointBrowser::handleOpenCallBack returned 64
No estoy 100% seguro de que esto esté exactamente relacionado con la pregunta en cuestión, pero podría ayudar a algunos con este problema.
TL; DR: asegúrese de que su máquina no incluya
.o\
Primero. De vuelta en OSX 10.9.x, Apple cambió el servicio de uso compartido de archivos predeterminado de AFP a SMB2, lo que significa que si usa Finder para conectarse a un recurso compartido de archivos de máquinas, la máquina probará SMB y luego debería probar AFP si SMB falla .
Pasé demasiado tiempo mirando las conversaciones de Wireshark entre un cliente 10.10.5 y un servidor de archivos 10.11.3 para ver qué estaba pasando y creo que puede haber encontrado la razón por la que esto a veces falla para algunos usuarios.
Primero, una configuración que parece funcionar: el nombre de la computadora del servidor está configurado para Computer 1(tenga en cuenta el espacio) en el System Preferences > Sharingpanel. el nombre de netbios para esta máquina es diferente, pero eso no entra en juego cuando se conecta a través de Finder.
Esto da como resultado que Bonjour complete la máquina cliente con un computer 1en la sección Compartido de la barra lateral. cuando hace clic en este elemento compartido y luego hace clic en el Connect As...botón, se produce la siguiente conversación entre el cliente y el servidor:
CLIENT: Tree Connect Request: \\computer 1._smb._tcp.local\IPC$
SERVER: STATUS_SUCCESS
CLIENT: Create Request File: srvsvc
...
CLIENT: Finder receives Directory listing
Esto funciona como se esperaba, hace clic en el servidor, ingresa sus credenciales y obtiene acceso a los recursos.
Ahora, una configuración que no funciona, la misma configuración que la anterior, pero esta vez el nombre del servidor se cambia a computer.1(usando un punto en lugar de un espacio), esto da como resultado la siguiente conversación entre el servidor y el cliente:
CLIENT: Tree Connect Request: \\computer\.1._smb._tcp.local\IPC$
SERVER: STATUS_BAD_NETWORK_PATH
CLIENT: Tree Connect Request: \\<ip address>\IPC$
SERVER: STATUS_SUCCESS
CLIENT: Finder displays Connection Failed
Hay dos partes interesantes en esto:
.hace \.que el servidor informe de una ruta incorrectaEsto parece ser un error en el manejo de caracteres no válidos por parte del sistema operativo en el protocolo SMB y el respaldo adecuado a IP o AFP en caso de falla.
Probé todos los caracteres especiales de la cara de EE. UU. Los siguientes caracteres causan este problema: .(punto) y \(barra invertida). Todos los demás caracteres parecen funcionar bien (por ejemplo !, @, %, , ?...) aunque no hice una verificación exhaustiva como el espacio de caracteres ASCII.
Tuve exactamente el mismo problema con el error "SDSharePointBrowser::handleOpenCallBack devolvió 65" en la consola. Para solucionarlo, habilité y luego deshabilité el uso compartido de archivos SMB y AFP en Preferencias del sistema. Después de reiniciar el sistema, el NAS se conecta correctamente a través de AFP.
Aldequine
jalanb