Waarom werkt SMB-bestandsdeling op Windows maar niet op macOS?

Wanneer SMB-bestandsdeling werkt op Windows maar faalt op macOS, is de server waarschijnlijk niet volledig offline. Windows heeft al aangetoond dat de share bestaat en dat ten minste één client deze kan bereiken. Het verschil zit waarschijnlijk in het gebruikte adres, opgeslagen referenties, accountidentiteit, SMB-onderhandeling, ondertekeningsvereisten, share-machtigingen of de manier waarop Finder netwerkmappen behandelt.

De veiligste methode voor probleemoplossing is om beide computers hetzelfde doel te laten testen. Begin met het exacte server-IP en de share-naam, en ga dan verder met hostnaamresolutie, authenticatie, beveiligingsonderhandeling, machtigingen, Samba-compatibiliteit en Finder-prestaties. Begin niet met het inschakelen van legacy SMB of het uitschakelen van ondertekening op de Mac.

Bevestig eerst dat Windows en macOS dezelfde share openen

Windows kan al een gekoppelde schijf hebben zoals \\192.168.1.50\Documents, terwijl de Mac-gebruiker op een serverpictogram in Finder klikt of alleen probeert smb://server-naam. Die tests kunnen wijzen op verschillende adressen, accounts of share-paden.

Noteer op de Windows-computer het werkende serveradres, de share-naam, gebruikersnaam en of de verbinding een IP-adres of hostnaam gebruikt. Druk vervolgens op Command + K in Finder en voer het equivalente pad in, zoals smb://192.168.1.50/Documents.

Als de Mac het precieze IP-en-sharepad kan openen, zijn de SMB-service en share in principe bereikbaar. Het resterende probleem ligt waarschijnlijk bij ontdekking, DNS, opgeslagen referenties of het oorspronkelijke padformaat.

Gebruik het server-IP voordat u vertrouwt op Finder-ontdekking

Windows en macOS ontdekken netwerkapparaten niet altijd op dezelfde manier. Een server kan automatisch verschijnen in Windows Verkenner terwijl deze afwezig blijft in het Finder Netwerkoverzicht.

Dit betekent niet per se dat macOS SMB niet kan gebruiken. Automatische ontdekking hangt af van DNS, mDNS, NetBIOS-compatibel gedrag, routernaamresolutie en de aankondigingen die door de bestandsserver worden gedaan. Directe toegang via smb://IP/share omzeilt het grootste deel van die ontdekkingslaag.

Als het IP werkt, laat de SMB-configuratie ongewijzigd en onderzoek in plaats daarvan de naam. Controleer of de hostnaam naar het juiste adres wordt vertaald, of de server zichzelf via mDNS adverteert en of de Mac een oud adres heeft gecached.

Wis opgeslagen referenties voordat u het serverwachtwoord opnieuw instelt

macOS kan SMB-referenties hergebruiken die in Sleutelhangertoegang zijn opgeslagen. Dit wordt verwarrend wanneer een wachtwoord verandert, dezelfde server via zowel een IP als hostnaam wordt benaderd, of de gebruiker eerder gasttoegang heeft geselecteerd.

Verbreek de gekoppelde share, open Sleutelhangertoegang en zoek naar de serverhostnaam, IP-adres en share-naam. Verwijder verouderde vermeldingen, maak opnieuw verbinding en voer het account in dat daadwerkelijk op de SMB-server bestaat.

De probleemoplossingsstappen van Apple beginnen met het verifiëren van de juiste gebruikersnaam, wachtwoord, hostnaam en share-toegang. Hoewel die pagina macOS-gehoste SMB-omgevingen behandelt, is dezelfde scheiding hier nuttig: succesvolle authenticatie en toestemming om een bepaalde share te gebruiken zijn verschillende controles.

Zorg ervoor dat de Mac de juiste accountidentiteit verzendt

Een Windows-computer kan automatisch verbinding maken met het ingelogde account. Op macOS kan het inlogvenster standaard de Mac-gebruikersnaam tonen, die mogelijk niet bestaat op de Windows-, NAS- of Samba-server.

De server verwacht mogelijk een lokaal serveraccount, Samba-gebruiker, Microsoft-account, Active Directory-identiteit of een account gekwalificeerd met een machine-, werkgroep- of domeinnaam. Afhankelijk van de omgeving kunnen geldige formaten zijn gebruikersnaam, SERVER\gebruikersnaam, of DOMAIN\gebruikersnaam.

