Varför fungerar SMB-fildelning på Windows men inte på macOS?

När SMB-fildelning fungerar på Windows men misslyckas på macOS är servern troligen inte helt offline. Windows har redan visat att delningen finns och att åtminstone en klient kan nå den. Skillnaden ligger troligen i den använda adressen, sparade inloggningsuppgifter, kontoinformation, SMB-förhandling, signeringskrav, delningsbehörigheter eller hur Finder hanterar nätverksmappar.

Den säkraste felsökningsmetoden är att låta båda datorerna testa samma mål. Börja med exakt server-IP och delningsnamn, gå sedan vidare till värdnamnsupplösning, autentisering, säkerhetsförhandling, behörigheter, Samba-kompatibilitet och Finder-prestanda. Börja inte med att aktivera äldre SMB eller inaktivera signering på Mac.

Bekräfta först att Windows och macOS öppnar samma delning

Windows kan redan ha en mappad enhet som \\192.168.1.50\Documents, medan Mac-användaren klickar på en serverikon i Finder eller bara försöker smb://server-namn. Dessa tester kan peka på olika adresser, konton eller delningsvägar.

På Windows-datorn, notera den fungerande serveradressen, delningsnamnet, användarnamnet och om anslutningen använder en IP-adress eller ett värdnamn. Tryck sedan på Command + K i Finder och ange motsvarande sökväg, till exempel smb://192.168.1.50/Documents.

Om Macen kan öppna den exakta IP- och delningsvägen är SMB-tjänsten och delningen i grunden nåbara. Det kvarvarande problemet är troligen upptäckt, DNS, sparade inloggningsuppgifter eller det ursprungliga sökvägsformatet.

Använd serverns IP innan du förlitar dig på Finder-upptäckt

Windows och macOS upptäcker inte alltid nätverksenheter på samma sätt. En server kan dyka upp automatiskt i Windows Filutforskare medan den saknas i Finders Nätverksvy.

Detta betyder inte nödvändigtvis att macOS inte kan använda SMB. Automatisk upptäckt beror på DNS, mDNS, NetBIOS-kompatibelt beteende, routerns namnupplösning och de meddelanden som filservern skickar. Direkt åtkomst via smb://IP/share bypassar det mesta av det lagret för upptäckt.

Om IP-adressen fungerar, behåll SMB-konfigurationen oförändrad och undersök istället namnet. Kontrollera om värdnamnet löser till rätt adress, om servern annonserar sig via mDNS och om Macen har cachat en gammal adress.

Rensa sparade referenser innan du återställer serverns lösenord

macOS kan återanvända SMB-referenser som lagrats i Nyckelhanteraren. Detta blir förvirrande när ett lösenord ändras, samma server nås både via IP och värdnamn, eller användaren tidigare valt gäståtkomst.

Koppla bort den monterade delningen, öppna Nyckelhanteraren och sök efter serverns värdnamn, IP-adress och delningsnamn. Ta bort gamla poster, anslut sedan igen och ange det konto som faktiskt finns på SMB-servern.

Apples felsökningssteg börjar med att verifiera rätt användarnamn, lösenord, värdnamn och delningsåtkomst. Även om den sidan handlar om SMB-miljöer som hostas på macOS, är samma uppdelning användbar här: lyckad autentisering och behörighet att använda en viss delning är olika kontroller.

Se till att Macen skickar rätt kontoinformation

En Windows-dator kan ansluta automatiskt med sitt inloggade konto. På macOS kan inloggningsdialogen som standard visa Mac-användarnamnet, vilket kanske inte finns på Windows-, NAS- eller Samba-servern.

Servern kan förvänta sig ett lokalt serverkonto, Samba-användare, Microsoft-konto, Active Directory-identitet eller ett konto kvalificerat med maskin-, arbetsgrupps- eller domännamn. Beroende på miljön kan giltiga format inkludera användarnamn, SERVER\användarnamn, eller DOMAIN\användarnamn.

Använd inte en Windows Hello PIN som SMB-lösenord. En PIN låser normalt upp Windows-enheten lokalt; filservern behöver fortfarande det underliggande kontolösenordet eller en annan stödd autentiseringsmetod.

