mount.cifs nie może użyć tego samego pliku danych logowania, którego używa smbclient

Próbuję zamontować udział NetApp CIFS na jednym z naszych serwerów i ciągle otrzymuję komunikat „Odmowa zezwolenia” na stderr i NT_STATUS_WRONG_PASSWORDdrukowany na bieżąco dmesg.

root@xxxehpvld05 ~ $ mount.cifs -vv //zhp-nas.xxx.com/perspectives /mnt/secure/cifs -o credentials=/etc/cifs.creds
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
root@xxxehpvld05 ~ $ dmesg | tail
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
Status code returned 0xc000006a NT_STATUS_WRONG_PASSWORD
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13

smbclientPolecenia, jednak działa bez problemu, przy użyciu tego samego pliku dokładne mandatów:

root@xxxehpvld05 ~ $ smbclient -L //zhp-nas.xxx.com/perspectives -A /etc/cifs.creds
Domain=[XXX] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       Remote IPC
        ZHPSubmit-dev   Disk
    [...snip...]

Wygląda na to, że jedno z nich powinno działać również drugie, zwłaszcza że plik poświadczeń określa również nazwę domeny.

Bez dodatkowych informacji nie mogę powiedzieć na pewno, ale widziałem ten problem podczas łączenia się ze starszym serwerem Windows, na którym działała starsza wersja protokołu. Pamiętaj, że CIFS jest uważany za „dialekt” (typ) SMB. Istnieją inne typy i starsze konfiguracje nie używają CIFS.

Zasadniczo to tak, jakby mówić dwie osoby. Jeden hiszpański i jeden angielski, a ty próbujesz zmusić osobę mówiącą po angielsku do zrozumienia hiszpańskiego, kiedy wyraźnie tego nie robi.

SMBclient używa innego dielektryka do negocjacji bezpieczeństwa. (lub przynajmniej wykrywa inaczej).

Próbować

mount -t cifs // ścieżka / rzecz / / mount / point -o nazwa użytkownika = użytkownik, hasło = hasło, sec = ntlm

i zobacz co się stanie. (sec = ntlm jest ważną częścią)

Bawiąc się poleceniami, znalazłem możliwy powód:

Ze strony podręcznika użytkownika smbclient:

   -A|--authentication-file=filename
       This option allows you to specify a file from which to read the
       username and password used in the connection. The format of the file is

           username = <value>
           password = <value>
           domain   = <value>

       Make certain that the permissions on the file restrict access from
       unwanted users.

Ze strony manuala mount.cifs:

   credentials=filename
       specifies a file that contains a username and/or password and
       optionally the name of the workgroup. The format of the file is:

          username=value
          password=value
          domain=value

Następnie utworzyłem dwa pliki referencji, jeden ze spacjami, jak pokazano w pierwszym fragmencie, a drugi bez i nazwał je credsoraz creds.spacy.

Wielkie showdown:

Z credsplikiem:

mount.cifs -vvv //host/path /local/path -o credentials=/path/creds

dobra cisza, bez błędów.

Z creds.spacyplikiem:

# mount.cifs -vvv //host/path /local/path -o credentials=/path/creds.spacy
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Oczywiście plik poświadczeń zawiera spacje, które nie są rozumiane przez mount.cifs.

Ponadto smbclientnie ma znaczenia, czy są spacje. credsi creds.spacynie spowodował żadnego cietrzewia.

Dodanie sec = ntlm rozwiązało problem. Mam starszy NAS (netgear stora). Domyślnym zabezpieczeniem cifs w najnowszych jądrach jest ntlmssp

Inną możliwością, którą odkryłem, próbując dzisiaj zamontować udział, jest smbmountobsługa username=DOMAIN\\userskładni dostarczania użytkownika w domenie jako poświadczenia.

Do mount.cifs(i mount -t cifs) do pracy, te dwa muszą być dostarczane oddzielnie: -o username=user,password=pass,dom=DOMAIN.

Jak wyjaśnił user55518, prawdopodobnie w pliku danych logowania znajdują się spacje, nawet jeśli ich nie widzisz. Jeśli edytowałeś plik poświadczeń w systemie Windows, prawdopodobnie masz go \rna końcu linii, co powoduje błąd 13.

Chcę wam wszystkim podziękować !!! w przypadku tego problemu, to naprawdę bardzo mi pomaga !, znalazłem też ważne informacje o parametrze „sec = ntlm”, więc zostawiam link, jeśli niektórzy z was są zainteresowani, wiersze poniżej:

Microsoft NTLM

Próbowałem zamontować katalog udostępniania z pulpitu Windows 7, ale nie byłem w stanie dodać parametru „sec = ntlm” i działa, a niektóre ważne szczegóły mogą być takie, że nie uważałem, że mój pulpit Windows 7 był domenę, więc uważam, że był to najważniejszy szczegół, który powinienem rozważyć. dlatego to działa !, naprawdę dziękuję bardzo wszystkim! błogosławieństwa !! i dobre wibracje! :RE

W moim przypadku musiałem tylko dodać opcję vers=3.0(CIFS to wersja 1, która nie jest już obsługiwana od jądra 4.13, więc przełączyłem się w prawo do SMBv3 na serwerze) i nadal musiałem zrestartować komputer, aby działał, to jest mój zamontuj linię /etc/fstabteraz:

auto,rw,credentials=/usr/local/etc/smb.credentials,vers=3.0,file_mode=0664,dir_mode=0775,uid=myuser,gid=users

Mój plik poświadczeń:

username=myuser
password=****
domain=mydomain

Właściwie domainto nie jest potrzebne, ale teraz jest to poprawna opcja do użycia zgodnie ze stroną podręcznika mount.cifs.

Walczyłem z tym przez jakiś czas.

Z następującymi błędami:

mount error(112): Host is down

tutaj pomógł ustawić opcję vers = 1.0, a następnie zgłosił

mount error(13): Permission denied

i okazało się, że w moim pliku referencji są dodatkowe „znaki”

gdzie pierwotnie miałem:

# cat /etc/samba/cred-file
username="john"
password="secret"

gdzie powinno być

# cat /etc/samba/cred-file
username=john
password=secret