Perché la condivisione file SMB funziona su Windows ma fallisce su macOS?

Quando la condivisione file SMB funziona su Windows ma fallisce su macOS, probabilmente il server non è completamente offline. Windows ha già dimostrato che la condivisione esiste e che almeno un client può raggiungerla. La differenza è più probabilmente nell'indirizzo usato, nelle credenziali salvate, nell'identità dell'account, nella negoziazione SMB, nei requisiti di firma, nei permessi della condivisione o nel modo in cui il Finder gestisce le cartelle di rete.

Il metodo di risoluzione dei problemi più sicuro è far testare a entrambi i computer lo stesso obiettivo. Inizia con l'IP esatto del server e il nome della condivisione, poi passa alla risoluzione del nome host, autenticazione, negoziazione della sicurezza, permessi, compatibilità Samba e prestazioni del Finder. Non iniziare abilitando SMB legacy o disabilitando la firma su Mac.

Conferma prima che Windows e macOS stiano aprendo la stessa condivisione

Windows potrebbe già avere un'unità mappata come \\192.168.1.50\Documents, mentre l'utente Mac sta cliccando un'icona del server nel Finder o sta provando solo smb://nome-server. Questi test possono indicare indirizzi, account o percorsi di condivisione diversi.

Sul computer Windows, annota l'indirizzo del server funzionante, il nome della condivisione, il nome utente e se la connessione usa un indirizzo IP o un nome host. Poi premi Command + K nel Finder e inserisci il percorso equivalente, come smb://192.168.1.50/Documents.

Se il Mac può aprire il percorso preciso IP-e-condivisione, il servizio SMB e la condivisione sono fondamentalmente raggiungibili. Il problema rimanente è più probabilmente la scoperta, il DNS, le credenziali memorizzate o il formato originale del percorso.

Usa l'IP del server prima di affidarti alla scoperta del Finder

Windows e macOS non scoprono sempre i dispositivi di rete allo stesso modo. Un server può apparire automaticamente in Esplora file di Windows mentre rimane assente nella vista Rete del Finder.

Questo non significa necessariamente che macOS non possa usare SMB. La scoperta automatica dipende da DNS, mDNS, comportamento compatibile con NetBIOS, risoluzione del nome del router e dagli annunci fatti dal file server. Accesso diretto tramite smb://IP/share aggira la maggior parte di quel livello di scoperta.

Se l'IP funziona, lascia invariata la configurazione SMB e indaga sul nome invece. Verifica se il nome host risolve all'indirizzo corretto, se il server si pubblicizza tramite mDNS e se il Mac ha memorizzato un indirizzo vecchio.

Cancella le credenziali salvate prima di reimpostare la password del server

macOS può riutilizzare le credenziali SMB memorizzate in Portachiavi. Questo può creare confusione quando la password cambia, lo stesso server è accessibile sia tramite IP che nome host, o l'utente ha precedentemente selezionato l'accesso guest.

Disconnetti la condivisione montata, apri Accesso Portachiavi e cerca il nome host del server, l'indirizzo IP e il nome della condivisione. Rimuovi le voci obsolete, quindi riconnetti e inserisci l'account che esiste effettivamente sul server SMB.

I passaggi di risoluzione problemi di Apple iniziano verificando il nome utente, password, nome host e accesso alla condivisione corretti. Sebbene quella pagina si riferisca ad ambienti SMB ospitati su macOS, la stessa distinzione è utile qui: autenticazione riuscita e permesso di usare una condivisione specifica sono controlli diversi.

Assicurati che il Mac stia inviando l'identità account corretta

Un computer Windows può connettersi automaticamente con l'account con cui è stato effettuato l'accesso. Su macOS, la finestra di login può predefinire il nome utente del Mac, che potrebbe non esistere sul server Windows, NAS o Samba.

Il server potrebbe aspettarsi un account locale del server, un utente Samba, un account Microsoft, un'identità Active Directory o un account qualificato con nome macchina, gruppo di lavoro o dominio. A seconda dell'ambiente, i formati validi possono includere username, SERVER\username, oppure DOMAIN\username.

