Dlaczego udostępnianie plików SMB działa w systemie Windows, ale nie działa na macOS?

Gdy udostępnianie plików SMB działa w Windows, ale nie działa na macOS, serwer prawdopodobnie nie jest całkowicie offline. Windows już pokazał, że udział istnieje i że przynajmniej jeden klient może się z nim połączyć. Różnica najprawdopodobniej dotyczy używanego adresu, zapisanych poświadczeń, tożsamości konta, negocjacji SMB, wymagań podpisywania, uprawnień udziału lub sposobu, w jaki Finder obsługuje foldery sieciowe.

Najbezpieczniejszą metodą rozwiązywania problemów jest sprawdzenie tego samego celu na obu komputerach. Zacznij od dokładnego adresu IP serwera i nazwy udziału, a następnie przejdź przez rozwiązywanie nazw hostów, uwierzytelnianie, negocjację zabezpieczeń, uprawnienia, kompatybilność Samby i wydajność Findera. Nie zaczynaj od włączania starszego SMB ani wyłączania podpisywania na Macu.

Najpierw potwierdź, że Windows i macOS otwierają ten sam udział

Windows może już mieć zmapowany dysk, taki jak \\192.168.1.50\Documents, podczas gdy użytkownik Maca klika ikonę serwera w Finderze lub próbuje tylko smb://nazwa-serwera. Te testy mogą wskazywać różne adresy, konta lub ścieżki udziałów.

Na komputerze z Windows zapisz działający adres serwera, nazwę udziału, nazwę użytkownika oraz czy połączenie używa adresu IP czy nazwy hosta. Następnie naciśnij Command + K w Finderze i wpisz równoważną ścieżkę, na przykład smb://192.168.1.50/Documents.

Jeśli Mac może otworzyć dokładną ścieżkę IP i udziału, usługa SMB i udział są zasadniczo dostępne. Pozostały problem to najprawdopodobniej wykrywanie, DNS, zapisane poświadczenia lub oryginalny format ścieżki.

Użyj adresu IP serwera przed poleganiem na wykrywaniu przez Findera

Windows i macOS nie zawsze wykrywają urządzenia sieciowe w ten sam sposób. Serwer może pojawić się automatycznie w Eksploratorze plików Windows, podczas gdy w widoku Sieć Findera pozostaje niewidoczny.

To niekoniecznie oznacza, że macOS nie może korzystać z SMB. Automatyczne wykrywanie zależy od DNS, mDNS, zachowania zgodnego z NetBIOS, rozwiązywania nazw routera oraz ogłoszeń wysyłanych przez serwer plików. Bezpośredni dostęp przez smb://IP/share pomija większość tej warstwy wykrywania.

Jeśli IP działa, pozostaw konfigurację SMB bez zmian i zamiast tego zbadaj nazwę. Sprawdź, czy nazwa hosta rozwiązuje się do poprawnego adresu, czy serwer reklamuje się przez mDNS oraz czy Mac ma w pamięci podręcznej stary adres.

Wyczyść zapisane poświadczenia przed zresetowaniem hasła serwera

macOS może ponownie używać poświadczeń SMB przechowywanych w Pęku kluczy. Staje się to mylące, gdy hasło się zmienia, ten sam serwer jest dostępny zarówno przez IP, jak i nazwę hosta, lub gdy użytkownik wcześniej wybrał dostęp gościa.

Odłącz zamontowany udział, otwórz Dostęp do pęku kluczy i wyszukaj nazwę hosta serwera, adres IP oraz nazwę udziału. Usuń nieaktualne wpisy, następnie połącz się ponownie i wprowadź konto, które faktycznie istnieje na serwerze SMB.

Kroki rozwiązywania problemów Apple zaczynają się od weryfikacji poprawnej nazwy użytkownika, hasła, nazwy hosta i dostępu do udziału. Chociaż ta strona dotyczy środowisk SMB hostowanych na macOS, ta sama separacja jest tutaj przydatna: pomyślna autoryzacja i uprawnienia do korzystania z konkretnego udziału to różne kontrole.

Upewnij się, że Mac wysyła poprawną tożsamość konta

Komputer z Windows może automatycznie łączyć się za pomocą zalogowanego konta. Na macOS okno logowania może domyślnie używać nazwy użytkownika Maca, która może nie istnieć na serwerze Windows, NAS lub Samba.

Serwer może oczekiwać lokalnego konta serwera, użytkownika Samby, konta Microsoft, tożsamości Active Directory lub konta kwalifikowanego nazwą maszyny, grupy roboczej lub domeny. W zależności od środowiska, prawidłowe formaty mogą obejmować nazwa użytkownika, SERVER\usernamelub DOMAIN\username.

Nie używaj PIN-u Windows Hello jako hasła SMB. PIN zwykle odblokowuje urządzenie Windows lokalnie; serwer plików nadal wymaga hasła konta lub innej obsługiwanej metody uwierzytelniania.

