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 equipo no incluya . o \
Primero. de nuevo en OSX 10.9.x Apple cambió el servicio predeterminado de uso compartido de archivos de AFP a SMB2, lo que significa que si usa el Finder para conectarse a un archivo de máquinas, la máquina probará con SMB, entonces debería probar AFP si SMB falla. .
Acabo de pasar 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 falla a veces para algunos usuarios.
Primero una configuración que parece funcionar:
El nombre de la computadora del servidor está configurado para Computer 1 (note el espacio) en el panel System Preferences > Sharing . el nombre de netbios para esta máquina es diferente, pero no entra en juego cuando se conecta a través del Finder.
Esto hace que Bonjour llene la máquina cliente con un computer 1 en la sección Compartida de la barra lateral. cuando hace clic en este elemento compartido y luego hace clic en el botón Connect As... , ocurre 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, al hacer clic en el servidor, ingresar sus credenciales y obtener 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 del servidor 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 para esto:
- El cliente escapa de
. a \. , lo que hace que el servidor reporte una ruta incorrecta
- Tan pronto como el cliente se da cuenta del error de ruta incorrecta, intenta conectarse con la dirección IP del servidor, eso tiene éxito, pero el cliente no solicita una lista de directorios y muestra el error de conexión.
- La conexión no recae en AFP cuando falla SMB.
Esto parece ser un error en el manejo de SO de caracteres no válidos para el protocolo SMB y un repliegue adecuado de IP o AFP en caso de falla.
He probado que todos los caracteres especiales de cara de EE. UU. son los siguientes son los siguientes problemas: . (periodo) y \ (barra diagonal inversa). Todos los demás caracteres parecen funcionar bien (por ejemplo, ! , @ , % , ? ...) aunque no hice una comprobación exhaustiva como el espacio de caracteres ascii.