mount.cifs kann nicht dieselbe Anmeldeinformationsdatei verwenden, die smbclient verwendet


10

Ich versuche, eine NetApp CIFS-Freigabe auf einem unserer Server bereitzustellen, und ich bekomme immer wieder "Berechtigung verweigert" auf stderr NT_STATUS_WRONG_PASSWORDgedruckt und auf die Ausführung gedruckt 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

Der smbclientBefehl funktioniert jedoch ohne Probleme mit derselben exakten Anmeldeinformationsdatei:

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...]

Es scheint, als ob das eine funktioniert, sollte das andere auch funktionieren, zumal die Anmeldeinformationsdatei auch den Domänennamen angibt.


Was ist mit dem Kopfgeld passiert?

Ich habe nie eine Antwort bekommen, die für mich funktioniert hat, so dass das Kopfgeld schließlich abgelaufen ist und all diese Punkte den Weg des Dodos gegangen sind.
Bratchley

Wenn Ihnen die Antwort einfällt, werde ich Ihnen ein neues Kopfgeld gewähren. Ich möchte nur keine Verlustpunkte behalten, wenn ich keine Antwort bekomme.
Bratchley

Ich hatte also ein ähnliches Problem (mit dem Fehler -13 vom Kernelmodul). Ich habe das cifs-utilsPaket (Debian) installiert und es hat das Problem behoben. Ich habe ein bisschen damit verbracht, dies zu debuggen, weil ich keine Unterstützung erwartet hatte , ohne dass das Paket installiert worden war, also nahm ich an, dass dies der Fall war. Ich hatte so etwas wie "unbekanntes Dateisystem" von mount erwartet, aber das ist nicht passiert.
Sherellbc

Antworten:


7

Ohne weitere Informationen kann ich nicht sicher sagen, aber ich habe dieses Problem beim Herstellen einer Verbindung zu einem älteren Windows-Server gesehen, auf dem eine ältere Protokollversion ausgeführt wurde. Denken Sie daran, dass CIFS als "Dialekt" (Typ) von KMU betrachtet wird. Es gibt andere Typen und ältere Setups verwenden kein CIFS.

Im Grunde ist es so, als würden zwei Leute sprechen. Ein Spanisch und ein Englisch, und Sie versuchen, den englischen Sprecher zu zwingen, Spanisch zu verstehen, wenn er dies eindeutig nicht tut.

SMBclient verwendet für Sicherheitsverhandlungen ein anderes Dielektrikum. (oder zumindest anders erkennt).

Versuchen

mount -t cifs // Pfad / Ding / / mount / Punkt -o Benutzername = Benutzer, Passwort = Pass, Sek = ntlm

und sehen, was passiert. (sec = ntlm ist der wichtige Teil)


Gleiches Problem, auch wenn die NTLM-Authentifizierung angegeben wird. Das gleiche wenn ich ntlmoder ntlmv2. Ich bin mir nicht sicher, wie ich das Problem beheben soll. Wenn Sie weitere Informationen benötigen, lassen Sie es mich wissen und ich werde die Frage aktualisieren. Könnte es auf der NetApp-Seite einige Zugriffskontrollen geben, die der SAN-Typ übersehen hat?
Bratchley

Version der Serversoftware, stehen Router oder Switches im Weg?
Coteyr

Gleiches Subnetz. Ich bin mir nicht sicher, welche Version von Samba auf der anderen Seite ist, da es sich um eine NetApp ONTAP-Appliance handelt.
Bratchley

4

Beim Herumspielen mit den Befehlen habe ich einen möglichen Grund gefunden:

Aus der Manpage von 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.

Aus der Manpage von 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

Dann habe ich zwei Anmeldeinformationsdateien erstellt, eine mit Leerzeichen, wie im ersten Snippet gezeigt, und eine ohne und benannte sie credsund creds.spacy.

Der große Showdown:

Mit credsDatei:

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

Gute Stille, keine Fehler.

Mit creds.spacyDatei:

# 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)

Ihre Anmeldeinformationsdatei enthält also offensichtlich Leerzeichen, die von mount.cifs nicht verstanden werden.

Außerdem spielt smbclientes keine Rolle, ob Leerzeichen vorhanden sind. credsund creds.spacyverursachte kein Auerhahn.


Am Ende der Datei befand sich eine zusätzliche Leerzeile, aber nach dem Löschen erhalte ich dasselbe. Dies ist eine leicht überarbeitete Version der creds-Datei. Redigierte und echte Passwörter sind Passwörter in Groß- und Kleinschreibung, die "!" als Sonderzeichen.
Bratchley