Sprawdź, czy port 445 jest dostępny z Maca

Jeśli dokładna ścieżka SMB nie działa przed pojawieniem się monitu logowania, sprawdź, czy Mac może połączyć się z serwerem na porcie TCP 445. Windows może używać innego interfejsu sieciowego, VLAN, profilu zapory lub zapisanej trasy.

Na macOS prosty test taki jak nc -vz 192.168.1.50 445 może pokazać, czy port akceptuje połączenie. Przekroczenie limitu czasu wskazuje na problemy z trasowaniem, izolacją VLAN, regułami zapory lub serwerem, który nie nasłuchuje na oczekiwanym interfejsie.

Jeśli port 445 jest dostępny, ale uwierzytelnianie nie powiodło się, fizyczna ścieżka sieciowa nie jest już głównym podejrzanym. Przejdź do poświadczeń, dialektów SMB, podpisywania i uprawnień do udostępniania.

Negocjacja dialektu SMB może różnić się między dwoma klientami

Starsze routery, starsze urządzenia NAS i przestarzałe instalacje Samba mogą oferować kombinacje protokołów, które akceptuje jeden komputer z Windows, ale które aktualny Mac nie negocjuje pomyślnie.

Długoterminowym rozwiązaniem jest skonfigurowanie serwera dla SMB2 i SMB3 zamiast polegania na SMB1 lub zbiorze wyjątków kompatybilności po stronie klienta. Nowoczesna konfiguracja Samba może wyraźnie używać SMB2 jako minimalnego i SMB3 jako maksymalnego protokołu, co daje Windows i macOS jaśniejszy zakres negocjacji.

Nie zakładaj, że zgodność z Windows dowodzi, że konfiguracja serwera jest nowoczesna. SMB1 lub starsze uwierzytelnianie mogły zostać ręcznie włączone na tym komputerze z Windows, podczas gdy Mac używa innej podstawy bezpieczeństwa.

Wymagania dotyczące podpisywania i uwierzytelniania muszą się zgadzać

Podpisywanie SMB weryfikuje, że wiadomości nie zostały zmodyfikowane w trakcie przesyłania. Połączenie może nie powieść się, gdy klient i serwer nie zgadzają się co do możliwości bezpieczeństwa SMB, uwierzytelniania, podpisywania lub zachowania walidacji-negocjacji.

Apple zauważa, że SMB 3 jest domyślną metodą połączenia na macOS, że uwierzytelnione sesje SMB 3 używają podpisywania oraz że niektóre środowiska powiązane z katalogiem mogą zawieść podczas sprawdzania walidacji-negocjacji i podpisywania sesji SMB 3. To specyficzny przypadek Open Directory, ale ilustruje, dlaczego ogólny komunikat „połączenie nie powiodło się” może pochodzić z negocjacji bezpieczeństwa, a nie z podstawowej sieci.

Nie ustawiaj signing_required=no lub validate_neg_off=yes jako pierwsza odpowiedź. Wyłączenie walidacji lub podpisywania może zmniejszyć ochronę przed przechwyceniem. Najpierw potwierdź, że serwer obsługuje aktualną wersję SMB i ma spójną politykę podpisywania.

Dostęp gościa może nie być tym, czego Windows faktycznie używa

Udostępnianie Windows może otworzyć się bez wyświetlania monitu o hasło, co prowadzi użytkownika do założenia, że jest to udostępnianie gościa. Windows może faktycznie ponownie używać zapisanych poświadczeń z Menedżera poświadczeń lub konta zalogowanego użytkownika.

Na kliencie Windows sprawdź aktywną sesję SMB lub rozłącz mapowany udział i połącz go ponownie jawnie. Następnie użyj tego samego konta po stronie serwera na Macu.

Jeśli udział jest celowo anonimowy, potwierdź, że serwer zezwala na dostęp gościa i mapuje użytkowników gościa na konto z odpowiednimi uprawnieniami systemu plików. Unikaj włączania szerokiego dostępu gościa tylko po to, by obejść nierozwiązany problem z poświadczeniami.

Uprawnienia udziału i uprawnienia systemu plików są oddzielne

Mac może się uwierzytelnić pomyślnie, ale nadal widzieć pusty udział, otrzymać „odmowę dostępu” lub zamontować folder jako tylko do odczytu. W takim przypadku połączenie SMB działało; autoryzacja plików nie.

Większość serwerów plików ocenia co najmniej dwie warstwy. Konfiguracja udziału decyduje, którzy użytkownicy mogą wejść na udział, podczas gdy uprawnienia NTFS, własność POSIX lub ACL systemu plików decydują, co ci użytkownicy mogą czytać, tworzyć, modyfikować i usuwać.