Kontrollera om port 445 är nåbar från Macen

Om den exakta SMB-sökvägen misslyckas innan en inloggningsprompt visas, kontrollera att Macen kan nå servern på TCP-port 445. Windows kan använda ett annat nätverksgränssnitt, VLAN, brandväggsprofil eller sparad rutt.

På macOS kan ett enkelt test som nc -vz 192.168.1.50 445 kan visa om porten accepterar en anslutning. En timeout tyder på routing, VLAN-isolering, brandväggsregler eller en server som inte lyssnar på det förväntade gränssnittet.

Om port 445 är nåbar men autentisering misslyckas är den fysiska nätverksvägen inte längre huvudmisstänkt. Gå vidare till autentiseringsuppgifter, SMB-dialekter, signering och delningsbehörigheter.

SMB-dialektförhandling kan skilja sig mellan de två klienterna

Äldre routrar, äldre NAS-enheter och föråldrade Samba-installationer kan erbjuda protokollkombinationer som en Windows-dator accepterar men som en aktuell Mac inte förhandlar fram framgångsrikt.

Den långsiktiga lösningen är att konfigurera servern för SMB2 och SMB3 istället för att förlita sig på SMB1 eller en samling klientbaserade kompatibilitetsundantag. En modern Samba-konfiguration kan uttryckligen använda SMB2 som minimum och SMB3 som maximum-protokoll, vilket ger Windows och macOS ett tydligare förhandlingsintervall.

Anta inte att Windows-kompatibilitet bevisar att serverkonfigurationen är modern. SMB1 eller äldre autentisering kan ha aktiverats manuellt på den Windows-datorn, medan Mac använder en annan säkerhetsnivå.

Krav på signering och autentisering måste stämma överens

SMB-signering verifierar att meddelanden inte har ändrats under överföringen. En anslutning kan misslyckas när klienten och servern är oense om SMB-säkerhetsfunktioner, autentisering, signering eller validate-negotiate-beteende.

Apple noterar att SMB 3 är standardanslutningsmetoden på macOS, att autentiserade SMB 3-sessioner använder signering, och att vissa katalogbundna miljöer kan misslyckas under SMB 3 validate-negotiate och session-signeringskontroller. Det är ett specifikt Open Directory-fall, men det illustrerar varför ett generiskt ”anslutningen misslyckades”-meddelande kan uppstå under säkerhetsförhandling snarare än grundläggande nätverk.

Ställ inte in signing_required=no eller validate_neg_off=yes som första svar. Att inaktivera validering eller signering kan minska skyddet mot avlyssning. Bekräfta först att servern stöder en aktuell SMB-version och har en konsekvent signeringspolicy.

Gäståtkomst är kanske inte vad Windows faktiskt använder

En Windows-delning kan öppnas utan att visa en lösenordsprompt, vilket får användaren att tro att det är en gästdelning. Windows kan faktiskt återanvända cachade autentiseringsuppgifter från Credential Manager eller det inloggade kontot.

På Windows-klienten, inspektera den aktiva SMB-sessionen eller koppla bort den mappade delningen och anslut igen uttryckligen. Använd sedan samma serverkonto på Mac.

Om delningen är avsiktligt anonym, bekräfta att servern tillåter gäståtkomst och mappar gästanvändare till ett konto med lämpliga filsystembehörigheter. Undvik att aktivera bred gäståtkomst bara för att kringgå ett olöst autentiseringsproblem.

Delningsbehörigheter och filsystembehörigheter är separata

En Mac kan autentisera framgångsrikt men ändå se en tom delning, få ”åtkomst nekad” eller montera mappen som skrivskyddad. I det fallet fungerade SMB-anslutningen; filbehörigheten gjorde det inte.

De flesta filservrar utvärderar minst två lager. Delningskonfigurationen avgör vilka användare som kan komma åt delningen, medan NTFS-behörigheter, POSIX-ägarskap eller filsystemets ACL:er avgör vad dessa användare kan läsa, skapa, ändra och ta bort.

