mount.cifs ne peut pas utiliser le même fichier d'informations d'identification que smbclient utilise


10

J'essaie de monter un partage NetApp CIFS sur l'un de nos serveurs et je continue à obtenir "Autorisation refusée" imprimé sur stderr et NT_STATUS_WRONG_PASSWORDimprimé sur le serveur en cours d'exécution 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

La smbclientcommande, fonctionne cependant sans problème, en utilisant le même fichier d'informations d'identification exactes:

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

Il semble que si l'un fonctionne, l'autre le devrait aussi, d'autant plus que le fichier d'informations d'identification spécifie également le nom de domaine.


qu'est-il arrivé à la prime?

Je n'ai jamais eu de réponse qui a fonctionné pour moi, donc la prime a finalement expiré et tous ces points ont fait le chemin du dodo.
Bratchley

Si vous pouvez penser à la réponse, je vais vous attribuer une nouvelle prime, je ne veux tout simplement pas garder des points perdus si je n'obtiens pas de réponse.
Bratchley

Donc, j'avais un problème similaire (avec l'erreur -13 du module du noyau). J'ai installé le cifs-utilspaquet (Debian) et cela a résolu le problème. J'ai passé un peu à déboguer cela parce que je ne m'attendais à aucun support sans que le paquet ait été installé, alors j'ai supposé que c'était le cas. J'attendais quelque chose comme "système de fichiers inconnu" de la part de mount, mais cela ne s'est pas produit.
sherrellbc

Réponses:


7

Sans plus d'informations, je ne peux pas le dire avec certitude, mais j'ai vu ce problème lors de la connexion à un ancien serveur Windows qui exécutait une ancienne version de protocole. N'oubliez pas que CIFS est considéré comme un "dialecte" (type) de SMB. Il existe d'autres types et les anciennes configurations n'utilisent pas CIFS.

Fondamentalement, c'est comme dire que deux personnes parlent. Un espagnol et un anglais, et vous essayez de forcer le locuteur anglais à comprendre l'espagnol alors qu'il ne le comprend clairement pas.

SMBclient utilise un diélectrique différent pour les négociations de sécurité. (ou du moins détecte différemment).

Essayer

mount -t cifs // chemin / chose / / mount / point -o nomutilisateur = utilisateur, mot de passe = passe, sec = ntlm

et voyez ce qui se passe. (sec = ntlm est la partie importante)


Même problème même lors de la spécification de l'authentification NTLM. Même si je fais ntlmou ntlmv2. Je ne sais pas comment le résoudre, donc si vous avez besoin de plus d'informations, faites-le moi savoir et je mettrai à jour la question. Pourrait-il y avoir des contrôles d'accès du côté de NetApp que le gars du SAN a manqué?
Bratchley

Version du logiciel serveur, y a-t-il des routeurs ou des commutateurs sur le chemin?
coteyr

Même sous-réseau. Je ne sais pas quelle version de Samba est de l'autre côté car c'est une appliance NetApp ONTAP.
Bratchley

4

En jouant avec les commandes, j'ai trouvé une raison possible:

Depuis la page de manuel de 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.

Depuis la page de manuel de 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

Ensuite, j'ai créé deux fichiers d'informations d'identification, un avec des espaces, comme indiqué dans le premier extrait et un sans et les a nommés credset creds.spacy.

La grande épreuve de force:

Avec credsdossier:

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

bon silence, pas d'erreurs.

Avec creds.spacydossier:

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

Donc, évidemment, votre fichier d'informations d'identification contient des espaces, qui ne sont pas compris par mount.cifs.

De plus, smbclientpeu importe s'il y a des espaces. credset creds.spacyn'a causé aucun tétras.


Il y avait une ligne vierge supplémentaire à la fin du fichier mais j'obtiens la même chose après l'avoir supprimé. Il s'agit d' une version légèrement expurgée de ce qui se trouve dans le fichier creds. Les mots de passe rédigés et réels sont des mots de passe à casse mixte contenant "!" comme caractère spécial.
Bratchley