Testuj Windows i macOS z tym samym kontem serwera. Jeśli jeden klient używa innego użytkownika lub grupy, ich wyniki nie są bezpośrednio porównywalne. Sprawdź także, czy Mac przypadkowo nie połączył się jako gość, podczas gdy Windows używał konta uwierzytelnionego.

Samba może wymagać lepszego wsparcia metadanych macOS

Jeśli serwer używa Samby, podstawowa kompatybilność z Windows nie gwarantuje idealnego działania na macOS. Finder i aplikacje Mac używają rozszerzonych atrybutów, metadanych Findera, alternatywnych strumieni danych i widłów zasobów, których klienci Windows mogą nigdy nie żądać.

Konfiguracja Samby przeznaczona do mieszanej pracy z Windows i macOS może umożliwiać metadane macOS przez fruit i streams_xattr. Typowa konfiguracja może zawierać vfs objects = catia fruit streams_xattr, aby metadane specyficzne dla Apple mogły być reprezentowane bez zakłócania normalnego dostępu Windows.

Te moduły są najbardziej istotne, gdy udział jest zamontowany, ale nazwy plików, rozszerzone atrybuty, widły zasobów, zachowanie Time Machine lub metadane Findera są niespójne. Nie zastępują one naprawy niepoprawnego hasła lub niedostępnego serwera.

Problemy z wydajnością Findera mogą wyglądać jak awarie połączenia

Czasami udział jest połączony, ale Finder pokazuje pusty katalog, kręci się przez kilka sekund lub przestaje odpowiadać podczas otwierania dużego folderu. Użytkownik odbiera to jako „SMB jest uszkodzony”, mimo że montowanie się powiodło.

Finder może żądać metadanych plików, uprawnień, podglądów, informacji o zasobach i aktualizacji katalogów. Operacje te wpływają na Maca inaczej niż podstawowa lista katalogów Windows, zwłaszcza w dużych folderach lub na serwerach bez obsługi metadanych zorientowanych na Apple.

Przetestuj ten sam zamontowany udział w Terminalu za pomocą poleceń takich jak lslub skopiuj jeden duży plik bez wcześniejszego przeglądania dużego katalogu. Jeśli dostęp przez Terminal działa, a Finder pozostaje wolny, rozwiązywanie problemów skup się na metadanych i enumeracji katalogów, a nie na uwierzytelnianiu.

Wolny udział to nie to samo co nieudany udział.

Nie łącz awarii uwierzytelniania i problemów z prędkością transferu w jednej diagnozie. Mac, który nie może zamontować udziału, ma inny problem niż Mac, który montuje go poprawnie, ale zapisuje wolno.

W jednym przypadku w społeczności Unraid odczyty osiągały około 180 MB/s, podczas gdy zapisy spadały do około 2 MB/s, mimo że lokalne testy dysku i sieci były znacznie szybsze. To jest przydatne jako wzorzec objawów, ale nie dowodzi, że podpisywanie jest uniwersalną przyczyną; układ magazynu, zachowanie pamięci podręcznej, małe pliki, interfejsy klienta i ustawienia Samba mogą powodować podobną asymetrię.

Mierz osobno: przepustowość sieci, odczyt jednego dużego pliku, zapis jednego dużego pliku oraz obciążenie wieloma małymi plikami. Ustawienia wydajności SMB dostosowuj dopiero po zidentyfikowaniu, który test jest faktycznie wolny.

Samba oparta na Dockerze powoduje problemy z mapowaniem użytkowników i woluminów.

Kontener Samba może akceptować połączenia z Windows, odrzucając jednocześnie macOS, ponieważ oba klienty nie przedstawiają tej samej tożsamości. Kontener może również poprawnie publikować port 445, podczas gdy zamontowany wolumin ma niezgodne własności lub ACL.

Sprawdź konto Samba wewnątrz kontenera, UID i GID hosta używane do zamontowanego magazynu, uprawnienia do odczytu/zapisu woluminu, opublikowany port oraz efektywne ustawienia. smb.confPrzejrzyj logi kontenera, gdy Mac próbuje się połączyć.

Jeśli żądanie dociera do kontenera i uwierzytelnianie się powiodło, przestań zmieniać sieć Dockera. Skoncentruj się na mapowaniu użytkowników, konfiguracji udziałów, własności systemu plików i wsparciu metadanych Apple.

Traktuj poprawki SMB po stronie klienta jako ostatnią warstwę

Naprawy online często oferują długie /etc/nsmb.conf plik, który wyłącza podpisywanie, zmienia buforowanie katalogów, wymusza protokół lub modyfikuje zachowanie multikanału. Skopiowanie wszystkich tych ustawień naraz uniemożliwia określenie, która zmiana miała znaczenie.