Es gibt noch einen weiteren Aspekt, den ich aufgrund dieser Lösung gefunden habe: Die Anmeldeinformationen müssen in der richtigen Reihenfolge vorliegen, dh Benutzername, Passwort, Domain und keine andere Reihenfolge wie Domain, Benutzername, Passwort (was ich hatte). Dies funktioniert auch gut mit smbclient, schlägt aber fehl mount.cifs. Nachdem ich die Reihenfolge in die richtige geändert hatte, wie in der hier zitierten Dokumentation angegeben, funktionierte sie. Scheint, als ob diese (sowohl die falsche Behandlung von Leerzeichen als auch das Bestellproblem) schreckliche Fehler sind, die von jedem, der sie pflegt, leicht behoben werden sollten mount.cifs.
leftclickben

2

Das Hinzufügen von sec = ntlm hat das Problem für mich behoben. Ich habe ein älteres NAS (Netgear Stora). Die Standardsicherheit für cifs in aktuellen Kerneln ist ntlmssp


Hat auch für mich gearbeitet. Ich kenne die wahre Ursache noch nicht. Für den Fall, dass es jemandem hilft: Isilon Mount auf Ubuntu LTS 14.04. Das Isilon (ein SAN-Ding) kommuniziert mit unserem Windows Active Directory. Das gleiche Konto funktionierte wie ein Zauber auf anderen Maschinen und bei der direkten Montage in Windows.
Reinout van Rees

Zusätzlicher Hinweis: 12.04 mit den neuesten Updates funktioniert einwandfrei, 14.04 ist jetzt irgendwie Teil des Problems (Ende April 2015).
Reinout van Rees

Letzte zusätzliche Anmerkung: Das Kernproblem war ein bekanntes Microsoft-Problem mit dem Emc Isilon-Speicher und dem Update KB3002657 (oder so sagt mir mein Systemadministrator gerade :-))
Reinout van Rees

2

Eine andere Möglichkeit, die ich heute beim Versuch, eine Freigabe bereitzustellen, entdeckt habe, besteht darin, dass smbmountdie username=DOMAIN\\userSyntax unterstützt wird, einen Benutzer in einer Domäne als Berechtigungsnachweis anzugeben.

Damit mount.cifs(und mount -t cifs) funktionieren, müssen diese beiden separat bereitgestellt werden : -o username=user,password=pass,dom=DOMAIN.


Um eine smb 3.0-Freigabe bereitzustellen, die von einem NetApp Clustered Data ONTAP bereitgestellt wird, musste ONTAP beide sec=ntlmunddom=DOMAIN
iii

1

Wie user55518 erklärt hat, haben Sie wahrscheinlich Leerzeichen in Ihrer Anmeldeinformationsdatei, auch wenn Sie diese nicht sehen. Wenn Sie Ihre Anmeldeinformationsdatei unter Windows bearbeitet haben, haben Sie wahrscheinlich \ram Ende Ihrer Zeilen und das löst den Fehler 13 aus.


Sie können die Befehlssatzliste in vim verwenden, um nach zusätzlichen Tabulatoren / Leerzeichen zu
suchen

0

Ich möchte euch allen danken !!! Für dieses Problem hat es mir sehr geholfen! Außerdem habe ich einige wichtige Informationen über den Parameter "sec = ntlm" gefunden. Ich verlasse den Link, wenn einige von Ihnen daran interessiert sind, Zeilen unten:

Microsoft NTLM

Ich habe versucht, ein Freigabeverzeichnis von Windows 7 Desktop zu mounten, aber es war unmöglich, den Parameter "sec = ntlm" hinzuzufügen, und es funktioniert, und einige wichtige Details könnten sein, dass ich nicht berücksichtigt habe, dass mein Windows 7-Desktop in einem ist Domain, also denke ich, es war das wichtigste Detail, das ich berücksichtigen sollte. deshalb funktioniert es!, wirklich vielen Dank euch allen!, Segen !! und gute Stimmung! : D.


0

In meinem Fall musste ich nur die Option hinzufügen vers=3.0(CIFS war Version 1, die seit Kernel 4.13 nicht mehr unterstützt wird, also habe ich auf dem Server direkt zu SMBv3 gewechselt) und musste trotzdem neu starten, damit es funktioniert Mount Line in /etc/fstabjetzt:

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

Meine Anmeldeinformationsdatei:

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

Eigentlich wird domaines nicht benötigt, aber es ist die richtige Option, um es jetzt gemäß der Manpage mount.cifs zu verwenden.


0

Ich habe eine Weile damit zu kämpfen.

Mit folgenden Fehlern:

mount error(112): Host is down

hier hat es geholfen, die Option vers = 1.0 zu setzen, dann wurde berichtet

mount error(13): Permission denied

und es stellte sich heraus, dass es sich um zusätzliche "Zeichen in meiner Anmeldeinformationsdatei handelte

wo ich ursprünglich hatte:

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

wo es sein sollte

# cat /etc/samba/cred-file
username=john
password=secret
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.