Mac mini non riesce a connettersi al mio server SMB aziendale. Funzionava qualche giorno fa

Sono al lavoro e il mio Mac mini ha smesso di connettersi alle cartelle condivise del server SMB aziendale.

Se provo Finder> Connetti al server (utilizzando l'URL memorizzato da precedenti connessioni riuscite), macOS Sierra si lamenta di un "errore generico" più che inutile.

Nei registri della mia console non riesco a rilevare alcun errore relativo a samba (dove dovrei cercare?)

Ci sono macchine mini clonic di Mac sullo stesso piano (quelle dei miei colleghi) e possono connettersi a questo server senza alcun problema.

Se eseguo il ping di questa macchina dalla mia riga di comando, posso vederla perfettamente.

Se provo questo dalla riga di comando:

smbutil view smb://192.168.XXX.XXX/docs/

macOS Sierra produce questo:

smbutil: server connection failed: No such file or directory

Se provo quella riga di comando molto esatta su una macchina collega, elenca solo le risorse condivise sospese da quel server SMB ...

Qualche suggerimento? Forse è qualcosa correlato a un servizio disabilitato per errore nel mio Mac mini?

Non ho accesso alla macchina e alla configurazione del mio server Samba aziendale.

Ho letto e cercato su Google molte pagine e sono più che perso.

Nel caso in cui possa essere utile, utilizzo MacPorts. Potrebbe sembrare una cosa casuale da aggiungere qui, ma forse non sono a conoscenza di alcune librerie che avrei potuto installare che potrebbero essere problematiche con il client SAMBA OS X ufficiale.

SUCCESSO!!

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

TL; DR Il motivo era questo kext installato:

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

Puoi controllare se lo hai installato con il seguente comando da un normale Terminale:

kextstat | grep -iv apple

Nel caso in cui lo possiedi (e nel caso tu stia riscontrando anche problemi di connettività SMB) puoi disinstallarlo digitando il seguente comando, di nuovo, da un Terminale ordinario (non è necessario avviare 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 software. Non geniale, ma è qualcosa. Puoi reinstallare HAXM nel caso in cui tu abbia davvero bisogno di nuovo l'accelerazione hardware per gli emulatori Android (ma preparati a perdere di nuovo la connettività SMB (?)).

Risposta lunga:

Se usi Sierra Mac per sviluppare roba Android probabilmente avrai installato i tipici moduli casuali necessari (Android SDK, emulatori, driver, ecc ...) Il fatto è che "Intel HAXM accelerator" è uno dei driver tipici che installare se si desidera una corretta accelerazione hardware degli emulatori per lo sviluppo di Android. Bene, a quanto pare, e che ci crediate o no, quel driver non è compatibile con l'utilizzo di SMB su macOS Sierra, almeno con il mio MAC.

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

SMB o emulatori veloci adeguati per lo sviluppo Android .

Ho scelto SMB :)

Grazie a TUTTI in questa domanda, rispondendo, commentando, ecc ... specialmente Brett che, dopo molte settimane, mi ha dato il comando giusto.

Ho avuto lo stesso problema (1025 errori nell'apertura del dispositivo smb, syserr = nessun file o directory del genere) e alla fine l'ho rintracciato nel /dev/nsmb0dispositivo non configurato correttamente a causa di un kext in conflitto da un'app di terze parti molto vecchia. Se cat /dev/nsmb0ottieni "Dispositivo non configurato", è probabilmente un problema simile.

Per risolverlo, ho guardato tutti i kex non Apple e ho rimosso le app / kexts uno alla volta fino a quando non ha funzionato. Ho dovuto avviare in modalità utente singolo (cmd + s durante l'avvio) per rimuoverne alcuni.

Puoi cercare tra i tuoi kexts non Apple caricati usando kextstat | grep -iv apple. Ecco un esempio dell'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 kexts per nome file con:

kextunload /System/Library/Extensions/KextName.kext

o per il nome del pacchetto:

kextunload -b com.example.kext.name

Sei connesso ad altre condivisioni SMB contemporaneamente? Oggi ho segnalato ad Apple un bug relativo a macOS Sierra in base al quale se sono connesso a un'altra condivisione SMB su un server diverso, quando provo a collegarmi a un secondo utilizzerà l'indirizzo IP originale e il percorso di condivisione dal nuovo server.

Per 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 che ho escogitato sono connettersi per disconnettersi dal primo server prima di tentare la connessione sul secondo. Tuttavia, ciò significa che è possibile aprire una sola connessione SMB alla volta.

Una soluzione leggermente migliore era utilizzare il nome host per il server anziché l'indirizzo IP. Questo mi ha permesso di collegarmi senza problemi al secondo server SMB. Se non si conosce il nome host, è possibile ottenerlo aprendo il terminale e digitando il comando seguente.

host <ip_address>

Spero che sia di aiuto.

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