Nowy użytkownik ZimaOS mógł kopiować pliki do udziału Samba z Eksploratora plików systemu Windows tylko po dodaniu niezabezpieczonego konta gościa. Po usunięciu dostępu gościa system Windows uznawał udziały za niedostępne i nie wyświetlał nowego monitu o nazwę użytkownika i hasło.
Problem rozwiązano bez pozostawiania włączonego dostępu gościa. Członek zespołu Zima, Giorgio, poprosił użytkownika o usunięcie wszystkich danych logowania zapisanych przez system Windows i ponowne uruchomienie społecznościowego skryptu połączenia z Sambą. Autor potwierdził, że wyczyściło to konflikt i przywróciło dostęp.
Początkowa konfiguracja ZimaOS i systemu Windows
Użytkownik zainstalował ZimaOS 1.4.1 na systemie ASUS Prime N100I-D D4. Dysk SSD Crucial M.2 o pojemności 500 GB zawierał system operacyjny, a pojedynczy dysk twardy Seagate o pojemności 1 TB został udostępniony jako dysk sieciowy za pośrednictwem interfejsu internetowego ZimaOS.
Przy włączonym użytkowniku gościa wklejenie adresu URL udziału z sekcji Zarządzaj udziałem do Eksploratora plików systemu Windows działało. Niejasne było to, że w tym stanie osiągalny wydawał się również inny udział chroniony hasłem, mimo że nie wymieniono dla niego użytkownika gościa.
Dlaczego pierwsze próby użycia danych logowania nie pomogły
Autor podejrzewał problem z danymi logowania i ręcznie dodał wpis w Menedżerze poświadczeń systemu Windows. Postępował również zgodnie ze stroną pomocy ZimaOS dotyczącą SMB oraz społecznościowym samouczkiem połączenia z użyciem wiersza poleceń. Skrypt poprosił o dane logowania, ale wpisanie oczekiwanej nazwy użytkownika i hasła ZimaOS początkowo nadal nie otwierało udziału.
Potencjalnie istotnym szczegółem było to, że pod tym samym serwerem i adresem IP wcześniej działał TrueNAS. Wątek nie dowiódł, że poprzednia instalacja spowodowała konflikt, ale w chwili diagnozy system Windows miał zapisanych wiele danych logowania do sieci Web i systemu Windows.
Potwierdzone rozwiązanie: najpierw usuń wszystkie zapisane dane logowania
Giorgio zalecił usunięcie wszystkich zapisanych danych logowania z Panelu sterowania systemu Windows, w razie potrzeby ponowne utworzenie udziału, a następnie ponowne wykonanie samouczka połączenia z Sambą ZimaOS z użyciem wiersza poleceń. Autor usunął zarówno dane logowania do sieci Web, jak i dane logowania systemu Windows, ponownie uruchomił plik wsadowy z tego samouczka i potwierdził, że dostęp do chronionego udziału w końcu zadziałał.
Wynik ma znaczenie, ponieważ w tym przypadku włączenie dostępu gościa było tylko obejściem problemu. Skuteczne rozwiązanie polegało na usunięciu przez system Windows konfliktowych danych logowania przed ponownym uwierzytelnieniem.
Jak wyglądały ekrany klienta Zima
Inny członek społeczności udostępnił oczekiwane ekrany klienta Zima i systemu Windows 11 z działającej konfiguracji dysku sieciowego. Te zrzuty ekranu nie przedstawiały rozwiązania konfliktu danych logowania autora, ale pomogły odróżnić klienta do pobrania od osobnego samouczka dotyczącego wiersza poleceń.
FAQ
Czy ten użytkownik musiał pozostawić włączony dostęp gościa?
Nie. Dostęp gościa tymczasowo umożliwił dostęp do udziałów, ale potwierdzone rozwiązanie polegało na usunięciu wszystkich zapisanych danych logowania systemu Windows i ponownym połączeniu przy użyciu chronionego konta.
Czy ręczne dodanie jednych danych logowania rozwiązało problem?
Nie. Autor wcześniej próbował ręcznie dodać dane logowania. Skuteczna próba była możliwa dopiero po usunięciu wszystkich zapisanych danych logowania do sieci Web i systemu Windows, a następnie ponownym uruchomieniu skryptu połączenia.