Gebruik geen Windows Hello PIN als SMB-wachtwoord. Een PIN ontgrendelt normaal gesproken het Windows-apparaat lokaal; de bestandsserver heeft nog steeds het onderliggende accountwachtwoord of een andere ondersteunde authenticatiemethode nodig.

Controleer of poort 445 bereikbaar is vanaf de Mac

Als het exacte SMB-pad faalt voordat een inlogprompt verschijnt, controleer dan of de Mac de server kan bereiken op TCP-poort 445. Windows kan een andere netwerkinterface, VLAN, firewallprofiel of opgeslagen route gebruiken.

Op macOS is een eenvoudige test zoals nc -vz 192.168.1.50 445 kan aangeven of de poort een verbinding accepteert. Een time-out wijst op routing, VLAN-isolatie, firewallregels of een server die niet luistert op de verwachte interface.

Als poort 445 bereikbaar is maar authenticatie faalt, is het fysieke netwerkpad niet langer de hoofdsuspect. Ga verder met referenties, SMB-dialecten, ondertekening en share-machtigingen.

SMB-dialectonderhandeling kan verschillen tussen de twee clients

Oudere routers, legacy NAS-apparaten en verouderde Samba-installaties kunnen protocolcombinaties bieden die een Windows-computer accepteert, maar die een huidige Mac niet succesvol onderhandelt.

De langetermijnoplossing is om de server te configureren voor SMB2 en SMB3 in plaats van te vertrouwen op SMB1 of een verzameling client-side compatibiliteitsexcepties. Een moderne Samba-configuratie kan expliciet SMB2 als minimum en SMB3 als maximum protocol gebruiken, wat Windows en macOS een duidelijkere onderhandelingsrange geeft.

Ga er niet van uit dat Windows-compatibiliteit bewijst dat de serverconfiguratie modern is. SMB1 of legacy-authenticatie kan handmatig zijn ingeschakeld op die Windows-machine, terwijl de Mac een andere beveiligingsbasis gebruikt.

Vereisten voor ondertekening en authenticatie moeten overeenkomen

SMB-ondertekening verifieert dat berichten niet zijn gewijzigd tijdens verzending. Een verbinding kan mislukken wanneer de client en server het oneens zijn over SMB-beveiligingsmogelijkheden, authenticatie, ondertekening of validate-negotiate gedrag.

Apple merkt op dat SMB 3 de standaard verbindingsmethode is op macOS, dat geauthenticeerde SMB 3-sessies ondertekening gebruiken, en dat bepaalde directory-gebonden omgevingen kunnen falen tijdens SMB 3 validate-negotiate en sessie-ondertekeningscontroles. Dit is een specifiek Open Directory-geval, maar het illustreert waarom een generieke “verbinding mislukt” melding kan ontstaan tijdens beveiligingsonderhandeling in plaats van basisnetwerken.

Niet instellen signing_required=no of validate_neg_off=yes als eerste reactie. Het uitschakelen van validatie of ondertekening kan de bescherming tegen onderschepping verminderen. Bevestig eerst dat de server een actuele SMB-versie ondersteunt en een consistente ondertekeningsbeleid heeft.

Gasttoegang is mogelijk niet wat Windows daadwerkelijk gebruikt

Een Windows-share kan openen zonder een wachtwoordprompt weer te geven, waardoor de gebruiker aanneemt dat het een gastshare is. Windows kan eigenlijk gecachte referenties uit Credential Manager of het ingelogde account hergebruiken.

Controleer op de Windows-client de actieve SMB-sessie of verbreek de gekoppelde share en maak expliciet opnieuw verbinding. Gebruik daarna hetzelfde serveraccount op de Mac.

Als de share bewust anoniem is, bevestig dan dat de server gasttoegang toestaat en gastgebruikers koppelt aan een account met passende bestandsysteemmachtigingen. Vermijd brede gasttoegang alleen om een onopgelost inlogprobleem te omzeilen.

Share-machtigingen en bestandsysteemmachtigingen zijn gescheiden

Een Mac kan succesvol authenticeren maar toch een lege share zien, “toegang geweigerd” krijgen of de map als alleen-lezen mounten. In dat geval werkte de SMB-verbinding; de bestandsautorisatie niet.

De meeste bestandsservers evalueren minstens twee lagen. De share-configuratie bepaalt welke gebruikers toegang hebben tot de share, terwijl NTFS-machtigingen, POSIX-eigendom of filesystem-ACL’s bepalen wat die gebruikers kunnen lezen, aanmaken, wijzigen en verwijderen.

