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 / répertoire / chemin et du fichier d'informations d'identification / etc / user . Les modules et services concernés ont également été activés, c.-à-d.

 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 un 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

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

Pouvez-vous utiliser l' nodfsoption? c'est-à-dire pour vos -ooptions d'entrée, passez l'entrée comme ci-dessous.

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

c'est-à-dire en annexe ,nodfs

Ça a marché pour moi.

Vous devrez peut-être modifier le secparamètre: 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 (pas de nom)
• krb5 - Utilisez l'authentification Kerberos version 5
• krb5i - Utilisez l'authentification Kerberos et activez de force la signature de 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 - Utiliser le hachage de mot de passe NTLMv2 encapsulé dans le message Raw NTLMSSP et forcer 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é changée en 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.

Je suis tombé sur cela sur Ubuntu 18.04. Le problème était que j'avais besoin du package keyutils pour faire l'authentification Kerberos ( sec=krb5option de montage), qui n'était pas installée 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.0 pour la solution.)

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

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_uservous pouvez rencontrer des problèmes. Le correctif pour moi était de supprimer et de rajouter l'utilisateur smb par la suite:

smbpasswd -x my_user
smbpasswd -a mon_utilisateur

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

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

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é ntlm par défaut (et des variantes), mais j'ai découvert que l'utilisation de l'authentification Kerberos contournait 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é.

Une solution pourrait être d'installer manuellement keyutilscar ce n'est plus une dépendance (dure) de cifs-utils.

Des informations sur les raisons pour lesquelles 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

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