Non usare un PIN di Windows Hello come password SMB. Un PIN normalmente sblocca il dispositivo Windows localmente; il server file necessita ancora della password dell'account sottostante o di un altro metodo di autenticazione supportato.

Verifica se la porta 445 è raggiungibile dal Mac

Se il percorso SMB esatto fallisce prima che appaia la richiesta di login, verifica che il Mac possa raggiungere il server sulla porta TCP 445. Windows potrebbe utilizzare un'interfaccia di rete, VLAN, profilo firewall o percorso salvato diverso.

Su macOS, un test semplice come nc -vz 192.168.1.50 445 può mostrare se la porta accetta una connessione. Un timeout indica problemi di routing, isolamento VLAN, regole del firewall o un server che non ascolta sull'interfaccia prevista.

Se la porta 445 è raggiungibile ma l'autenticazione fallisce, il percorso di rete fisico non è più il principale sospettato. Passare a credenziali, dialetti SMB, firma e permessi di condivisione.

La negoziazione del dialetto SMB può differire tra i due client

Router più vecchi, dispositivi NAS legacy e installazioni Samba obsolete possono offrire combinazioni di protocolli che un computer Windows accetta ma un Mac attuale non negozia con successo.

La soluzione a lungo termine è configurare il server per SMB2 e SMB3 invece di affidarsi a SMB1 o a una raccolta di eccezioni di compatibilità lato client. Una configurazione Samba moderna può esplicitamente usare SMB2 come protocollo minimo e SMB3 come massimo, che offre a Windows e macOS un intervallo di negoziazione più chiaro.

Non presumere che la compatibilità con Windows dimostri che la configurazione del server sia moderna. SMB1 o l'autenticazione legacy potrebbero essere stati abilitati manualmente su quella macchina Windows, mentre il Mac utilizza una base di sicurezza diversa.

I requisiti di firma e autenticazione devono corrispondere

La firma SMB verifica che i messaggi non siano stati modificati durante il transito. Una connessione può fallire quando client e server non sono d'accordo sulle capacità di sicurezza SMB, autenticazione, firma o comportamento di convalida-negoziazione.

Apple nota che SMB 3 è il metodo di connessione predefinito su macOS, che le sessioni SMB 3 autenticate utilizzano la firma, e che alcuni ambienti legati a directory possono fallire durante i controlli di convalida-negoziazione e firma sessione SMB 3. Questo è un caso specifico di Open Directory, ma illustra perché un messaggio generico di “connessione fallita” può originare durante la negoziazione di sicurezza piuttosto che durante la rete di base.

Non impostare signing_required=no o validate_neg_off=yes come prima risposta. Disabilitare la convalida o la firma può ridurre la protezione contro l'intercettazione. Prima confermare che il server supporti una versione SMB attuale e abbia una politica di firma coerente.

L'accesso guest potrebbe non essere ciò che Windows sta effettivamente utilizzando

Una condivisione Windows può aprirsi senza mostrare un prompt per la password, portando l'utente a presumere che si tratti di una condivisione guest. In realtà, Windows potrebbe riutilizzare credenziali memorizzate nella cache da Credential Manager o dall'account connesso.

Sul client Windows, ispeziona la sessione SMB attiva o disconnetti la condivisione mappata e riconnettila esplicitamente. Poi usa lo stesso account server sul Mac.

Se la condivisione è intenzionalmente anonima, conferma che il server permette l'accesso ospite e mappa gli utenti ospiti a un account con permessi filesystem appropriati. Evita di abilitare un accesso ospite ampio solo per bypassare un problema di credenziali non risolto.

I permessi della condivisione e i permessi del filesystem sono separati

Un Mac può autenticarsi con successo ma vedere comunque una condivisione vuota, ricevere “permesso negato” o montare la cartella in sola lettura. In quel caso, la connessione SMB ha funzionato; l'autorizzazione ai file no.

La maggior parte dei server di file valuta almeno due livelli. La configurazione della condivisione decide quali utenti possono accedervi, mentre i permessi NTFS, la proprietà POSIX o le ACL del filesystem decidono cosa quegli utenti possono leggere, creare, modificare e cancellare.

