Serwer domowy jest dostępny, ale udział plików wygasa: co powinieneś przetestować?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Home Server Is Reachable but File Shares Time Out: What Should You Test? - Zima Store Online

Dostępny serwer domowy może nadal przerywać połączenia na udziałach plików, gdy sam protokół SMB jest zablokowany, zatrzymany, błędnie powiązany, przeciążony lub utknął w nieudanej sesji.

Ping potwierdza jedynie, że serwer odpowiada na ICMP; nie dowodzi, że TCP 445 dociera do nasłuchiwacza SMB, że klient negocjuje obsługiwany protokół lub że udział może się uwierzytelnić i wyliczyć zawartość. Najszybsza diagnoza przebiega warstwami: dostępność IP, wynik nazwy hosta, port 445, stan usługi SMB, ścieżka udziału, poświadczenia i wreszcie obciążenie serwera podczas timeoutu.

Porównaj IP serwera z nazwą udziału

Przetestuj udział za pomocą aktualnego adresu IP serwera oraz jego normalnej nazwy hosta z tego samego klienta. Zanotuj, czy oba kończą się timeoutem, czy tylko nazwa nie działa, lub czy nazwa rozwiązuje się do innego adresu IPv4 lub IPv6.

Przypadek wsparcia OSMC pokazał host, który można było pingować, podczas gdy ścieżka SMB zwracała timeout połączenia. Ta różnica zapobiega przedwczesnemu wykluczeniu problemów z DNS, portem lub usługą na podstawie udanego pinga.

Jeśli IP działa, a nazwa nie, napraw DNS, wykrywanie multicast, sufiksy lub pamięć podręczną adresów. Jeśli oba zawiodą identycznie, kontynuuj testowanie TCP 445 i nasłuchiwacza SMB zamiast wielokrotnego czyszczenia pamięci podręcznej nazw.

Przetestuj port TCP 445 z klienta, który ma problem

Otwórz test połączenia TCP do adresu serwera na porcie 445 z tego samego urządzenia, które doświadcza timeoutu. Uruchom test podczas występowania problemu, a nie po restarcie NAS lub ponownym połączeniu klienta.

Diagnoza na Ask Ubuntu rozróżniła działający ping od awarii Samby, sprawdzając, czy port 445 był dostępny. SMB w nowoczesnych sieciach zależy od tej ścieżki TCP, nawet gdy inne usługi serwera pozostają dostępne.

Jeśli port 445 kończy się timeoutem, sprawdź VLAN klienta, zaporę hosta, zaporę NAS, powiązanie interfejsu i pośrednie ACL. Jeśli łączy się natychmiast, ścieżka sieciowa jest otwarta, a diagnoza powinna przejść do negocjacji SMB, sesji, poświadczeń lub stanu udziału.

Potwierdź, że usługa SMB nasłuchuje na właściwym interfejsie

Sprawdź status usługi SMB i aktywnych nasłuchiwaczy na serwerze. Upewnij się, że jest powiązana z adresem LAN lub VLAN, którego używa klient, a nie tylko z loopback, inną kartą sieciową, mostkiem kontenera lub starym adresem.

Restart całego NAS może tymczasowo ukryć zatrzymaną lub zablokowaną usługę. Lepiej sprawdzić logi usługi, wyjście nasłuchiwaczy i ostatnie zmiany konfiguracji przed restartem, aby dowody awarii pozostały dostępne.

Jeśli usługa jest zatrzymana, znajdź przyczynę jej zakończenia i zweryfikuj konfigurację udziału przed ponownym uruchomieniem. Jeśli nasłuchuje na niewłaściwym interfejsie, popraw powiązanie i przetestuj ponownie z klienta bez zmiany niepowiązanych reguł zapory.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Oddziel negocjację protokołu od uwierzytelniania

Użyj klienta SMB, który raportuje negocjowany dialekt i kod błędu. Porównaj bezpośrednią ścieżkę udziału z przeglądaniem katalogu głównego serwera, ponieważ wykrywanie, wyliczanie, uwierzytelnianie i otwieranie znanego udziału to oddzielne operacje.

Raport społeczności Synology opisał NAS, którego nazwa hosta i adres były dostępne, podczas gdy port SMB 445 zawodził na wynikach IPv4 i IPv6.

Jeśli połączenie TCP się otwiera, ale negocjacja zawodzi, porównaj wersje SMB, podpisywanie, szyfrowanie i kompatybilność klienta. Jeśli negocjacja się powiedzie, ale uwierzytelnianie zawiesza się lub zawodzi, wyczyść tylko odpowiednie zapisane poświadczenia i zweryfikuj konto, ACL udziału oraz stan blokady.

Wyczyść przestarzałe sesje bez usuwania działającej konfiguracji

Odłącz istniejące mapowane dyski i aktywne sesje SMB z klienta, który ma problem, a następnie połącz się ponownie, używając jednego wyraźnego adresu serwera i konta. Przestarzałe sesje mogą zachować stary adres, poświadczenia, dialekt lub rozłączony transport.

Sprawdź jednocześnie tabelę sesji serwera. Sesja, która pozostaje ustanowiona, podczas gdy klient doświadcza timeoutu, może wskazywać na półotwarte połączenie TCP, uśpionego klienta, zmianę ścieżki VPN lub przełączenie interfejsu, które nie zresetowało stanu SMB w czysty sposób.

Wyczyść indywidualną sesję klienta przed restartem usługi SMB dla każdego użytkownika. Jeśli timeout powraca przy nowych sesjach, kontynuuj diagnozę obciążenia serwera i zachowania sieci zamiast traktować czyszczenie sesji jako ostateczne rozwiązanie.

Odtwórz timeout, obserwując obciążenie serwera

Monitoruj CPU, obciążenie pamięci, opóźnienia dysku, stan puli, kolejki sieciowe, aktywność kontenerów, skanowanie antywirusowe, indeksowanie i pracę snapshotów podczas otwierania i wyliczania udziału. Serwer może odpowiadać na ping, podczas gdy pracownik SMB lub ścieżka magazynu czeka wystarczająco długo, by nastąpił timeout.

Przewodnik ZimaSpace po przeciążonej ścieżce usługi NAS dostarcza powiązane kontrole wydajności po pomyślnych testach portu i protokołu.

Problem jest rozwiązany tylko wtedy, gdy ten sam klient może połączyć się, uwierzytelnić, wyliczyć foldery, czytać, pisać, rozłączyć się i ponownie połączyć w trakcie okna awarii. Jeśli SMB kończy się timeoutem, podczas gdy port 445 pozostaje otwarty, a serwer jest przeciążony, napraw wąskie gardło zasobów lub magazynu zamiast wydłużać timeouty klienta.