Testa Windows och macOS med samma serverkonto. Om en klient använder en annan användare eller grupp är deras resultat inte direkt jämförbara. Kontrollera också om Mac av misstag anslöt som gäst medan Windows använde ett autentiserat konto.

Samba kan behöva bättre stöd för macOS-metadata

Om servern använder Samba garanterar grundläggande Windows-kompatibilitet inte idealiskt macOS-beteende. Finder och Mac-appar använder utökade attribut, Finder-metadata, alternativa dataströmmar och resursforkar som Windows-klienter kanske aldrig begär.

En Samba-konfiguration avsedd för blandad Windows- och macOS-användning kan aktivera macOS-metadata via fruit och streams_xattr. En typisk konfiguration kan inkludera vfs objects = catia fruit streams_xattr så att Apple-specifik metadata kan representeras utan att störa normal Windows-åtkomst.

Dessa moduler är mest relevanta när delningen monteras men filnamn, utökade attribut, resursforkar, Time Machine-beteende eller Finder-metadata är inkonsekventa. De ersätter inte att åtgärda ett felaktigt lösenord eller en otillgänglig server.

Prestandaproblem i Finder kan se ut som anslutningsfel

Ibland är delningen ansluten, men Finder visar en tom katalog, snurrar i flera sekunder eller slutar svara när en stor mapp öppnas. Användaren upplever detta som att ”SMB är trasigt”, även om monteringen lyckades.

Finder kan begära filmetadata, behörigheter, förhandsvisningar, resursinformation och kataloguppdateringar. Dessa operationer påverkar en Mac annorlunda än en grundläggande Windows-kataloglista, särskilt på stora mappar eller servrar utan Apple-orienterad metadatahantering.

Testa samma monterade delning i Terminal med kommandon som ls, eller kopiera en stor fil utan att först bläddra i en stor katalog. Om Terminal-åtkomst fungerar medan Finder förblir långsam, felsök metadata och kataloguppräkning snarare än autentisering.

En långsam delning är inte samma sak som en misslyckad delning

Kombinera inte autentiseringsfel och överföringshastighetsproblem i en diagnos. En Mac som inte kan montera en delning har ett annat problem än en Mac som monterar framgångsrikt men skriver långsamt.

I ett fall i Unraid-communityn nådde läsningar cirka 180 MB/s medan skrivningar föll till ungefär 2 MB/s, trots att lokala disk- och nätverkstester var mycket snabbare. Det är användbart som ett symptommönster, men det bevisar inte att signering är den universella orsaken; lagringslayout, cachebeteende, små filer, klientgränssnitt och Samba-inställningar kan ge liknande asymmetri.

Mät separat: nätverksprestanda, en stor fil-läsning, en stor fil-skrivning och en arbetsbelastning med många små filer. Justera SMB-prestandainställningar först efter att ha identifierat vilket test som faktiskt är långsamt.

Docker-baserad Samba lägger till problem med användar- och volymkartläggning

En Samba-container kan acceptera Windows-anslutningar men avvisa macOS eftersom de två klienterna inte presenterar samma identitet. Containern kan också publicera port 445 korrekt medan dess monterade volym har inkompatibelt ägarskap eller ACL:er.

Kontrollera Samba-kontot inuti containern, värdens UID och GID som används för monterad lagring, volymens läs-/skrivrättigheter, den publicerade porten och den effektiva smb.confGranska containerloggar medan Mac försöker ansluta.

Om förfrågan når containern och autentiseringen lyckas, sluta ändra Docker-nätverk. Fokusera på användarkartläggning, delningskonfiguration, filsystemägarskap och stöd för Apple-metadata.

Behandla klientbaserade SMB-justeringar som det sista lagret

Online-lösningar ger ofta en lång /etc/nsmb.conf fil som inaktiverar signering, ändrar katalogcache, tvingar en protokollversion eller modifierar multikanalsbeteende. Att kopiera alla dessa inställningar samtidigt gör det omöjligt att veta vilken ändring som var avgörande.

Gemenskapsgranskade ändringar som involverar katalogcache och trådbundet multikanalsbeteende kan hjälpa specifika kombinationer av macOS, nätverk och Unraid. Samma diskussion inkluderar också säkerhetsminskande alternativ och motstridiga resultat, så det bör behandlas som experimentell felsökning snarare än en universell konfiguration.

