16.04 CIFS „Host nie działa”, ale tak nie jest

27

Mam moją konfigurację CIFS w fstab i działają one tak, jak powinny podczas uruchamiania. Wspinają się tak, jak powinny i pracują przez chwilę. Wydaje się znikąd (może to być po odblokowaniu komputera itp.). Występuje błąd „Host jest wyłączony” podczas próby uzyskania dostępu. Mam wiele i wszystkie są w dół. Są one również udostępniane z tego samego serwera. W tej chwili sprawdzam na komputerze z systemem Windows i nieaktualną maszynę 14.04 i działają one tak, jak powinny. Po kliknięciu udziałów w nautilus i powtórzeniu błędów, zaczną ponownie działać. Aby uzyskać dostęp do udziału, który jest „wyłączony”, potrzeba około 2-3 minut losowego kliknięcia różnych montowań i powrotu do pierwszego, gdy w sposób automatyczny pokazuje dane w punkcie montowania.

Nie mam tego problemu na maszynach 14.04, które nie były aktualizowane od dłuższego czasu. Wszystkie te maszyny są w pełni funkcjonalne, a CIFS nigdy nie spada. 16.04 nie stanowili problemu do niedawna.

Upewniłem się, że aktualizuję co drugi dzień i wyczyściłem stare nagłówki linuksa (z perspektywy czasu prawdopodobnie powinienem był przywrócić). Robię to, ponieważ błagam o pojawienie się poprawki, ale minęły tygodnie walki z wierzchowcami CIFS bez żadnego rozwiązania.

DevinM
źródło
Mam dokładnie ten sam problem. Niedawno zaczęłam kilka tygodni temu. Trochę szczęścia?
Ian H
Nie, wciąż mam ten sam problem. Czy przypadkiem używasz gnome-shell? Zaczynam się zastanawiać, czy to był punkt zwrotny, ponieważ mam laptopa, który był w porządku, dopóki gnome-shell
DevinM
Nie, używam urxvt. Myślę, że to błąd w bezpieczniku.
Ian H
Powiązane - serverfault.com/a/842686/301458
David Refoua,

Odpowiedzi:

14

Mam ten sam problem. Wygląda na to, że ma to coś wspólnego z najnowszymi wersjami jądra i sambą.

Udało mi się to rozwiązać, dodając vers = 2.0 w poleceniach mount (lub na końcu każdej linii fstab)

josepcoves
źródło
3
Czy możesz spróbować wyjaśnić to innym? Pokaż linię z fstab lub powłoki i wyjaśnij, dlaczego to pomaga?
Zanna
Cześć, zastosowałem to obejście, wykonując następujące kroki podane na launchpad
josepcoves
Testuję teraz tę poprawkę. Jak na razie dobrze. Jeśli jutro będzie nadal działać, zaakceptuję to jako odpowiedź. Dzięki za informację!
DevinM
Nie działa dla mnie - czy możesz opublikować to, co zrobiłeś? Jak rozpoznać, którego numeru wersji użyć?
hippyjim
4
Ponieważ jest to zaakceptowana odpowiedź, należy wspomnieć, że wypróbowanie prawidłowych wartości versdałoby najlepsze wyniki, zamiast zalecania jednej konkretnej wersji protokołu (która nie będzie działać na nieaktualnych serwerach). Zacznij od wersji z wysokim protokołem i przechodź jeden po drugim. Jeśli skończysz ze vers=1.0zdalnym serwerem, może być konieczne uaktualnienie (jeśli to możliwe) lub zabezpieczenie w inny sposób.
0xC0000022L
38

Po wielu testach dodanie vers=1.0linii montowania wydaje się naprawiać problem. Montaż działa teraz na Ubuntu 17.10, podobnie jak przez lata w starszych wersjach Ubuntu.

Stéphane PIOTROWSKI
źródło
3
Po wielu próbach x 10 jest to jedyne działające rozwiązanie. vers=2.0nie działało
Olivier Pons,
Nie wiem o vers = 1.0 vs 2.0 lub 3.0 i nie mogę znaleźć żadnej wzmianki na stronach podręcznika, ale to zadziałało dla mnie.
Greg Chabala
3
//192.168.1.222/volume_1 / media / nas cifs nazwa użytkownika = ****, hasło = ****, vers = 1.0
Steven
@GregChabala: może sprawdź mount.cifs(8)np. Z man 8 mount.cifs? W mount.cifswersji 6.8 (z cifs-utilspakietu) strona podręcznika zawiera wzmiankę o vers=arg.
0xC0000022L
vers=1.0pracował w moim przypadku.
Sohel Pathan
7

