Ten wątek opisuje dwa odrębne problemy z Sambą, których nie należy traktować jako jednego błędu. Po pierwsze, w ZimaOS 1.5.4 alpha 3 podczas udostępniania nowego folderu pojawiał się komunikat „Sharing management failed”. Ponowna instalacja ZimaOS i ponowne uruchomienie systemu usunęły ten problem u autora wpisu.
Następnie system Windows wyświetlił inny komunikat informujący, że zasady zabezpieczeń organizacji zablokowały nieuwierzytelniony dostęp gościa. Ten drugi problem rozwiązano po utworzeniu oddzielnego użytkownika ZimaOS zamiast łączenia się za pomocą konta administratora.
Oddziel błąd ZimaOS od błędu systemu Windows
Jeśli w ogóle nie można utworzyć udziału w ZimaOS, sprawdź usługę Samba i wygenerowaną konfigurację. Jeśli udział istnieje, ale system Windows odmawia jego otwarcia, skoncentruj się na uwierzytelnianiu i uprawnieniach udziału.
Diagnostyka udostępniona w wątku
W odpowiedzi społeczności zasugerowano sprawdzenie stanu Samby i najnowszych logów:
systemctl status smbd nmbd --no-pager
journalctl -u smbd -u nmbd --no-pager -n 200Zasugerowano również sprawdzenie poprawności konfiguracji Samby:
testparm -sMożna też sprawdzić, czy udziały są lokalnie widoczne:
smbclient -L localhost -NTe polecenia służą do diagnostyki. Same w sobie nie naprawiają uprawnień.
Użyj uwierzytelnionego konta członkowskiego
Aktualna strona konfiguracji członków Samby w ZimaOS opisuje konta członkowskie, uprawnienia poszczególnych użytkowników oraz dostęp z systemu Windows przy użyciu nazwy użytkownika i hasła. Odpowiada to pomyślnemu rozwiązaniu przedstawionemu w wątku: autor wpisu utworzył nowego użytkownika, po czym dostęp z systemu Windows zaczął działać.
W przypadku chronionego udziału połącz się z systemu Windows za pomocą ścieżki udziału oraz danych uwierzytelniających członka przypisanego w ZimaOS, zamiast polegać na anonimowym dostępie gościa.
Kontekst wersji
Początkowe zgłoszenie „Sharing management failed” dotyczyło wersji alpha. Nie zakładaj, że w aktualnej stabilnej wersji ZimaOS konieczne jest wykonanie tej samej czynności, czyli ponownej instalacji. Najważniejszy wniosek jest taki, aby odróżniać błąd tworzenia udziału od błędu zasad uwierzytelniania systemu Windows.
Aktualny kontekst uwierzytelniania SMB
Aktualny materiał ZimaOS SMB w CachyOS pokazuje tę samą zasadę z perspektywy klienta Linux: przed obwinianiem wykrywania serwera należy sprawdzić dane uwierzytelniające członka. Materiał Podstawy udostępniania plików NAS wyjaśnia działanie aktualnych uprawnień członków ZimaOS w systemach Windows, macOS i Linux oraz na urządzeniach mobilnych, natomiast materiał Zmiany w ZimaOS 1.5 przedstawia przydatny kontekst wersji dotyczący interfejsu pamięci masowej i udostępniania.
Dokumentacja firmy Microsoft dotycząca zasad dostępu gościa SMB w systemie Microsoft wyjaśnia, że obecne wersje systemu Windows ograniczają niezabezpieczone uwierzytelnianie gościa SMB, ponieważ sesje gościa nie mają standardowych mechanizmów ochrony uwierzytelniania. Oficjalna dokumentacja Samba smbclient zapewnia bezpośredni sposób wyświetlania i testowania udziałów SMB po stronie klienta przy użyciu jawnie podanych danych uwierzytelniających. Jest to przydatne do odróżnienia problemu z zasadami Eksploratora Windows od problemu z serwerem Samba.
Podsumowanie
W tym przypadku ponowna instalacja usunęła problem z zarządzaniem udziałami w wersji alpha, ale błąd systemu Windows miał inną przyczynę. Utworzenie i używanie dedykowanego konta członkowskiego ZimaOS rozwiązało blokadę dostępu gościa. Aktualne zalecenia dotyczące Samby w ZimaOS również preferują jawnie określone dane uwierzytelniające i uprawnienia członków.