Test Windows en macOS met hetzelfde serveraccount. Als een client een andere gebruiker of groep gebruikt, zijn de resultaten niet direct vergelijkbaar. Controleer ook of de Mac per ongeluk als gast is verbonden terwijl Windows een geverifieerd account gebruikte.

Samba heeft mogelijk betere ondersteuning voor macOS-metadata nodig

Als de server Samba gebruikt, garandeert basis Windows-compatibiliteit geen ideaal macOS-gedrag. Finder en Mac-applicaties gebruiken uitgebreide attributen, Finder-metadata, alternatieve datastromen en resource forks die Windows-clients mogelijk nooit opvragen.

Een Samba-configuratie bedoeld voor gemengd gebruik van Windows en macOS kan macOS-metadata inschakelen via fruit en streams_xattr. Een typische configuratie kan vfs objects = catia fruit streams_xattr bevatten zodat Apple-specifieke metadata kan worden weergegeven zonder normale Windows-toegang te breken.

Deze modules zijn vooral relevant wanneer de share wordt gemount, maar bestandsnamen, uitgebreide attributen, resource forks, Time Machine-gedrag of Finder-metadata inconsistent zijn. Ze vervangen geen oplossing voor een verkeerd wachtwoord of een onbereikbare server.

Prestaties van Finder kunnen eruitzien als verbindingsproblemen

Soms is de share verbonden, maar toont Finder een lege map, draait enkele seconden door of reageert niet bij het openen van een grote map. De gebruiker ervaart dit als “SMB is kapot,” ook al is de mount zelf gelukt.

Finder kan bestandsmetadata, rechten, previews, resource-informatie en directory-updates opvragen. Deze bewerkingen beïnvloeden een Mac anders dan een basis Windows-directorylijst, vooral bij grote mappen of servers zonder Apple-gerichte metadata-afhandeling.

Test dezelfde aangekoppelde share in Terminal met commando's zoals ls, of kopieer één groot bestand zonder eerst een grote map te doorzoeken. Als Terminal-toegang werkt terwijl Finder traag blijft, los dan metadata en directory-opsomming op in plaats van authenticatie.

Een trage share is niet hetzelfde als een mislukte share

Combineer geen authenticatiefouten en overdrachtssnelheidsproblemen in één diagnose. Een Mac die een share niet kan aankoppelen heeft een ander probleem dan een Mac die succesvol aankoppelt maar traag schrijft.

In een Unraid-communitygeval bereikten leesbewerkingen ongeveer 180 MB/s terwijl schrijven daalde tot ongeveer 2 MB/s, hoewel lokale schijf- en netwerktests veel sneller waren. Dat is nuttig als symptoompatroon, maar het bewijst niet dat ondertekening de universele oorzaak is; opslagindeling, cachegedrag, kleine bestanden, clientinterfaces en Samba-instellingen kunnen vergelijkbare asymmetrie veroorzaken.

Meet afzonderlijk: netwerkdoorvoer, één grote-bestand-leesbewerking, één grote-bestand-schrijfbewerking en een werklast met veel kleine bestanden. Pas SMB-prestatie-instellingen alleen aan nadat is vastgesteld welke test daadwerkelijk traag is.

Docker-gebaseerde Samba voegt problemen toe met gebruikers- en volumemapping

Een Samba-container kan Windows-verbindingen accepteren terwijl macOS wordt geweigerd omdat de twee clients niet dezelfde identiteit presenteren. De container kan ook poort 445 correct publiceren terwijl het aangekoppelde volume incompatibele eigendom of ACL's heeft.

Controleer het Samba-account binnen de container, de host UID en GID die worden gebruikt voor aangekoppelde opslag, de lees-/schrijfrechten van het volume, de gepubliceerde poort en de effectieve smb.conf. Bekijk de containerlogs terwijl de Mac probeert verbinding te maken.

Als het verzoek de container bereikt en authenticatie slaagt, stop dan met het wijzigen van Docker-netwerken. Richt je op gebruikersmapping, share-configuratie, bestandseigendom en Apple-metadata-ondersteuning.

Behandel client-side SMB-aanpassingen als de laatste laag

Online oplossingen bieden vaak een lange /etc/nsmb.conf bestand dat ondertekening uitschakelt, directory caching wijzigt, een protocol forceert of multichannel-gedrag aanpast. Alle instellingen tegelijk kopiëren maakt het onmogelijk te weten welke wijziging van belang was.