Il y a un autre aspect à cela, que cette solution m'a amené à trouver: les informations d'identification doivent être dans le bon ordre, c'est-à-dire nom d'utilisateur, mot de passe, domaine et pas tout autre ordre comme domaine, nom d'utilisateur, mot de passe (c'est ce que j'avais). Cela fonctionne également très bien smbclientmais échoue mount.cifs. Une fois que j'ai changé la commande pour la bonne comme spécifié dans la documentation que vous avez citée ici, elle a commencé à fonctionner. On dirait que ceux-ci (à la fois la mauvaise gestion des espaces et le problème de commande) sont de terribles bogues qui devraient être facilement corrigés par quiconque le maintient mount.cifs.
leftclickben

2

L'ajout de sec = ntlm a corrigé le problème pour moi. J'ai un NAS plus ancien (netgear stora). La sécurité par défaut pour les cifs dans les noyaux récents est ntlmssp


A aussi fonctionné pour moi. Je ne connais pas encore la vraie cause. Au cas où cela aiderait quelqu'un: montage isilon sur ubuntu LTS 14.04. L'isilon (quelque chose de SAN) parle à notre répertoire actif Windows. Le même compte a fonctionné comme un charme sur d'autres machines et lors du montage direct dans des fenêtres.
Reinout van Rees

Note supplémentaire: 12.04 avec les dernières mises à jour fonctionne bien, 14.04 fait en quelque sorte partie du problème maintenant (fin avril 2015).
Reinout van Rees

Dernière note supplémentaire: le problème principal était un problème connu de Microsoft avec le stockage emc isilon et la mise à jour KB3002657 (ou du moins mon administrateur système me le dit maintenant :-))
Reinout van Rees

2

Une autre possibilité que j'ai découverte en essayant de monter un partage aujourd'hui est de prendre en smbmountcharge la username=DOMAIN\\usersyntaxe pour fournir un utilisateur dans un domaine comme informations d'identification.

Pour mount.cifs(et mount -t cifs) au travail, ces deux doivent être fournis séparément: -o username=user,password=pass,dom=DOMAIN.


Pour monter un partage smb 3.0 servi par un NetApp Clustered Data, ONTAP a dû appeler les deux sec=ntlmetdom=DOMAIN
iii

1

Comme l'a expliqué user55518, vous avez probablement des espaces dans votre fichier d'informations d'identification même si vous ne les voyez pas. Si vous avez modifié votre fichier d'informations d'identification sur Windows, vous avez probablement \rà la fin de vos lignes et cela jette l'erreur 13.


vous pouvez utiliser la liste des jeux de commandes dans vim pour vérifier les tabulations / espaces supplémentaires
vfbsilva

0

Je tiens à vous remercier tous !!! pour ce problème, cela m'a vraiment beaucoup aidé !, j'ai également trouvé des informations importantes sur le paramètre "sec = ntlm", donc je laisse le lien si certains d'entre vous sont intéressants à ce sujet, lignes ci-dessous:

Microsoft NTLM

J'essayais de monter un répertoire de partage à partir du bureau Windows 7, mais il était impossible d'ajouter le paramètre "sec = ntlm" et cela fonctionne, et certains détails importants pourraient être que je n'ai pas considéré que mon bureau Windows 7 était dans un domaine, donc je pense que c'était le détail le plus important que je devrais considérer. par conséquent, cela fonctionne !, merci vraiment beaucoup à vous tous!, bénédictions !! et bonnes vibes! :RÉ


0

Dans mon cas, je n'avais qu'à ajouter l'option vers=3.0(CIFS était la version 1, qui n'est plus prise en charge depuis le noyau 4.13, donc je suis passé directement à SMBv3 sur le serveur) et j'ai quand même dû redémarrer pour le faire fonctionner, c'est mon monter la ligne /etc/fstabmaintenant:

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

Mon fichier d'informations d'identification:

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

En fait, ce domainn'est pas nécessaire, mais c'est l'option correcte à utiliser selon la page de manuel mount.cifs maintenant.


0

Je me bats avec ça depuis un moment.

Avec les erreurs suivantes:

mount error(112): Host is down

ici, il a aidé à définir l'option vers = 1.0, puis il a signalé

mount error(13): Permission denied

et il s'est avéré qu'il y avait des caractères supplémentaires dans mon fichier d'informations d'identification

où à l'origine j'avais:

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

où il devrait être

# cat /etc/samba/cred-file
username=john
password=secret
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.