Monter l'hôte CIFS est en panne

J'ai un problème avec un point de montage précédemment configuré. Il montre le dossier, mais le montage est manquant et contient "?" valeurs de taille, autorisations, etc.

J'ai donc essayé de remonter en utilisant cifs et la même commande que précédemment:

mount -t cifs //nas.domain.local/share /mnt/archive

Mais je reçois l'erreur:

Host is down.

Si je cingle le domaine ou l'adresse IP, je reçois une résolution correcte et je me connecte également à l'aide de smbclient sans problème

 ping nas.domain.local
 ping ip
 smbclient //nas.domain.local/share

J'ai regardé autour de moi, mais je ne peux pas trouver une réponse solide. Des pensées?

Cela pourrait aussi être dû à une inadéquation de protocole. En 2017, Microsoft a corrigé les serveurs Windows et conseillé de désactiver le protocole SMB1.

A partir de maintenant, mount.cifs pourrait avoir des problèmes avec la négociation de protocole.

L'erreur affichée est "L'hôte est en panne.", Mais lorsque vous effectuez un débogage avec:

smbclient -L <server_ip> -U <username> -d 256

vous obtiendrez l'erreur:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Pour résoudre ce problème, utilisez mount ou smbclient avec un protocole spécifié.

pour smbclient: ajoutez -m SMB2 (ou SMB3 pour la version la plus récente du protocole)

smbclient -L <server_ip> -U <username> -m SMB2

ou pour mount: ajoutez vers = 2.0 (ou vers = 3.0 si vous souhaitez utiliser la version 3 du protocole)

mount -t cifs //<server_ip>/<share> /mnt/<mountpoint> -o vers=2.0

Sur archlinux après une récente mise à jour du paquet, j'ai dû ajouter vers = 1.0 à mes options de montage. Je me connecte à une ancienne boîte centos 5 et, jusqu'à hier, je pouvais me connecter sans indiquer explicitement un numéro de version.

CIFS dans le noyau linux 4.13 utilise maintenant SMB 3.0 par défaut et dans le noyau 4.14, il essaie la version 2.1 ou supérieure. Voir ce journal des modifications .

La clé USB de Fritz NAS indiquait "Host Down" pour Ubuntu 17.10:

Définir la version ( vers=1.0) a fonctionné - voici la chaîne complète:

sudo mount -t cifs -o vers=1.0,_netdev,username=<user>,password=<pwd>,uid=1000,gid=1000  //192.168.178.1/fritz.nas <local mountpoint>

Problème similaire après la mise à niveau vers Ubuntu 17.10, avec un ancien Buffalo Diskstation. Résolu en ajoutant dans / etc / fstab l'option "vers = 1.0":

// myWDhostname / partage / media / Partage cifs guest, vers = 1.0 0 0