Community-geteste wijzigingen met betrekking tot directory caching en bekabeld multichannel-gedrag kunnen specifieke macOS-, netwerk- en Unraid-combinaties helpen. Dezelfde discussie bevat ook beveiligingsverminderende opties en conflicterende resultaten, dus het moet worden behandeld als experimentele probleemoplossing in plaats van een universele configuratie.

Voor het bewerken nsmb.conf, sla de huidige status op en wijzig één parameter tegelijk. Test dezelfde map en bestandsoverdracht opnieuw na elke wijziging. Vermijd het uitschakelen van ondertekening alleen voor snelheid, tenzij de beveiligingsoverdracht begrepen wordt en de share beperkt is tot een vertrouwd netwerk.

Volg een gelaagde probleemoplossingsvolgorde

Het meest effectieve proces begint met het exacte doel en beweegt naar steeds specifiekere clientgedragingen. Bewerk Samba, Keychain, DNS, ondertekening en Finder-instellingen niet tegelijkertijd.

Begin met het werkende Windows-pad, test smb://IP/share op macOS, en bevestig poort 445. Wis vervolgens opgeslagen inloggegevens, verifieer de accountidentiteit en controleer SMB2/3-ondersteuning. Onderzoek daarna ondertekening, share-permissies, bestandssysteem-ACL's, Samba Apple-extensies en Finder-prestaties.

Deze volgorde behoudt het bewijs van elke test. Een IP-tegen-hostnaam resultaat identificeert ontdekkingsproblemen; een inlogprompt identificeert een bereikbare SMB-service; een aangekoppelde maar alleen-lezen share identificeert permissies; en een werkende Terminal-sessie met een trage Finder-venster identificeert client-side bladergedrag.

Belangrijkste conclusie

Als SMB op Windows werkt maar faalt op macOS, gebruik dan de Windows-verbinding als referentie en niet als bewijs dat elke serverinstelling correct is. De twee clients kunnen verschillende adressen, gebruikersnamen, gecachte inloggegevens, protocolmogelijkheden of rechten gebruiken.

Begin met het exacte smb://IP/share pad. Als het IP werkt maar de hostnaam faalt, los dan het ontdekkingprobleem op. Als het inloggen faalt, wis dan de Sleutelhanger-inloggegevens en controleer het serveraccount. Als authenticatie werkt maar bestandstoegang niet, controleer dan share-rechten en bestandssysteem-ACL's. Als de share wordt gekoppeld maar Finder traag is, ga dan verder met metadata, Samba Apple-extensies en gemeten prestatietests.

Clientopties die signing of onderhandelingscontroles uitschakelen, moeten een laatste redmiddel blijven. Een actuele SMB2/3-server, duidelijke accountkoppeling, correcte rechten en bewuste macOS-metadata-ondersteuning bieden een betrouwbaardere oplossing dan het verzwakken van de beveiliging om een onverklaarde configuratie-inconsistentie te omzeilen.

FAQ

Waarom kan Windows mijn SMB-server zien maar Finder niet?

Windows en macOS kunnen verschillende ontdekkingsmethoden gebruiken. Probeer het exacte server-IP en het sharepad met smb://192.168.x.x/shareAls dat werkt, ligt het probleem bij hostnaamresolutie of ontdekking en niet bij SMB zelf.

Waarom blijft mijn Mac een wachtwoord weigeren dat op Windows werkt?

De Mac kan een oud wachtwoord uit Sleutelhanger hergebruiken of de lokale macOS-gebruikersnaam in plaats van het serveraccount verzenden. Verwijder de opgeslagen SMB-inloggegevens en maak opnieuw verbinding met het account dat op de bestandsserver is ingesteld.

Moet ik SMB-signing uitschakelen op macOS?

Niet als eerste oplossing. Het uitschakelen van signing vermindert de berichtintegriteitsbescherming en kan een verouderde of inconsistente serverconfiguratie verbergen. Controleer eerst SMB2/3-ondersteuning, inloggegevens, rechten en server signing-beleid.

Waarom kan de Mac de share koppelen maar geen bestanden aanmaken of bewerken?

De verbinding en authenticatie zijn geslaagd, maar de gebruiker heeft mogelijk geen schrijfrechten in de SMB-shareconfiguratie of de onderliggende NTFS/POSIX-bestandssysteemrechten.

Waarom is Finder traag terwijl Windows Verkenner snel is?

Finder vraagt om extra metadata en kan meer tijd besteden aan het doorzoeken van grote mappen. Test een directe overdracht van grote bestanden en vergelijk Finder met Terminal voordat je de beveiligingsinstellingen wijzigt.