Testa Windows e macOS con lo stesso account server. Se un client usa un utente o gruppo diverso, i risultati non sono direttamente comparabili. Verifica anche se il Mac si è connesso accidentalmente come ospite mentre Windows usava un account autenticato.

Samba potrebbe necessitare di un migliore supporto per i metadati macOS

Se il server usa Samba, la compatibilità base con Windows non garantisce un comportamento ideale su macOS. Finder e le applicazioni Mac usano attributi estesi, metadati di Finder, flussi di dati alternativi e fork di risorse che i client Windows potrebbero non richiedere mai.

Una configurazione Samba pensata per un uso misto Windows e macOS può abilitare i metadati macOS tramite fruit e streams_xattr. Una configurazione tipica può includere vfs objects = catia fruit streams_xattr così i metadati specifici Apple possono essere rappresentati senza compromettere l'accesso normale da Windows.

Questi moduli sono più rilevanti quando la condivisione si monta ma i nomi dei file, gli attributi estesi, le fork di risorse, il comportamento di Time Machine o i metadati di Finder sono incoerenti. Non sostituiscono la correzione di una password errata o di un server irraggiungibile.

I problemi di prestazioni di Finder possono sembrare guasti di connessione

A volte la condivisione è connessa, ma Finder mostra una directory vuota, gira per diversi secondi o diventa non rispondente durante l'apertura di una cartella grande. L'utente percepisce questo come “SMB è rotto”, anche se il mount è riuscito.

Finder può richiedere metadati dei file, permessi, anteprime, informazioni sulle risorse e aggiornamenti della directory. Queste operazioni influenzano un Mac in modo diverso rispetto a una semplice lista di directory Windows, specialmente su cartelle grandi o server senza gestione dei metadati orientata ad Apple.

Testa la stessa condivisione montata in Terminal con comandi come ls, o copia un file grande senza prima sfogliare una directory grande. Se l'accesso da Terminal funziona mentre Finder rimane lento, risolvi i problemi di metadati ed enumerazione della directory piuttosto che di autenticazione.

Una condivisione lenta non è la stessa cosa di una condivisione fallita

Non combinare i fallimenti di autenticazione con i problemi di velocità di trasferimento in una sola diagnosi. Un Mac che non riesce a montare una condivisione ha un problema diverso da un Mac che monta con successo ma scrive lentamente.

In un caso della community Unraid, le letture hanno raggiunto circa 180 MB/s mentre le scritture sono scese a circa 2 MB/s, anche se i test locali su disco e rete erano molto più veloci. Questo è utile come modello di sintomo, ma non dimostra che la firma sia la causa universale; layout dello storage, comportamento della cache, file piccoli, interfacce client e impostazioni Samba possono produrre simile asimmetria.

Misura separatamente: throughput di rete, lettura di un file grande, scrittura di un file grande e carico di lavoro con molti file piccoli. Regola le impostazioni di prestazione SMB solo dopo aver identificato quale test è effettivamente lento.

Samba basato su Docker aggiunge problemi di mappatura utenti e volumi

Un container Samba può accettare connessioni Windows rifiutando quelle macOS perché i due client non presentano la stessa identità. Il container può anche pubblicare correttamente la porta 445 mentre il volume montato ha una proprietà o ACL incompatibili.

Verifica l'account Samba all'interno del container, l'UID e il GID dell'host usati per lo storage montato, i permessi di lettura/scrittura del volume, la porta pubblicata e l'effettivo smb.conf. Controlla i log del container mentre il Mac tenta di connettersi.

Se la richiesta raggiunge il container e l'autenticazione ha successo, smetti di modificare la rete Docker. Concentrati sulla mappatura utenti, configurazione delle condivisioni, proprietà del filesystem e supporto ai metadati Apple.

Tratta le modifiche SMB lato client come l'ultimo strato

Le correzioni online spesso forniscono un lungo /etc/nsmb.conf file che disabilita la firma, modifica la memorizzazione nella cache delle directory, forza un protocollo o modifica il comportamento multicanale. Copiare tutte queste impostazioni contemporaneamente rende impossibile sapere quale modifica abbia avuto effetto.

