Mac mini non può connettersi al mio server SMB aziendale. Lavorava qualche giorno fa

SUCCESSO !!

Dopo 2 mesi di (moderata) miseria ho finalmente trovato il motivo per cui SMB non ha funzionato con il mio Sierra Mac Mini.

TL; DR Il motivo è stato questo kext installato:

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

È possibile verificare se è stato installato con il seguente comando da un normale terminale:

kextstat | grep -iv apple

Nel caso ce l'avessi (e nel caso tu stia anche soffrendo problemi di connettività SMB) puoi disinstallarlo digitando nuovamente il seguente comando da un normale Terminale (non è necessario il boot in modalità Utente singolo):

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

Segui le istruzioni sullo schermo, REBOOT e il gioco è fatto :)

In questo modo perderai l'accelerazione hardware all'interno degli emulatori Android, ma funzioneranno in modalità di rendering del software. Non brillante, ma è qualcosa. È possibile reinstallare HAXM nel caso in cui sia necessario ricorrere all'accelerazione hardware per gli emulatori Android (ma essere pronti a perdere di nuovo la connettività SMB (?)).

Risposta lunga:

Se utilizzi il tuo Sierra Mac per sviluppare materiale Android probabilmente avrai installato i tipici moduli necessari a caso (Android SDK, emulatori, driver, ecc ...) Il fatto è che "Intel HAXM Accelerator" è uno dei driver tipici che si installa se si desidera un'accurata accelerazione hardware dei propri emulatori per lo sviluppo Android. Bene, a quanto pare, e ci creda o no, quel driver non è compatibile con l'uso di SMB in macOS Sierra, almeno con il mio MAC.

Il sottosistema Sierra SMB e HAXM sono pezzi di software apparentemente non correlati, ma sembra che siano in qualche modo incompatibili tra loro. Nel caso di problemi SMB dovrai decidere quale dei due hai davvero bisogno di più:

SMB o emulatori veloci appropriati per lo sviluppo Android .

Ho scelto SMB:)

Grazie a TUTTI in questa domanda, rispondendo, commentando, ecc ... specialmente Brett che, dopo molte settimane , mettimi dopo il comando corretto.

Ho avuto lo stesso problema (1025 errori per aprire il dispositivo smb, syserr = No tale file o directory) e infine rintracciato fino al dispositivo /dev/nsmb0 non configurato correttamente a causa di un kext in conflitto da una terza parte molto vecchia app. Se cat /dev/nsmb0 e ottieni "Dispositivo non configurato", è possibile che si tratti di un problema simile.

Per risolverlo, ho esaminato tutti i kex non Apple e rimosso app / kexts uno alla volta finché non ha funzionato. Ho dovuto avviare la modalità utente singolo (cmd + s durante l'avvio) per rimuoverne alcuni.

Puoi cercare tra i tuoi kester non-Apple caricati usando kextstat | grep -iv apple . Ecco un esempio di output per me su un sistema funzionante:

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>

Puoi scaricare kex per nome file con:

kextunload /System/Library/Extensions/KextName.kext

o per il nome del pacchetto:

kextunload -b com.example.kext.name

Sei connesso a qualsiasi altra azione SMB allo stesso tempo? Oggi ho segnalato un bug ad Apple relativo a macOS Sierra, in base al quale se sono connesso a un'altra condivisione SMB su un server diverso, quando provo a connettermi a un altro, verrà utilizzato l'indirizzo IP originale e il percorso di condivisione dal nuovo server.

Ad esempio

1. Già connesso a smb: //192.168.0.2/share1
2. Tentativo di connessione a smb: //192.168.0.3/share2
3. L'analisi dei pacchetti mostra che macOS tenta di connettersi a smb: //192.168.0.2/share2, che non esiste.

Le uniche soluzioni alternative che ho trovato sono quelle di connettersi per disconnettersi dal primo server prima di tentare la connessione sul secondo. Tuttavia, ciò significa che è possibile avere una sola connessione SMB aperta alla volta.

Una soluzione leggermente migliore era usare il nome host per il server invece dell'indirizzo IP. Questo sembrava consentirmi di collegarmi al secondo server SMB senza problemi. Se non conosci il nome host, puoi ottenerlo aprendo il terminale e digitando il seguente comando.

host <ip_address>

Spero che questo aiuti.

Modifica - Ho pensato che valesse la pena ricordare che questo problema sembra interessare tutti i client che sono stati aggiornati a Sierra.