Host CIFS nie działa

97

Mam problem z uprzednio skonfigurowanym punktem instalacji. Pokazuje folder, ale brak montowania i zawiera „?” wartości wielkości, uprawnień itp.

Więc próbowałem ponownie zamontować cifs i tę samą komendę wcześniej:

mount -t cifs //nas.domain.local/share /mnt/archive

Ale dostaję błąd:

Host is down.

Jeśli pinguję domenę lub adres IP, uzyskuję odpowiednią rozdzielczość i bez problemu nawiązałem połączenie za pomocą programu smbclient

 ping nas.domain.local
 ping ip
 smbclient //nas.domain.local/share

Rozejrzałem się, ale nie mogę znaleźć solidnej odpowiedzi. jakieś pomysły?

Kevin
źródło
czy nslookup nas.domain.local czy to równa się ipowi pingowi?
Tony Roth,
Tak, zwracany adres IP jest dokładny. Mogę uzyskać dostęp do interfejsu sieciowego serwera NAS przy użyciu adresu IP i domeny. Mogę uzyskać dostęp do danych na moim laptopie za pomocą domeny lub adresu IP, więc wydaje się, że tutaj jest jakiś inny problem
Kevin
6
Dodaj --verboseprzełącznik do polecenia mount, publikuj wszelkie błędy / wyniki, które wydają się istotne.
Zoredache,
Czy usługa działa nawet na zdalnym serwerze? To jest Linux lub Windows Server? Jeśli jest to Linux ... sprawdź, czy usługa jest uruchomiona. Upewnij się, że w zaporze nie wprowadzono żadnych zmian ... Jeśli jest to system Windows ... możesz rozważyć ponowne uruchomienie ...
Jay
1
@Zoredache Dodaj, -vvvaby uzyskać jeszcze więcej pełnych informacji!
Serge Stroobandt,

Odpowiedzi:

108

Może to być również spowodowane niedopasowaniem protokołu. W 2017 roku Microsoft załatał serwery Windows i zalecił wyłączenie protokołu SMB1.

Odtąd mount.cifs może mieć problemy z negocjowaniem protokołu.

Wyświetlany błąd to „Host nie działa”, ale podczas debugowania za pomocą:

smbclient -L <server_ip> -U <username> -d 256

dostaniesz błąd:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Aby temu zaradzić, użyj mount lub smbclient z określonym protokołem.

dla smbclient: dodaj -m SMB2 (lub SMB3 dla nowszej wersji protokołu)

smbclient -L <server_ip> -U <username> -m SMB2

lub dla mount: dodaj vers = 2.0 (lub vers = 3.0, jeśli chcesz użyć wersji 3 protokołu)

mount -t cifs //<server_ip>/<share> /mnt/<mountpoint> -o vers=2.0
Marcin P.
źródło
Moja NAS jest na Linuksie, gdy próbuję rozwiązanie smbclient -L 192.168.1.47 -U admin -d 256wszystko działa perfekcyjnie, ale gdy próbuję mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiersto powtarzamount error(112): Host is down
Olivier Pons
3
Czy próbowałeś podać protokół, jak wyjaśniam w tej odpowiedzi? Spróbuj dodać vers = 2.0 lub vers = 3.0 lub vers = 1.0 (w zależności od tego ustawienia NAS), dodając: mount -t cifs -o nazwa użytkownika = aa, hasło = bb, uid = olivier, vers = 2.0 //192.168.1.47/ partagefichiers / / mnt / PartageFichiers
Marcin P
11
Dziwne. Strona vers=1.0podręcznika mówi, że jest to ustawienie domyślne, ale nie mogłem zmontować dysku sieciowego przed jawnym przekazaniem vers=1.0.
Hubro,
Czy można to zmienić po stronie systemu Windows? Mam oprogramowanie, które przekazuje tę opcję do cifs i nie zna opcji versa, więc nie jest przesyłana dalej.
Andrew Savinykh
1
W pliku fstab będzie tak//<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0
PRIHLOP
43

Na archlinuxie po ostatniej aktualizacji pakietu musiałem dodać vers = 1.0 do moich opcji montowania. Łączę się ze starym urządzeniem Centos 5 i do wczoraj mogłem się połączyć bez wyraźnego podania numeru wersji.

CIFS w jądrze Linuksa 4.13 domyślnie ma teraz SMB 3.0, aw jądrze 4.14 próbuje wersji 2.1 i nowszej. Zobacz ten dziennik zmian .