Sam napotkałem ten sam problem, chciałem automatycznie zamontować za pomocą metody znalezionej na wiki Ubuntu ( https://wiki.ubuntu.com/MountWindowsSharesPermanently ), chociaż mam ten sam problem, jak podano powyżej:mount error(112): Host is down

Chodzi o to, co pomogło mi dodać vers=3.0w opcjach i:

//servername/sharename /media/windowMBsshare cifs credentials=/home/ubuntuusername/.smbcredentials,iocharset=utf8,sec=ntlm,vers=3.0 0 0

Wygląda więc na to, że działa teraz tylko wtedy, gdy obejdziesz SMB1 i użyjesz innego, SMB3 działał dla mnie, więc nie próbowałem niczego innego.

Użyłem konta lokalnego na komputerze z systemem Windows, a nie z nazwą domeny outlook.com, ponieważ przeczytałem coś, co może powodować konflikty.

użytkownik695658
źródło
wydaje się, że ostatnia aktualizacja systemu Windows 10 pro podgląd informacji poufnych kompilacja 16232.rs_prerelease.170624-1334 zawierała zmianę, która wymagała ode mnie dodania, vers=3.0aby zamontować udział, który wcześniej działał bez niego.
dylan oliver
6

Inni już wskazywali na rozwiązanie, ale warto krótko wyjaśnić przyczynę.

mount.cifs w Ubuntu 16.04 domyślnie używa protokołu SMB1.

W późniejszych wersjach mount.cifsdomyślna wersja SMB to 2.1 lub 3.0.

Obecne serwery Windows nie obsługują już protokołu SMB 1.0, chyba że zostały specjalnie skonfigurowane w rejestrze, aby go zaakceptować. Dlatego domyślnie odrzucają połączenia od klientów korzystających z protokołu SMB1. Co prowadzi do mylącego komunikatu „Host nie działa”.

Ale niektóre starsze systemy (najczęściej NAS) nie obsługują protokołów 2.1 lub 3.

Rozwiązaniem jest powiedzieć, mount.cifsaby użyć odpowiedniego protokołu do połączenia z serwerem, korzystając z vers=opcji. Na przykład, aby połączyć się z komputerem z systemem Windows 10:

mount -t cifs ... -o vers=3.0,...

lub na stary NAS z Ubuntu 18.04 lub nowszej:

mount -t cifs ... -o vers=1.0,...

Od man mount.cifs(w Ubuntu 16.04):

   vers=
       SMB protocol version. Allowed values are:

       ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

       ·   2.0 - The SMBv2.002 protocol. This was initially introduced in
           Windows Vista Service Pack 1, and Windows Server 2008. Note
           that the initial release version of Windows Vista spoke a
           slightly different dialect (2.000) that is not supported.

       ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft
           Windows 7 and Windows Server 2008R2.

       ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft
           Windows 8 and Windows Server 2012.

       Note too that while this option governs the protocol version used,
       not all features of each version are available.

Jeśli zdefiniujesz swojego mounta /etc/fstab, może on wyglądać mniej więcej tak:

//server/share  /mnt/share  cifs  defaults,vers=3.0,...your_other_options...,nofail,x-systemd.device-timeout=15 0 0
mivk
źródło
cifs vers = 1.0, credentials = / root / .smbcredentials, pracował dla mnie w 18.04 LTS. Dołączenie „defaults” do fsatb spowodowało błąd analizy, więc usunięcie tego tekstu pomogło uniknąć błędu.
Graham
@Graham smb1 jest bardzo przestarzały i niebezpieczny. Jest również wolniejszy. Postaraj się dostać przynajmniejvers=2.1
Joel Coehoorn
@JoelCoehoorn, ale vers = 1.0 działało, podczas gdy późniejsze wersje nie działały ... Zacząłem od 3 i zmieniałem vers w dół, aż 1.0 działało. Od tego czasu absolutnie nie ma problemów.
Graham
@Graham Następnie musisz naprawić host, z którym się łączysz, aby obsługiwał smb2.1 lub nowszy. SMB1.0 jest naprawdę zły .
Joel Coehoorn
@JoelCoehoorn Postępowałem zgodnie ze wskazówkami zawartymi w tym wątku: serverfault.com/questions/414074/mount-cifs-host-is-down, aby rozwiązać problem. Właśnie wypróbowałem vers = 3.0 ponownie i ten sam błąd nadal występuje, a napęd się nie podłącza. Co jest tak strasznego w vers = 1.0?
Graham
0

Miałem ten sam problem po aktualizacji klienta cifs-utils do wersji 6.7-2. I w zasadzie rozwiązanie od Josepcoves i user695658 działało dla mnie. Ale dla mnie działała tylko wartość 1,0 dla opcji montowania „vers”. Wygląda na to, że domyślna wartość parametru „vers” nie jest już 1.0.

dev-null
źródło
To jest kopia zaakceptowanej odpowiedzi.
karel