Modifiche testate dalla comunità che coinvolgono la memorizzazione nella cache delle directory e il comportamento multicanale cablato possono aiutare combinazioni specifiche di macOS, rete e Unraid. La stessa discussione include anche opzioni che riducono la sicurezza e risultati contrastanti, quindi dovrebbe essere considerata una risoluzione sperimentale piuttosto che una configurazione universale.

Prima di modificare nsmb.conf, salva lo stato attuale e cambia un parametro alla volta. Riprova la stessa cartella e il trasferimento file dopo ogni modifica. Evita di disabilitare la firma solo per velocità a meno che non si comprenda il compromesso di sicurezza e la condivisione sia limitata a una rete fidata.

Segui un ordine di risoluzione a strati

Il processo più efficace inizia con l'obiettivo esatto e procede verso comportamenti client sempre più specifici. Non modificare contemporaneamente le impostazioni di Samba, Keychain, DNS, firma e Finder.

Inizia con il percorso Windows funzionante, testa smb://IP/share su macOS, e conferma la porta 445. Poi cancella le credenziali salvate, verifica l'identità dell'account e controlla il supporto SMB2/3. Successivamente, esamina la firma, i permessi di condivisione, le ACL del filesystem, le estensioni Apple di Samba e le prestazioni di Finder.

Questa sequenza conserva le prove di ogni test. Un risultato IP contro nome host identifica problemi di scoperta; un prompt di accesso identifica un servizio SMB raggiungibile; una condivisione montata ma in sola lettura identifica i permessi; e una sessione Terminal funzionante con una finestra Finder lenta identifica il comportamento di navigazione lato client.

Conclusione finale

Quando SMB funziona su Windows ma fallisce su macOS, usa la connessione Windows come riferimento e non come prova che ogni impostazione del server sia corretta. I due client potrebbero usare indirizzi, nomi utente, credenziali memorizzate, capacità del protocollo o permessi diversi.

Inizia con l'esatto smb://IP/share percorso. Se l'IP funziona ma il nome host no, risolvi i problemi di scoperta. Se il login fallisce, cancella le credenziali da Portachiavi e verifica l'account del server. Se l'autenticazione funziona ma l'accesso ai file no, controlla i permessi della condivisione e gli ACL del filesystem. Se la condivisione si monta ma Finder è lento, passa ai metadati, alle estensioni Apple di Samba e ai test di prestazioni misurate.

Le opzioni lato client che disabilitano la firma o i controlli di negoziazione dovrebbero rimanere l'ultima risorsa. Un server SMB2/3 aggiornato, una mappatura chiara degli account, permessi corretti e un supporto deliberato dei metadati macOS offrono una soluzione più affidabile che indebolire la sicurezza per accomodare una configurazione inspiegabile.

FAQ

Perché Windows vede il mio server SMB ma Finder no?

Windows e macOS possono usare metodi di scoperta diversi. Prova l'indirizzo IP esatto del server e il percorso della condivisione con smb://192.168.x.x/shareSe funziona, il problema è la risoluzione del nome host o la scoperta, non SMB in sé.

Perché il mio Mac continua a rifiutare una password che funziona su Windows?

Il Mac potrebbe riutilizzare una vecchia password da Portachiavi o inviare il nome utente locale di macOS invece dell'account del server. Rimuovi la credenziale SMB memorizzata e riconnettiti con l'account definito sul file server.

Devo disabilitare la firma SMB su macOS?

Non come prima soluzione. Disabilitare la firma riduce la protezione dell'integrità dei messaggi e potrebbe nascondere una configurazione del server obsoleta o incoerente. Verifica prima il supporto SMB2/3, le credenziali, i permessi e la politica di firma del server.

Perché il Mac può montare la condivisione ma non creare o modificare file?

La connessione e l'autenticazione sono riuscite, ma l'utente potrebbe non avere accesso in scrittura nella configurazione della condivisione SMB o nei permessi del filesystem NTFS/POSIX sottostante.

Perché Finder è lento mentre Esplora file di Windows è veloce?

Finder richiede metadati aggiuntivi e potrebbe impiegare più tempo per enumerare directory di grandi dimensioni. Esegui un test di trasferimento diretto di un file grande e confronta Finder con Terminal prima di modificare le impostazioni di sicurezza.