Mac mini no se puede conectar a mi servidor SMB corporativo. Estaba trabajando hace unos días.

ÉXITO!!

Después de 2 meses de miseria (moderada), finalmente encontré la razón por la que SMB no funcionó con mi Sierra Mac Mini.

TL;DR El motivo fue que se instaló este kext:

com.intel.kext.intelhaxm (6.0.1) 8FF2C637-0A5E-367E-B007-5B08655B1E8A < 7 5 4 3 1 >

Puede verificar si lo tiene instalado con el siguiente comando desde una Terminal ordinaria:

  

kextstat | grep -iv manzana

En caso de que lo tenga (y en caso de que también tenga problemas de conectividad SMB), puede desinstalarlo escribiendo el siguiente comando, nuevamente, desde un Terminal ordinario (no es necesario iniciar en el modo de usuario único):

  

sudo /Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh

Sigue las instrucciones en pantalla, REBOOT , y listo :)

Al hacerlo, perderá la aceleración de hardware dentro de sus emuladores de Android, pero funcionarán en el modo de renderización de software. No es brillante, pero es algo. Puede reinstalar HAXM en caso de que realmente necesite de nuevo la aceleración de hardware para los emuladores de Android (pero prepárese para perder la conectividad SMB de nuevo (?)).

Respuesta larga:

Si utilizas tu Sierra Mac para desarrollar cosas de Android, probablemente habrás instalado los típicos módulos aleatorios necesarios (Android SDK's, emuladores, controladores, etc.) La cuestión es que el "acelerador Intel HAXM" es uno de los controladores típicos que instala si desea una aceleración de hardware adecuada de sus emuladores para el desarrollo de Android. Bueno, al parecer, y lo creas o no, ese controlador no es compatible con el uso de SMB en macOS Sierra, al menos con mi MAC.

Sierra SMB subsystem y HAXM son piezas de software aparentemente no relacionadas, pero parece que de alguna manera son incompatibles entre ellas. En caso de que tenga problemas de SMB, tendrá que decidir cuál de los dos necesita más:

SMB o emuladores rápidos adecuados para el desarrollo de Android .

Elegí SMB :)

Gracias TODOS en esta pregunta, respondiendo, comentando, etc. ... especialmente Brett que, después de muchas semanas , ponme después de la pista correcta.

Tuve el mismo problema (1025 fallos al abrir el dispositivo smb, syserr = No hay tal archivo o directorio) y finalmente lo rastreé hasta que el dispositivo /dev/nsmb0 no se configuró correctamente debido a un kext conflictivo de un tercero muy antiguo la aplicación Si cat /dev/nsmb0 y obtiene "Dispositivo no configurado", posiblemente sea un problema similar.

Para resolverlo, miré todos los kexts que no eran de Apple y eliminé los apps / kexts uno a uno hasta que funcionó. Tuve que arrancar en modo de usuario único (cmd + s durante el arranque) para eliminar algunos de ellos.

Puedes buscar a través de tus kexts cargados que no sean de Apple usando kextstat | grep -iv apple . Este es un ejemplo de la salida para mí en un sistema que funciona:

Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
   82    0 0xffffff7f8284c000 0x7000     0x7000     net.sf.tuntaposx.tap (1.0) 23FDB715-3D0D-3A26-ACBA-E3794C231CB7 <7 5 4 1>
   83    0 0xffffff7f82853000 0x7000     0x7000     net.sf.tuntaposx.tun (1.0) 95DD963D-E23D-3B0F-8DE8-A4D2F6BFA5CC <7 5 4 1>
   87    3 0xffffff7f8287c000 0x63000    0x63000    org.virtualbox.kext.VBoxDrv (5.0.28) 4ED2DD49-255E-37C8-A0B8-2556670B17B1 <7 5 4 3 1>
  144    0 0xffffff7f8363e000 0x7000     0x7000     com.zerotier.tap (1.0) 8BA59C0A-B3A7-3418-BFF5-B4914CE7734A <7 5 4 1>
  146    0 0xffffff7f83645000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (5.0.28) E7605ACF-20E3-3016-94E2-A6013CD9260F <145 87 40 7 5 4 3 1>
  151    0 0xffffff7f8366f000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (5.0.28) 89C23056-9027-33DB-852A-429BFA00D6DE <87 7 5 4 3 1>
  152    0 0xffffff7f83674000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (5.0.28) 1A767D65-6674-3A9F-B305-DAA197F109CC <87 5 4 1>

Puedes descargar kexts por nombre de archivo con:

kextunload /System/Library/Extensions/KextName.kext

o para el nombre del paquete:

kextunload -b com.example.kext.name

¿Está conectado a otras acciones SMB al mismo tiempo? Hoy informé a Apple sobre un error relacionado con macOS Sierra, por lo que si estoy conectado a otro recurso compartido SMB en un servidor diferente, al intentar conectarme a un segundo, utilizará la dirección IP original y la ruta compartida desde el nuevo servidor.

Por ejemplo

1. Ya está conectado a smb: //192.168.0.2/share1
2. Intente conectarse a smb: //192.168.0.3/share2
3. El análisis de paquetes muestra que macOS intenta conectarse a smb: //192.168.0.2/share2, que no existe.

Las únicas soluciones que he encontrado son conectar para desconectarse del primer servidor antes de intentar la conexión en el segundo. Sin embargo, esto significa que solo puede tener una conexión SMB abierta a la vez.

Una solución ligeramente mejor fue utilizar el nombre de host para el servidor en lugar de la dirección IP. Esto pareció permitirme conectarme al segundo servidor SMB sin problema. Si no conoce el nombre de host, puede obtenerlo abriendo el terminal y escribiendo el siguiente comando.

host <ip_address>

Espero que esto ayude.

Editar: pensé que valdría la pena mencionar que este problema parece afectar a todos los clientes que se han actualizado a Sierra.