Zmiany testowane przez społeczność dotyczące buforowania katalogów i zachowania przewodowego multikanału mogą pomóc w specyficznych kombinacjach macOS, sieci i Unraid. Ta sama dyskusja obejmuje również opcje obniżające bezpieczeństwo i sprzeczne wyniki, więc należy ją traktować jako eksperymentalne rozwiązywanie problemów, a nie uniwersalną konfigurację.

Przed edycją nsmb.conf, zapisz aktualny stan i zmieniaj jeden parametr na raz. Po każdej zmianie ponownie testuj ten sam folder i transfer plików. Unikaj wyłączania podpisywania tylko dla szybkości, chyba że rozumiesz kompromis bezpieczeństwa i udział jest ograniczony do zaufanej sieci.

Postępuj według warstwowego porządku rozwiązywania problemów

Najskuteczniejszy proces zaczyna się od dokładnego celu i przechodzi do coraz bardziej specyficznego zachowania klienta. Nie edytuj jednocześnie ustawień Samba, pęku kluczy, DNS, podpisywania i Findera.

Zacznij od działającej ścieżki Windows, przetestuj smb://IP/share na macOS i potwierdź port 445. Następnie wyczyść zapisane poświadczenia, zweryfikuj tożsamość konta i sprawdź obsługę SMB2/3. Potem zbadaj podpisywanie, uprawnienia udziałów, ACL systemu plików, rozszerzenia Samba Apple oraz wydajność Findera.

Ta sekwencja zachowuje dowody z każdego testu. Wynik IP kontra nazwa hosta identyfikuje problemy z wykrywaniem; monit logowania wskazuje na dostępność usługi SMB; zamontowany, ale tylko do odczytu udział wskazuje na uprawnienia; a działająca sesja Terminala z wolnym oknem Findera wskazuje na zachowanie przeglądania po stronie klienta.

Ostateczne wnioski

Gdy SMB działa na Windows, ale nie na macOS, użyj połączenia Windows jako odniesienia, a nie dowodu, że wszystkie ustawienia serwera są poprawne. Oba klienty mogą używać różnych adresów, nazw użytkowników, zapisanych poświadczeń, możliwości protokołu lub uprawnień.

Zacznij od dokładnego smb://IP/share ścieżka. Jeśli IP działa, ale nazwa hosta nie, rozwiąż problemy z wykrywaniem. Jeśli logowanie się nie powiodło, wyczyść poświadczenia Pęku kluczy i zweryfikuj konto serwera. Jeśli uwierzytelnianie działa, ale dostęp do plików nie, sprawdź uprawnienia udziału i ACL systemu plików. Jeśli udział jest zamontowany, ale Finder działa wolno, przejdź do metadanych, rozszerzeń Samba Apple i testów wydajności.

Opcje po stronie klienta wyłączające podpisywanie lub sprawdzanie negocjacji powinny pozostać ostatecznością. Aktualny serwer SMB2/3, jasne mapowanie kont, poprawne uprawnienia i świadome wsparcie metadanych macOS zapewniają bardziej niezawodne rozwiązanie niż osłabianie bezpieczeństwa, by dostosować się do niewyjaśnionej niezgodności konfiguracji.

FAQ

Dlaczego Windows widzi mój serwer SMB, a Finder nie?

Windows i macOS mogą używać różnych metod wykrywania. Spróbuj użyć dokładnego adresu IP serwera i ścieżki udziału z smb://192.168.x.x/shareJeśli to działa, problem dotyczy rozpoznawania nazwy hosta lub wykrywania, a nie samego SMB.

Dlaczego mój Mac ciągle odrzuca hasło, które działa na Windows?

Mac może ponownie używać starego hasła z Pęku kluczy lub wysyłać lokalną nazwę użytkownika macOS zamiast konta serwera. Usuń zapisane poświadczenia SMB i połącz się ponownie z kontem zdefiniowanym na serwerze plików.

Czy powinienem wyłączyć podpisywanie SMB na macOS?

Nie jako pierwsza naprawa. Wyłączenie podpisywania zmniejsza ochronę integralności wiadomości i może ukryć przestarzałą lub niespójną konfigurację serwera. Najpierw zweryfikuj obsługę SMB2/3, poświadczenia, uprawnienia i politykę podpisywania serwera.

Dlaczego Mac może zamontować udział, ale nie może tworzyć ani edytować plików?

Połączenie i uwierzytelnienie powiodły się, ale użytkownik może nie mieć uprawnień do zapisu w konfiguracji udziału SMB lub w uprawnieniach systemu plików NTFS/POSIX.

Dlaczego Finder jest wolny, gdy Eksplorator plików Windows działa szybko?

Finder żąda dodatkowych metadanych i może spędzać więcej czasu na przeglądaniu dużych katalogów. Przetestuj bezpośredni transfer dużego pliku i porównaj Finder z Terminalem przed zmianą ustawień bezpieczeństwa.