web-dev-qa-db-fra.com

ne peut pas utiliser mount.cifs: erreur de montage (2): aucun fichier ou répertoire de ce type

La commande mount.cifs ne fonctionne pas dans un système gentoo avec systemd 

ae429-1105 etc # mount -t cifs //file.abc.edu.au/user /home/directory/path -o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Il a été confirmé que l'existence et l'accessibilité du point de montage /home/directory/path et du fichier d'informations d'identification /etc/utilisateur . Les modules et services pertinents ont également été activés, c'est-à-dire,

 ae429-1105 etc # lsmod |egrep 'Fuse|cifs'
 Fuse                   72589  5 
 cifs                  312131  0

et

ae429-1105 etc # systemctl -t service -a |grep Samba
nmbd.service                         loaded active   running Samba NetBIOS                     name server
smbd.service                         loaded active   running Samba SMB/CIFS     server
winbindd.service                     loaded inactive dead    Samba Winbind daemon

Ce problème a été identifié par de nombreux utilisateurs, par exemple n exemple . NOTEZ ÉGALEMENT que la même commande exécutée dans mon système Ubuntu/debian est capable de monter avec succès.

Autres informations dans la machine problématique:

ae429-1105 etc # mount.cifs --version
mount.cifs version: 6.1

la version de mount.cifs installée dans debian/ubuntu est 6.0

mount
17
Chenming Zhang

Vous devrez peut-être fournir l'option vers = à la commande mount pour forcer la version 3.0 si vous essayez de monter un partage à partir d'une version plus récente de Windows. L'un de nos serveurs de fichiers a récemment été mis à niveau vers 2012R2 et c'est à ce moment que ma monture a cessé de fonctionner. Le mettre à vers = 3.0 a résolu le problème. Comme la plupart des erreurs Samba/CIFS, le message "Aucun fichier ou répertoire de ce type" n'aide pas beaucoup.

Par exemple:

# mount -t cifs //win2012r2/someshare -o cred=/home/foo/.cifs_user, vers=3.0 /mnt/tmp

..où j'ai mon domaine, mon nom d'utilisateur et mon mot de passe contenus dans le fichier .cifs_user.

Apparemment, smbmount utilise une version plus récente du protocole SMB par défaut car il fonctionnait sans problème ni aucune option spéciale.

Notez ci-dessous que la version du protocole par défaut est 1.0.

Depuis la page de manuel mount.cifs:

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.
8
foobrew

Pouvez-vous utiliser l'option nodfs? c'est-à-dire pour votre -o les options d'entrée passent l'entrée comme ci-dessous.

-o credentials=/etc/user,rw,iocharset=utf8,file_mode=0777,dir_mode=0777,nodfs

c'est-à-dire ,nodfs

Ça a marché pour moi.

5
Sanath

Vous devrez peut-être modifier le paramètre sec: ce paramètre l'a fait fonctionner sur ma configuration:

mount.cifs ... -o sec=ntlm

Extrait pertinent de man mount.cifs:

sec= Mode sécurité. Les valeurs autorisées sont:

  • none - tentative de connexion en tant qu'utilisateur nul (sans nom)
  • krb5 - Utiliser l'authentification Kerberos version 5
  • krb5i - Utilisez l'authentification Kerberos et activez de force la signature des paquets
  • ntlm - Utiliser le hachage de mot de passe NTLM
  • ntlmi - Utiliser le hachage de mot de passe NTLM et forcer la signature des paquets
  • ntlmv2 - Utiliser le hachage de mot de passe NTLMv2
  • ntlmv2i - Utiliser le hachage de mot de passe NTLMv2 et forcer la signature des paquets
  • ntlmssp - Utiliser le hachage de mot de passe NTLMv2 encapsulé dans un message Raw NTLMSSP

  • ntlmsspi - Utilisez le hachage de mot de passe NTLMv2 encapsulé dans le message Raw NTLMSSP et forcez la signature des paquets

    La valeur par défaut dans les versions du noyau principal avant la v3.8 était sec=ntlm. Dans la v3.8, la valeur par défaut a été remplacée par sec=ntlmssp.

    Si le serveur nécessite une signature pendant la négociation du protocole, il peut être activé automatiquement. La signature de paquets peut également être activée automatiquement si elle est activée dans /proc/fs/cifs/SecurityFlags.

2
Benoit Duffez

Ajouter un $ à la fin, comme ceci //winserver/sharename$

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename$ /mnt/mymountpoint
1
Fahri çetin

Je suis tombé sur cela sur Ubuntu 18.04. Le problème était que j'avais besoin du package keyutils pour effectuer l'authentification Kerberos (sec=krb5 option de montage), qui n'était pas installé avec cifs-utils (qui fournissait mount.cifs). Je ne sais pas si le nom du package est le même sur Gentoo ou non. (Merci à https://forum.zentyal.org/index.php?topic=18601. pour la solution.)

1
Chris

Essayez d'installer le package keyutils:

Sudo apt-get install keyutils

Je ne sais pas exactement pourquoi cela aide, peut-être que quelqu'un d'autre a une réponse ici. Mais au moins, cela a fait l'affaire pour moi: avec les keyutils, la monture cifs a très bien fonctionné.

1
Klaus

Je voulais ajouter une autre source de ce problème que j'ai rencontré aujourd'hui. Une fois que vous avez modifié l'ID utilisateur d'un utilisateur Unix, l'utilisateur smb créé via smbpasswd peut ne plus être en mesure de s'authentifier pour le partage samba, ce qui entraîne la même erreur.

Donc, si vous avez changé votre identifiant utilisateur Unix via usermod -u 1000 my_user alors vous pourriez rencontrer des problèmes. Le correctif pour moi était de supprimer et de rajouter l'utilisateur smb par la suite:

 smbpasswd -x mon_utilisateur 
 smbpasswd -a mon_utilisateur
1
Ryad

Une solution pourrait être d'installer manuellement keyutils car il ne s'agit pas d'une dépendance (dure) de cifs-utils plus.

Les informations expliquant pourquoi les keyutils ne sont plus installés peuvent être trouvées ici: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822841

Et un rapport de bug du tableau de bord peut être trouvé ici: https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1772148

0
tuk8

Je rencontrais cette même erreur "erreur de montage (2): aucun fichier ou répertoire" en utilisant mount.cifs sur une machine virtuelle CentOS 7. Je n'ai jamais déterminé exactement pourquoi l'erreur était générée lors de l'utilisation de la sécurité par défaut ntlm (et les variantes), mais j'ai découvert que l'utilisation de l'authentification Kerberos a permis de contourner le problème. Donc, ma dernière ligne de commande de travail ressemblait à ceci:

mount.cifs -v -o domain=MYCODOMAIN,sec=krb5 //winserver/sharename /mnt/mymountpoint

alors que cette commande qui a donné l'erreur "aucun fichier ou répertoire" était:

mount.cifs -v -o username=myusername,domain=MYCODOMAIN //winserver/sharename /mnt/mymountpoint

Pour utiliser Kerberos, j'ai installé le package "krb5-workstation" et l'ai configuré.

0
Mark Edington

Avec moi, cela a fonctionné en mettant "vers = 1.0" comme avant -> credentials =/root/.dbx.credentials, vers = 1., uid = 1001, gid = 100 , rw

0
Carlos Roberto da Silva Junior