Sjoerd Timmer
źródło
Dzięki, miałem ten sam problem, jednak nie wiem, która aktualizacja tego wymaga.
Ben
To naprawdę dziwny problem. To samo stało mi się dzisiaj. Próbowałem obniżyć wersję smbclient i libwbclient, ale problem nadal występował. Może coś na serwerze się zmieniło. Myślę, że to też CentOS, mam nadzieję, że nie CentOS 5! Dzięki za obejście :)
jPlatte
2
Musiałem to zrobić dla mojego systemu Fedora 26 uzyskującego dostęp do montowania na moim serwerze Synology NAS DS413j, mój plik / etc / fstab ma teraz „, vers = 1.0” na końcu łańcucha opcji i nie ma już komunikatu o błędzie „Host nie działa”.
Neek
1
Miałem aktualizację z Ubuntu 16.04 do 18.04 (LTS), co złamało moje wierzchowce Lacie NAS. To załatwiło sprawę.
YoungFrog
14

Pamięć USB na Fritz NAS pokazała „Host Down” dla Ubuntu 17.10:

Zdefiniowanie wersji ( vers=1.0) działało - oto pełny ciąg:

sudo mount -t cifs -o vers=1.0,_netdev,username=<user>,password=<pwd>,uid=1000,gid=1000  //192.168.178.1/fritz.nas <local mountpoint>
użytkownik449376
źródło
3
Wszystko działało od wewnątrz /etc/fstabcifs mount; po apt upgrademoim Ubuntu 16.04 tak się stało. Określenie załatwiło -o vers=1.0sprawę. Dziękuję
odpowiednik8
7

Podobny problem po aktualizacji do Ubuntu 17.10, ze starą Buffalo Diskstation. Rozwiązany przez dodanie w / etc / fstab opcji „vers = 1.0”:

// myWDhostname / partage / media / Partage cifs guest, vers = 1.0 0 0

Patrice
źródło
Każdy, kto używa Ubuntu 18.04, dodanie ,vers=1.0opcji rozwiązuje problem podczas korzystania z samouczka dostarczonego przez Ji m na ubuntuhandbook.org/index.php/2014/08/…
Geppettvs D'Constanzo
Mam ten sam problem i mogę go rozwiązać, używając wersji 1 w protokole. Ale mam bardzo niski wskaźnik transmisji danych. Podejrzewam, że może to być spowodowane wersją 1, więc użycie innej wersji byłoby lepsze.
Ben
5

Przepraszam, jeśli to spóźniona odpowiedź (zdaję sobie sprawę, że to stary wątek), ale właśnie odkryłem, że istnieje inny możliwy powód, dla którego mount.cifs powiedziałby, że host nie działa.

Mam program antywirusowy z zaporą ogniową i mimo że ustawiłem go wyraźnie, aby zezwolić na „udostępnianie plików i drukarek w systemie Windows” - to z góry określona reguła - nadal blokował połączenia. Udowodniłem to, tymczasowo wyłączając zaporę. Mam nadzieję, że to pomaga komuś, host nie działa, może nie oznaczać, że nie reaguje na pingi, ale może oznaczać, że nie odpowiada na próby uwierzytelnienia.

lolinux
źródło
Pamiętaj, aby sprawdzić zaporę po obu stronach: klienta i serwera (a także zaporę, która może być między nimi). W moim przypadku zapora klienta blokowała połączenia z serwerem. Musiałem dodać iptablesreguły, aby na to pozwolić: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPTi iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPTgdzie 1.2.3.4był adres IP serwera.
Antonio Vinicius Menezes Medei
Mój NAS jest na Linuksie, więc nadal mam ten problem, ale dziękuję za udostępnienie
Olivier Pons
4

Otrzymałem ten sam błąd bez zbędnych ceregieli od nowego klienta Samby, gdy próbowałem zamontować udział sieciowy CIFS SMB:

mount error(112): Host is down

W końcu okazało się, że wcześniej ograniczyłem dostęp do serwera SMB tylko do ograniczonej liczby adresów IP, konfigurując /etc/samba/smb.conf:

# Allow these IP Addresses to connect: 
hosts allow = 127.0.0.1 127.0.1.13 127.0.1.63

# Anything else not allowed is, by default, rejected
hosts deny = ALL

Dodanie stałego adresu IP nowego klienta SMB rozwiązało problem w tym konkretnym przypadku.

Oczywiście istnieje wiele innych powodów, dla których można otrzymać wyżej wspomniany błąd.

Serge Stroobandt
źródło
4

Te same problemy z połączeniem z Synology DiskStation (DSM 4.3).

Użycie vers = 1.0 w opcjach montowania działa dobrze.

Dodatkowo musiałem użyć opcji „noperm”, ponieważ wszystkie pliki błędnie pokazane jako nie do odczytu i zapisu przez właściciela.

Bernhard
źródło
2

Ten sam problem z Fritzbox 7490: błąd montowania (112): Host nie działa

Nie użyłem -o vers = XX. Jestem szybki jak rekin, najpierw spróbowałem -o vers = 2.0 i nie udało mi się.
Jak tylko użyłem opcji -o vers = 1.0 , wszystko działa dobrze!

To działa dla mnie ..

 sudo mount -t cifs -o rw,username=myname_on_the_box,pass\word=mypasswd_on_the_box,vers=1.0 //192.168.1.1/Fritz-nas /media/something/something    

