Samba: błąd montowania: nie można rozwiązać adresu dla XXX: nieznany błąd

Przeczytałem kilka przewodników na temat montowania udziałów w sambie, ale nie mam jeszcze szczęścia.

Jestem w stanie „zalogować się” do mojego udziału samba za pomocą następującego polecenia:

smbclient //vvlaptop/Documents

Prosi o hasło, ale nie ma hasła, więc po prostu naciśnij Enter. Następnie z powodzeniem loguje mnie za pomocą monitu smb: \>. Z jakiegoś powodu nie mogę zamontować udziału. Oto polecenie, którego używam:

mount -t cifs //vvlaptop/Documents /mnt/virginia
mount error: could not resolve address for vvlaptop: Unknown error

Jak mogę pomyślnie zamontować to urządzenie?

smbclient potrafi wyszukać nazwy hostów

mount nie może wyszukać nazw hostów

Aby zamontować według nazwy, musisz użyć lokalnej usługi DNS, takiej jak Avahi. Bez lokalnego DNS musisz podać adres IP podczas łączenia. Możesz użyć nmblookup -S WORKGROUPdo odkrycia adresu IP.

mount -t cifs //192.168.0.123/Documents /mnt/virginia

Zwykle lepszym sposobem na uzyskanie dostępu do udziałów jest użycie smbnetfs. Umożliwi to zamontowanie wielu udziałów bez uprawnień administratora.

smbnetfs ~/mountdir
fusermount -u ~/mountdir # To unmount.

Strona podręcznika dla smbnetfs powie ci więcej.

Jeśli udział wymaga loginu i hasła, wykonaj następujące kroki.

mkdir ~/.smb
cp /etc/samba/smb.conf /etc/smbnetfs.conf ~/.smb/
touch ~/.smb/smbnetfs.auth
chmod 600 ~/.smb/*

Edytuj plik, ~/.smb/smbnetfs.authaby wstawić poświadczenia. Format pliku

auth            "hostname" "username" "password"

Spróbuj wykonać następujące polecenie:

$ mount -t cifs -o username=USERNAME,password= //vvlaptop/Documents /mnt/virginia

Dodatkowo możesz przechowywać poświadczenia w pliku i odwoływać się do nich:

$ mount -t cifs //vvlaptop/Documents /mnt/virginia \
    -o credentials=/home/mylogin/winpasswd

Następnie umieść swoje poświadczenia w tym pliku:

username=mylogin
password=

Jeśli poświadczenia są częścią domeny, dołącz to również do pliku:

domain=domainname

Bibliografia

• Montowanie udziałów samby z klienta unix

Miał ten sam problem przy próbie zamontowania naszego NAS. Okazuje się, że potrzebne są różne polecenia dla (jak sądzę) różnych formatów, tj. Ext 4, NTFS itp. Kiedy w końcu znalazłem poprawną wersję, byłem w stanie zamontować poprzez fstabi terminal.
Używamy Iomega NAS

To fstabdziała

//NASIomega/Documents /mnt/nas/Documents cifs guest,uid=1000,gid=1000,rw,iocharset=utf8,_netdev,file_mode=0777,dir_mode=0777,auto 0 0

Początkowo użyłem formatu liczb zamiast nazwy, ale liczby ciągle się zmieniały. Niestety nie udało się podać stałych adresów IP w razie potrzeby, więc nadano maszynie nazwę i teraz działa.

Jednak to przestało działać na naszych wersjach nadia i maya (2 różne komputery). Nadia zaczęła działać może z powodu aktualizacji? (nie wiedząc o robieniu niczego, aby to poprawić, mimo prób). Maya nadal nie działa. O ile wiem, nic nie zmieniłem. Wygląda na to, że mogą tam być jakieś problemy.

Miałem dokładnie te same objawy i musiałem szturchnąć Avahi, aby rozpocząć nową instalację 18.04.1 (która była już wielokrotnie uruchamiana ponownie). Potem wszystko działało. Podejrzewam, że wiele osób kończy zadawanie tych pytań, ponieważ może nie zdają sobie sprawy, że nie zaczynało się na maszynie wirtualnej z jakiegokolwiek powodu itp.

Proszę przeczytać odpowiedź Rucent88, zanim przeczytałem więcej moich, co było jednym z najbardziej pomocnych postów na ten temat, a pytanie było świetnym zwięzłym pytaniem.

Ze świeżymi instalacjami 18.04.1, na VMware działało od razu po wyjęciu z pudełka. W VirtualBox musiałem ustawić sieć w VirtualBox na „Bridged Adapter”, a następnie podbić Avahi i dodać .localdo nazwy hosta. Zainstalowałem VMware wiele razy i nigdy nie miałem problemów, dopóki nie wypróbowałem VirtualBox kilka dni temu.

Podczas mojej dwudniowej przygody odkryłem, że Avahi nie uruchamiał się poprawnie w nowej wersji 18.04.1 w ustawieniach VirtualBox, gdzie wydawało się, że zaczyna się dobrze w przypadku nowych instalacji VMware. Oprócz tego na VMware dzieje się trochę innych magii, ponieważ nie muszę dodawać .local, w przypadku nazwy maszyny XXX i instalacji VMware mogę po prostu użyć zwykłej nazwy hosta Windows.

Na VirtualBox, gdybym to zrobił:

sudo avahi-daemon --check
sudo avahi-daemon
Daemon already running on PID 721

przed tym z dodanym .local:

sudo mount -t cifs -o username=bob,uid=bob,gid=bob //Xxx.local/MyShare /mnt/MyShare

to działa.

Niektóre osoby twierdzą, że zmiana nsswitch.confpowinna naprawić mountrozwiązanie nazwy. Ale po skonfigurowaniu winbindi dodaniu do listy na wiele różnych sposobów nie działało, a dodawanie lub usuwanie mdns4_minimalwydaje się w rzeczywistości nie wpływać mount. Być może plik nie był używany.

Zobacz także https://ubuntuforums.org/showthread.php?t=2099537, który jest bardzo krótkim przykładem kogoś, kto ma problem i kogoś, kto pokazuje składnię do naprawy jego polecenia, jeśli brakuje tylko różnic przy korzystaniu z rozdzielczości Avahi.