Innan redigering nsmb.conf, spara det aktuella tillståndet och ändra en parameter i taget. Testa samma mapp och filöverföring efter varje ändring. Undvik att inaktivera signering enbart för hastighet om inte säkerhetsavvägningen förstås och delningen är begränsad till ett betrott nätverk.

Följ en lagerindelad felsökningsordning

Den mest effektiva processen börjar med det exakta målet och går mot allt mer specifikt klientbeteende. Redigera inte Samba, Keychain, DNS, signering och Finder-inställningar samtidigt.

Börja med den fungerande Windows-sökvägen, testa smb://IP/share på macOS, och bekräfta port 445. Rensa sedan sparade autentiseringsuppgifter, verifiera kontots identitet och kontrollera SMB2/3-stöd. Undersök därefter signering, delningsbehörigheter, filsystemets ACL:er, Samba Apple-tillägg och Finder-prestanda.

Denna sekvens bevarar bevisen från varje test. Ett resultat som skiljer IP från värdnamn identifierar upptäcktsproblem; en inloggningsprompt identifierar en nåbar SMB-tjänst; en monterad men skrivskyddad delning identifierar behörigheter; och en fungerande Terminal-session med ett långsamt Finder-fönster identifierar klientens bläddringsbeteende.

Slutsats

När SMB fungerar på Windows men misslyckas på macOS, använd Windows-anslutningen som referens snarare än bevis på att alla serverinställningar är korrekta. De två klienterna kan använda olika adresser, användarnamn, cachade autentiseringsuppgifter, protokollkapaciteter eller behörigheter.

Börja med exakt smb://IP/share sökväg. Om IP-adressen fungerar men värdnamnet misslyckas, felsök upptäckten. Om inloggningen misslyckas, rensa Nyckelringens autentiseringsuppgifter och verifiera serverkontot. Om autentiseringen fungerar men filåtkomst inte gör det, kontrollera delningsbehörigheter och filsystemets ACL:er. Om delningen monteras men Finder är långsamt, gå vidare till metadata, Samba Apple-tillägg och mätbara prestandatester.

Klientsidans alternativ som inaktiverar signering eller förhandlingskontroller bör förbli en sista utväg. En aktuell SMB2/3-server, tydlig kontokartläggning, korrekta behörigheter och avsiktligt macOS-metadatasupport ger en mer pålitlig lösning än att försvaga säkerheten för att anpassa sig till en oförklarad konfigurationsavvikelse.

Vanliga frågor

Varför kan Windows se min SMB-server men inte Finder?

Windows och macOS kan använda olika upptäcktsmetoder. Prova den exakta server-IP:n och delningsvägen med smb://192.168.x.x/share. Om det fungerar är problemet värdnamnsupplösning eller upptäckt snarare än SMB i sig.

Varför fortsätter min Mac att avvisa ett lösenord som fungerar på Windows?

Macen kan återanvända ett gammalt lösenord från Nyckelring eller skicka sitt lokala macOS-användarnamn istället för serverkontot. Ta bort den sparade SMB-autentiseringen och anslut igen med kontot som definierats på filservern.

Ska jag inaktivera SMB-signering på macOS?

Inte som en första åtgärd. Att inaktivera signering minskar meddelandeintegritetsskyddet och kan dölja en föråldrad eller inkonsekvent serverkonfiguration. Verifiera SMB2/3-stöd, autentiseringsuppgifter, behörigheter och serverns signeringspolicy först.

Varför kan Macen montera delningen men inte skapa eller redigera filer?

Anslutningen och autentiseringen lyckades, men användaren kan sakna skrivbehörighet i SMB-delningskonfigurationen eller i de underliggande NTFS/POSIX-filsystembehörigheterna.

Varför är Finder långsamt när Windows Utforskaren är snabb?

Finder begär ytterligare metadata och kan spendera mer tid på att lista stora kataloger. Testa en direkt överföring av stora filer och jämför Finder med Terminal innan du ändrar säkerhetsinställningar.