Moja env:
Klient: Ubuntu 17.10 Linux 4.13.0-17-generic # 20-Ubuntu SMP x86_64 GNU / Linux
Server: Fritzbox 7490 firmware 6.83.

d.dieckert
źródło
AVM używa przestarzałej wersji Samby, którą sami utrzymują. To prawdopodobnie wyjaśnia, dlaczego należy użyć vers=1.0zamiast bardziej odpowiednich nowszych wersji protokołu.
0xC0000022L
2

Wersja protokołu SMB1 jest przestarzała, jednak jest to domyślna wersja używana w starszych wersjach mount.cifs, np. Mam ten problem z wersją 6.2.

Możesz to sprawdzić za pomocą: sudo mount.cifs --version

Jeśli spróbujesz połączyć się z serwerem SMB3 za pomocą protokołu SMB1, pojawi się Host is downbłąd.

Obejściem opisanym w wielu innych odpowiedziach tutaj jest określenie innej wersji protokołu. Następujące polecenie działa dla mnie: sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0

Jednakże , jeśli serwer, który łączysz się używa DFS, wtedy pojawia się następujący błąd zamiast: mount error(38): Function not implemented. Jest tak, ponieważ obsługa DFS na SMB3 została dodana do jądra tylko w wersji 4.11 .

Możesz sprawdzić swoją wersję jądra za pomocą uname -a. W moim przypadku było to 3,10 na CentOS7. Postępowałem zgodnie z tymi instrukcjami, aby zaktualizować i teraz działa.

Dr John A Stevenson
źródło
0

Zazwyczaj używam tego typu polecenia do montowania udziału cifs / smb.

mount -t cifs -o rw,netbiosname=nasserver1,credentials=/etc/user_credentials.txt //192.168.1.11/someshare /mnt

plik poświadczeń wygląda następująco:

username=mydomain\user1
password=somepass

Można to również dostosować do konfiguracji automatycznego montowania, aby montaż / demontaż mógł być obsługiwany przez system automatycznie za pomocą autofs.

slm
źródło
0

W naszym przypadku sprawdziłem nazwę użytkownika (user2) w AD. Zauważyłem tam, że nazwa zaczyna się od dużej litery i zmieniłem ją na małą, ponieważ jest zapisana w skrypcie montowania. Nawet jeśli wcześniej nie dotknęliśmy ani user2, ani skryptu montowania, nagle polecenie montowania zakończyło się powodzeniem.

mount --verbose -t cifs //pc/share /my-share -no user=user1,password=pw1 -o uid=user2,gid=group1,dir_mode=0775,file_mode=0664
Ludwig
źródło
0

Dla mnie zamontowany udział cifs znajdował się na serwerze Windows, którego adres IP ostatnio się zmienił, więc mogłem pingować serwer i rozpoznać nowy adres, ale sam mount nie zaktualizował się. Przez uruchomienie leniwego odmontowania, a następnie ponowne zamontowanie, mój problem został rozwiązany:

umount -l /mnt/share
mount -a
Jon.Mozley
źródło
0

Właśnie natrafiłem na problem wspomniany po aktualizacji do Xubuntu 17.10. Używam Synology DiskStation. Co tam zobaczyłem: na DiskStation możesz wybrać, które protokoły będą obsługiwane. Dodając odpowiednie protokoły (do SBM3) w zaawansowanych opcjach usług plików w panelu sterowania, możesz również rozwiązać problem.

Matthias Mielke
źródło
0

Jeśli masz ten problem z serwerem Synology NAS, sprawdź, czy vers=opcje określone dla mountwersji SMB min / max na serwerze NAS są zgodne.

W szczególności używam vers=2.0, ale moja stacja Synology Diskstation spowodowała Host is downbłąd. Znalazłem stronę dostępu systemu Windows 10 do udziału NAS. SMB 1.0 i 3.0 , na stronie Synology, która wyjaśniła, jak ustawić Diskstation, aby zezwalał na SMB v2.0 lub nowszy ...

Na serwerze Synology NAS

  • Przejdź do Panelu sterowania -> Usługi plików
  • Na karcie SMB / AFP / NFS wybierz Ustawienia zaawansowane
  • Zmień protokół Maximum SMB na SMB3
  • Zmień protokół Minumum SMB na SMB2 (strona mówi o używaniu SMB2 z dużym MTU, ale to nie działało dla mnie)
Roger Lipscombe
źródło
-4

Miał podobny problem. Rozwiązanie było dla mnie po stronie serwera udostępniania Windows. Nawet przekazanie wartości vers = 2.0 do mojego serwera Linux, mount nie działał. Musiałem więc włączyć obsługę smbv1 na moim serwerze Windows. Ten artykuł pomógł mi: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and

Vinicius Freitas
źródło
4
Nie rób tego . smbv1 jest wektorem używanym przez WannaCry do rozprzestrzeniania się i jest stopniowo wycofywany.
Andrew Schulman,