Désolé si la réponse est tardive (je réalise que c'est un ancien fil de discussion), mais je viens de découvrir qu'il existe une autre raison possible pour laquelle mount.cifs dirait que l'hôte est en panne.

J'ai un antivirus avec un pare-feu et même si je l'ai explicitement configuré pour autoriser le "partage de fichiers et d'impression Windows" - une règle prédéfinie, il bloquait toujours les connexions. Cela a été prouvé en désactivant temporairement le pare-feu. Espérer que cela aidera quelqu'un, l'hôte est en panne ne signifie peut-être pas qu'il ne répond pas aux pings, mais peut signifier qu'il ne répond pas aux tentatives d'authentification.

J'ai reçu la même erreur sans plus attendre de la part d'un nouveau client Samba, lors de la tentative de montage d'un partage réseau CIFS SMB:

mount error(112): Host is down

Finalement, il était apparu que j'avais précédemment restreint l'accès au serveur SMB à un nombre limité d'adresses IP en configurant /etc/samba/smb.conf:

# Allow these IP Addresses to connect: 
hosts allow = 127.0.0.1 127.0.1.13 127.0.1.63

# Anything else not allowed is, by default, rejected
hosts deny = ALL

L'ajout de l'adresse IP fixe du nouveau client SMB a résolu le problème dans ce cas particulier.

Bien sûr, il existe une multitude d'autres raisons pour lesquelles on peut recevoir l'erreur susmentionnée.

Même problème de connexion au Synology DiskStation (DSM 4.3).

Utiliser vers = 1.0 dans les options de montage fonctionne bien.

De plus, je devais utiliser l'option "noperm" car tous les fichiers étaient indiqués à tort comme non lisibles et non en écriture par le propriétaire.

Même problème avec la Fritzbox 7490: erreur de montage (112): l'hôte est en panne

Je n'ai pas utilisé -o vers = XX. Aussi vite qu'un requin que je suis, j'ai d'abord essayé -o vers = 2.0 et j'ai échoué.
Dès que j'ai utilisé l'option -o vers = 1.0 , tout fonctionne bien!

Cela fonctionne pour moi ..

 sudo mount -t cifs -o rw,username=myname_on_the_box,pass\word=mypasswd_on_the_box,vers=1.0 //192.168.1.1/Fritz-nas /media/something/something    

Mon env:
Client: Ubuntu 17.10 Linux 4.13.0-17-generic # 20-Ubuntu SMP x86_64
Serveur GNU / Linux : Fritzbox 7490 firmware 6.83.

La version SMB1 du protocole est obsolète. Cependant, il s'agit de la version par défaut utilisée dans les anciennes versions de mount.cifs, par exemple, le problème est lié à la version 6.2.

Vous pouvez vérifier avec: sudo mount.cifs --version

Si vous essayez de vous connecter à un serveur SMB3 à l'aide du protocole SMB1, vous obtenez l' Host is downerreur.

La solution de contournement, décrite par de nombreuses autres réponses ici, consiste à spécifier une version différente du protocole. La commande suivante fonctionne pour moi: sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0

Toutefois , si le serveur que vous connectez à utilise DFS, alors vous obtiendrez l'erreur suivante à la place: mount error(38): Function not implemented. En effet, la prise en charge de DFS sur SMB3 n’a été ajoutée au noyau que dans la version 4.11 .

Vous pouvez vérifier la version de votre noyau avec uname -a. Dans mon cas, il était 3.10 sur CentOS7. J'ai suivi ces instructions pour mettre à niveau et maintenant cela fonctionne.

Si vous rencontrez ce problème avec un Synology NAS, vérifiez que l' vers=option spécifiée pour mountet les versions SMB min / max sur le NAS sont compatibles.

Plus précisément, j'utilise vers=2.0, mais mon Synology Diskstation a déclenché l' Host is downerreur. J'ai trouvé une page, l' accès Windows 10 au partage NAS. SMB 1.0 et 3.0 , sur le site Web de Synology, expliquant comment configurer Diskstation pour autoriser SMB v2.0 ou plus récent ...

Sur le Synology NAS

• Allez dans le Panneau de configuration -> Services de fichiers
• Dans l'onglet SMB / AFP / NFS, sélectionnez Paramètres avancés.
• Modifier le protocole SMB maximum en SMB3
• Changez le protocole SMB de Minumum en SMB2 (la page dit d’utiliser SMB2 avec un grand MTU, mais cela ne m’a pas fonctionné)

J'utilise généralement ce type de commande pour monter un partage cifs / smb.

mount -t cifs -o rw,netbiosname=nasserver1,credentials=/etc/user_credentials.txt //192.168.1.11/someshare /mnt

le fichier de références ressemble à ceci:

username=mydomain\user1
password=somepass

Ceci peut également être adapté à une configuration de montage automatique afin que le montage / démontage puisse être géré automatiquement par le système via autofs.

Dans notre cas, j’ai vérifié le nom de connexion de l’utilisateur (utilisateur2) dans l’AD. Là, j'ai remarqué que le nom commençait par une lettre majuscule et je l'ai changé en minuscule, comme il est écrit dans le script de montage. Même si nous n’avions jamais touché à user2 ni au script de montage auparavant, la commande de montage a réussi.

mount --verbose -t cifs //pc/share /my-share -no user=user1,password=pw1 -o uid=user2,gid=group1,dir_mode=0775,file_mode=0664

Pour moi, le partage cifs monté se trouvait sur un serveur Windows dont l'adresse IP avait changé récemment. Je pouvais donc envoyer une requête ping au serveur et résoudre sa nouvelle adresse, mais le montage ne s'était pas mis à jour. En exécutant un démontage paresseux, puis en remontant le problème, mon problème a été résolu:

umount -l /mnt/share
mount -a

Je viens également de rencontrer le problème mentionné après une mise à niveau vers Xubuntu 17.10. J'utilise un Synology DiskStation. Ce que j’ai vu là-bas: sur le DiskStation, vous pouvez choisir les protocoles à prendre en charge. En ajoutant les protocoles pertinents (jusqu'à SBM3) dans les options avancées pour les services de fichiers du panneau de configuration, vous pouvez également résoudre le problème.

Avait un problème similaire. La solution pour moi était du côté du serveur de partage Windows. Même en passant la valeur vers = 2.0 à mon serveur Linux, le montage ne fonctionnait pas. Je devais donc activer sur mon serveur Windows le support smbv1. Cet article m'a aidé: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and