Mount CIFS Host is downmount error 5 = Input/output errorUnable to mount XP share using fs-cifs from LinuxCannot unmount CIFS mount?Issue with mount.cifs in Ubuntu [while accessing Windows samba share using a localServerUser]Mount a samba share as regular user using cifsHow to set permissions for a CIFS mount with autofs?CIFS error -512 on a mountCifs mount hanging“Mount error 13” on CIFS connection w/o Domain AdminCIFS VFS: BAD_NETWORK_NAME on Linux

Does the Aboleth have expertise in History and Perception?

Why is there no current between two capacitors connected in series?

Schwa-less Polysyllabic German Noun Stems of Germanic Origin

400–430 degrees Celsius heated bath

1950s or earlier book with electrical currents living on Pluto

Why did Nick Fury not hesitate in blowing up the plane he thought was carrying a nuke?

Differential of a one-form eating a vector?

Why was Harry at the Weasley's at the beginning of Goblet of Fire but at the Dursleys' after?

What does it mean to "take the Cross"

What to call a small, open stone or cement reservoir that supplies fresh water from a spring or other natural source?

Why is こと used in 「私に何かできること」?

What is metrics.roc_curve and metrics.auc measuring when I'm comparing binary data with probability estimates?

How to say "invitation for war"?

Old robot movie with robots in cages being hurt at a carnival show

No Active Recurring Contributions on civi record but stripe has the data. Is there a way to resend IPN?

How is dynamic resistance of a diode modeled for large voltage variations?

Will this series of events work to drown the Tarrasque?

How to say "they didn't leave him a penny"?

What city and town structures are important in a low fantasy medieval world?

Parse a C++14 integer literal

How to use Screen Sharing if I don't know the remote Mac's IP address

tikz: 5 squares on a row, roman numbered 1 -> 5

Expand a hexagon

Vehemently against code formatting



Mount CIFS Host is down


mount error 5 = Input/output errorUnable to mount XP share using fs-cifs from LinuxCannot unmount CIFS mount?Issue with mount.cifs in Ubuntu [while accessing Windows samba share using a localServerUser]Mount a samba share as regular user using cifsHow to set permissions for a CIFS mount with autofs?CIFS error -512 on a mountCifs mount hanging“Mount error 13” on CIFS connection w/o Domain AdminCIFS VFS: BAD_NETWORK_NAME on Linux






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








83















I have an issue with a mount point that was previously configured. It shows the folder, but the mount is missing and holds "?" values for size, permissions, etc.



So I tried to remount using cifs and the same command from before:



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


But I get the error:



Host is down.


If I ping the domain or IP I get a proper resolution and I also connected using smbclient without issue



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


I looked around, but cant find a solid answer. Any thoughts?










share|improve this question
























  • do a nslookup nas.domain.local does it equal the ip you pinged?

    – tony roth
    Aug 3 '12 at 17:19











  • Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

    – Kevin
    Aug 3 '12 at 17:28






  • 6





    Add the --verbose switch to your mount command, post any errors/results that seem relevant.

    – Zoredache
    Aug 3 '12 at 17:55











  • Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

    – Jay
    Aug 6 '12 at 22:06






  • 1





    @Zoredache Add -vvv for even more verbose information!

    – Serge Stroobandt
    Apr 23 '15 at 17:36


















83















I have an issue with a mount point that was previously configured. It shows the folder, but the mount is missing and holds "?" values for size, permissions, etc.



So I tried to remount using cifs and the same command from before:



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


But I get the error:



Host is down.


If I ping the domain or IP I get a proper resolution and I also connected using smbclient without issue



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


I looked around, but cant find a solid answer. Any thoughts?










share|improve this question
























  • do a nslookup nas.domain.local does it equal the ip you pinged?

    – tony roth
    Aug 3 '12 at 17:19











  • Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

    – Kevin
    Aug 3 '12 at 17:28






  • 6





    Add the --verbose switch to your mount command, post any errors/results that seem relevant.

    – Zoredache
    Aug 3 '12 at 17:55











  • Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

    – Jay
    Aug 6 '12 at 22:06






  • 1





    @Zoredache Add -vvv for even more verbose information!

    – Serge Stroobandt
    Apr 23 '15 at 17:36














83












83








83


29






I have an issue with a mount point that was previously configured. It shows the folder, but the mount is missing and holds "?" values for size, permissions, etc.



So I tried to remount using cifs and the same command from before:



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


But I get the error:



Host is down.


If I ping the domain or IP I get a proper resolution and I also connected using smbclient without issue



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


I looked around, but cant find a solid answer. Any thoughts?










share|improve this question
















I have an issue with a mount point that was previously configured. It shows the folder, but the mount is missing and holds "?" values for size, permissions, etc.



So I tried to remount using cifs and the same command from before:



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


But I get the error:



Host is down.


If I ping the domain or IP I get a proper resolution and I also connected using smbclient without issue



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


I looked around, but cant find a solid answer. Any thoughts?







linux centos mount cifs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 21 '12 at 21:17







Kevin

















asked Aug 3 '12 at 17:13









KevinKevin

533168




533168












  • do a nslookup nas.domain.local does it equal the ip you pinged?

    – tony roth
    Aug 3 '12 at 17:19











  • Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

    – Kevin
    Aug 3 '12 at 17:28






  • 6





    Add the --verbose switch to your mount command, post any errors/results that seem relevant.

    – Zoredache
    Aug 3 '12 at 17:55











  • Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

    – Jay
    Aug 6 '12 at 22:06






  • 1





    @Zoredache Add -vvv for even more verbose information!

    – Serge Stroobandt
    Apr 23 '15 at 17:36


















  • do a nslookup nas.domain.local does it equal the ip you pinged?

    – tony roth
    Aug 3 '12 at 17:19











  • Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

    – Kevin
    Aug 3 '12 at 17:28






  • 6





    Add the --verbose switch to your mount command, post any errors/results that seem relevant.

    – Zoredache
    Aug 3 '12 at 17:55











  • Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

    – Jay
    Aug 6 '12 at 22:06






  • 1





    @Zoredache Add -vvv for even more verbose information!

    – Serge Stroobandt
    Apr 23 '15 at 17:36

















do a nslookup nas.domain.local does it equal the ip you pinged?

– tony roth
Aug 3 '12 at 17:19





do a nslookup nas.domain.local does it equal the ip you pinged?

– tony roth
Aug 3 '12 at 17:19













Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

– Kevin
Aug 3 '12 at 17:28





Yes, the IP returned is accurate. I can access the web interface of the NAS using the IP and domain as well. I can access the data on my laptop using either the domain or IP so it seems there is some other issue at play here

– Kevin
Aug 3 '12 at 17:28




6




6





Add the --verbose switch to your mount command, post any errors/results that seem relevant.

– Zoredache
Aug 3 '12 at 17:55





Add the --verbose switch to your mount command, post any errors/results that seem relevant.

– Zoredache
Aug 3 '12 at 17:55













Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

– Jay
Aug 6 '12 at 22:06





Is the service even running on the remote server. It is a Linux or Windows Server? If it is Linux... verify that the service is running. Make sure no changes have been done to the firewall... If it is windows... then you might consider a reboot...

– Jay
Aug 6 '12 at 22:06




1




1





@Zoredache Add -vvv for even more verbose information!

– Serge Stroobandt
Apr 23 '15 at 17:36






@Zoredache Add -vvv for even more verbose information!

– Serge Stroobandt
Apr 23 '15 at 17:36











14 Answers
14






active

oldest

votes


















95














This could also be because of a protocol mismatch.
In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.



From now on, mount.cifs might have problems with the protocol negotiation.



The error displayed is "Host is down.", but when you do debug with:



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


you will get the error:



protocol negotiation failed: NT_STATUS_CONNECTION_RESET


To overcome this use mount or smbclient with a protocol specified.



for smbclient: add -m SMB2 (or SMB3 for the newer version of the protocol)



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


or for mount: add vers=2.0 (or vers=3.0 if you want to use version 3 of the protocol)



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





share|improve this answer

























  • My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

    – Olivier Pons
    Jan 12 '18 at 10:51






  • 3





    Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

    – Marcin P
    Jan 13 '18 at 11:47







  • 10





    Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

    – Hubro
    Feb 6 '18 at 5:39











  • Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

    – Andrew Savinykh
    May 1 '18 at 22:28











  • In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

    – PRIHLOP
    Apr 18 at 11:52


















41














On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.



CIFS in linux kernel 4.13 now defaults to SMB 3.0 and in kernel 4.14 it tries 2.1 and higher. See this change log.






share|improve this answer

























  • Thanks, I had the same issue however I don't know which upgrade makes this necessary.

    – Ben
    Oct 6 '17 at 18:54











  • This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

    – jPlatte
    Oct 9 '17 at 11:27







  • 2





    I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

    – Neek
    Nov 1 '17 at 6:41







  • 1





    I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

    – YoungFrog
    Oct 31 '18 at 12:56


















12














USB-stick at Fritz NAS showed "Host Down" for Ubuntu 17.10:



Defining the version (vers=1.0) worked - here's the full string:



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>





share|improve this answer




















  • 2





    Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

    – equivalent8
    Jan 12 '18 at 13:02


















6














Similar problem after upgrade to ubuntu 17.10, with an old Buffalo Diskstation. Solved by adding in /etc/fstab the "vers=1.0" option:



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






share|improve this answer

























  • Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

    – Geppettvs D'Constanzo
    May 26 '18 at 22:04











  • I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

    – Ben
    Jul 9 '18 at 18:01


















5














Sorry if this is a late response (I realise it's an old thread), however I have just discovered there is another possible reason why mount.cifs would say the host is down.



I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.
Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.






share|improve this answer























  • Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

    – Antonio Vinicius Menezes Medei
    Sep 12 '16 at 13:44











  • My NAS is on Linux so I still have this problem, but thanks for sharing

    – Olivier Pons
    Jan 12 '18 at 10:48


















4














I received the same error without further ado from a new Samba client, when trying to mount a CIFS SMB network share:



mount error(112): Host is down


Eventually, it turned out I had previously restricted SMB server access to only a limited number of IP addresses by configuring /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


Adding the fixed IP address of the new SMB client solved the issue in this specific case.



Of course, there is a myriad of other reasons why one may receive above-mentioned error.






share|improve this answer






























    2














    Same trouble with Fritzbox 7490: mount error(112): Host is down



    I didn't used -o vers=XX.
    As fast as a shark i am, i first tried -o vers=2.0 and failed.

    As soon as i used the option -o vers=1.0, everything works fine !



    This works for me..



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


    My env:

    Client: Ubuntu 17.10 Linux 4.13.0-17-generic #20-Ubuntu SMP x86_64 GNU/Linux

    Server: Fritzbox 7490 firmware 6.83.






    share|improve this answer























    • AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

      – 0xC0000022L
      Jul 30 '18 at 21:09


















    2














    Same trouble connecting to Synology DiskStation (DSM 4.3).



    Using vers=1.0 in the mount options works fine.



    Additionally I had to use the option "noperm" because all files wrongly showed as not readable and writable by the owner.






    share|improve this answer






























      2














      The SMB1 version of the protocol has been deprecated, however this is the default version used in older versions of mount.cifs, e.g. I have this problem with version 6.2.



      You can check with:

      sudo mount.cifs --version



      If you try to connect to an SMB3 server using SMB1 protocol, you get the Host is down error.



      The workaround, as described by many other answers here, is to specify a different version of the protocol. The following command works for me:

      sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0



      However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.



      You can check your kernel version with uname -a. In my case, it was 3.10 on CentOS7. I followed these instructions to upgrade and now it works.






      share|improve this answer






























        0














        I typically use this type of command to mount a cifs/smb share.



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


        the credentials file looks like so:



        username=mydomainuser1
        password=somepass


        This can also be adapted to an automount setup so the mounting/unmounting can be handled by the system automatically via autofs.






        share|improve this answer






























          0














          In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.



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





          share|improve this answer






























            0














            For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:



            umount -l /mnt/share
            mount -a





            share|improve this answer






























              0














              I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.
              What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.






              share|improve this answer






























                -4














                Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and






                share|improve this answer


















                • 4





                  Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                  – Andrew Schulman
                  Feb 2 '18 at 2:08









                protected by Sven Mar 3 at 9:44



                Thank you for your interest in this question.
                Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                Would you like to answer one of these unanswered questions instead?














                14 Answers
                14






                active

                oldest

                votes








                14 Answers
                14






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes









                95














                This could also be because of a protocol mismatch.
                In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.



                From now on, mount.cifs might have problems with the protocol negotiation.



                The error displayed is "Host is down.", but when you do debug with:



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


                you will get the error:



                protocol negotiation failed: NT_STATUS_CONNECTION_RESET


                To overcome this use mount or smbclient with a protocol specified.



                for smbclient: add -m SMB2 (or SMB3 for the newer version of the protocol)



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


                or for mount: add vers=2.0 (or vers=3.0 if you want to use version 3 of the protocol)



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





                share|improve this answer

























                • My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                  – Olivier Pons
                  Jan 12 '18 at 10:51






                • 3





                  Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                  – Marcin P
                  Jan 13 '18 at 11:47







                • 10





                  Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                  – Hubro
                  Feb 6 '18 at 5:39











                • Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                  – Andrew Savinykh
                  May 1 '18 at 22:28











                • In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                  – PRIHLOP
                  Apr 18 at 11:52















                95














                This could also be because of a protocol mismatch.
                In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.



                From now on, mount.cifs might have problems with the protocol negotiation.



                The error displayed is "Host is down.", but when you do debug with:



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


                you will get the error:



                protocol negotiation failed: NT_STATUS_CONNECTION_RESET


                To overcome this use mount or smbclient with a protocol specified.



                for smbclient: add -m SMB2 (or SMB3 for the newer version of the protocol)



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


                or for mount: add vers=2.0 (or vers=3.0 if you want to use version 3 of the protocol)



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





                share|improve this answer

























                • My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                  – Olivier Pons
                  Jan 12 '18 at 10:51






                • 3





                  Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                  – Marcin P
                  Jan 13 '18 at 11:47







                • 10





                  Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                  – Hubro
                  Feb 6 '18 at 5:39











                • Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                  – Andrew Savinykh
                  May 1 '18 at 22:28











                • In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                  – PRIHLOP
                  Apr 18 at 11:52













                95












                95








                95







                This could also be because of a protocol mismatch.
                In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.



                From now on, mount.cifs might have problems with the protocol negotiation.



                The error displayed is "Host is down.", but when you do debug with:



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


                you will get the error:



                protocol negotiation failed: NT_STATUS_CONNECTION_RESET


                To overcome this use mount or smbclient with a protocol specified.



                for smbclient: add -m SMB2 (or SMB3 for the newer version of the protocol)



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


                or for mount: add vers=2.0 (or vers=3.0 if you want to use version 3 of the protocol)



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





                share|improve this answer















                This could also be because of a protocol mismatch.
                In 2017 Microsoft patched Windows Servers and advised to disable the SMB1 protocol.



                From now on, mount.cifs might have problems with the protocol negotiation.



                The error displayed is "Host is down.", but when you do debug with:



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


                you will get the error:



                protocol negotiation failed: NT_STATUS_CONNECTION_RESET


                To overcome this use mount or smbclient with a protocol specified.



                for smbclient: add -m SMB2 (or SMB3 for the newer version of the protocol)



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


                or for mount: add vers=2.0 (or vers=3.0 if you want to use version 3 of the protocol)



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






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited May 7 at 15:33









                Ankur Gupta

                1032




                1032










                answered Apr 5 '17 at 8:30









                Marcin PMarcin P

                1,05845




                1,05845












                • My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                  – Olivier Pons
                  Jan 12 '18 at 10:51






                • 3





                  Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                  – Marcin P
                  Jan 13 '18 at 11:47







                • 10





                  Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                  – Hubro
                  Feb 6 '18 at 5:39











                • Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                  – Andrew Savinykh
                  May 1 '18 at 22:28











                • In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                  – PRIHLOP
                  Apr 18 at 11:52

















                • My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                  – Olivier Pons
                  Jan 12 '18 at 10:51






                • 3





                  Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                  – Marcin P
                  Jan 13 '18 at 11:47







                • 10





                  Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                  – Hubro
                  Feb 6 '18 at 5:39











                • Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                  – Andrew Savinykh
                  May 1 '18 at 22:28











                • In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                  – PRIHLOP
                  Apr 18 at 11:52
















                My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                – Olivier Pons
                Jan 12 '18 at 10:51





                My NAS is on Linux when I try your solution smbclient -L 192.168.1.47 -U admin -d 256 everything works perfectly but when I try mount -t cifs -o username=aa,password=bb,uid=olivier //192.168.1.47/partagefichiers/ /mnt/PartageFichiers it keeps saying mount error(112): Host is down

                – Olivier Pons
                Jan 12 '18 at 10:51




                3




                3





                Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                – Marcin P
                Jan 13 '18 at 11:47






                Have you tried to specify protocol as I explainde in this answer? Try adding vers=2.0 or vers=3.0 or vers=1.0 (depending on this NAS settings) by adding: mount -t cifs -o username=aa,password=bb,uid=olivier,vers=2.0 //192.168.1.47/partagefichiers/ /mnt/PartageFichiers

                – Marcin P
                Jan 13 '18 at 11:47





                10




                10





                Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                – Hubro
                Feb 6 '18 at 5:39





                Strange. The man page says that vers=1.0 is the default, but I couldn't get my network drive to mount before I explicitly passed vers=1.0.

                – Hubro
                Feb 6 '18 at 5:39













                Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                – Andrew Savinykh
                May 1 '18 at 22:28





                Is it possible to change that on windows side? I have a piece of software that forwards this options to cifs and it does not know the vers option so it is not forwarded.

                – Andrew Savinykh
                May 1 '18 at 22:28













                In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                – PRIHLOP
                Apr 18 at 11:52





                In fstab file it will be like that //<server_ip>/<share> /media/<mountpoint> cifs username=<username>,password=<password>,iocharset=utf8,sec=ntlm,vers=1.0 0 0

                – PRIHLOP
                Apr 18 at 11:52













                41














                On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.



                CIFS in linux kernel 4.13 now defaults to SMB 3.0 and in kernel 4.14 it tries 2.1 and higher. See this change log.






                share|improve this answer

























                • Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                  – Ben
                  Oct 6 '17 at 18:54











                • This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                  – jPlatte
                  Oct 9 '17 at 11:27







                • 2





                  I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                  – Neek
                  Nov 1 '17 at 6:41







                • 1





                  I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                  – YoungFrog
                  Oct 31 '18 at 12:56















                41














                On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.



                CIFS in linux kernel 4.13 now defaults to SMB 3.0 and in kernel 4.14 it tries 2.1 and higher. See this change log.






                share|improve this answer

























                • Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                  – Ben
                  Oct 6 '17 at 18:54











                • This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                  – jPlatte
                  Oct 9 '17 at 11:27







                • 2





                  I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                  – Neek
                  Nov 1 '17 at 6:41







                • 1





                  I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                  – YoungFrog
                  Oct 31 '18 at 12:56













                41












                41








                41







                On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.



                CIFS in linux kernel 4.13 now defaults to SMB 3.0 and in kernel 4.14 it tries 2.1 and higher. See this change log.






                share|improve this answer















                On archlinux after a recent package update, I had to add vers=1.0 to my mount options. I'm connecting to an old centos 5 box and up until yesterday I could connect without explicitly stating a version number.



                CIFS in linux kernel 4.13 now defaults to SMB 3.0 and in kernel 4.14 it tries 2.1 and higher. See this change log.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Feb 26 at 11:21









                J Smith

                32




                32










                answered Oct 6 '17 at 7:51









                Sjoerd TimmerSjoerd Timmer

                51132




                51132












                • Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                  – Ben
                  Oct 6 '17 at 18:54











                • This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                  – jPlatte
                  Oct 9 '17 at 11:27







                • 2





                  I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                  – Neek
                  Nov 1 '17 at 6:41







                • 1





                  I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                  – YoungFrog
                  Oct 31 '18 at 12:56

















                • Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                  – Ben
                  Oct 6 '17 at 18:54











                • This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                  – jPlatte
                  Oct 9 '17 at 11:27







                • 2





                  I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                  – Neek
                  Nov 1 '17 at 6:41







                • 1





                  I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                  – YoungFrog
                  Oct 31 '18 at 12:56
















                Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                – Ben
                Oct 6 '17 at 18:54





                Thanks, I had the same issue however I don't know which upgrade makes this necessary.

                – Ben
                Oct 6 '17 at 18:54













                This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                – jPlatte
                Oct 9 '17 at 11:27






                This is a really weird problem. Same thing happened to me today. I tried downgrading smbclient and libwbclient, but the problem persisted. Maybe something on the server changed. I think it's CentOS too, I hope not CentOS 5! Thanks for the workaround :)

                – jPlatte
                Oct 9 '17 at 11:27





                2




                2





                I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                – Neek
                Nov 1 '17 at 6:41






                I had to do this for my Fedora 26 system accessing a mount on my Synology NAS DS413j, my /etc/fstab now has ",vers=1.0" on the end of the options string and no more 'Host is down' error message.

                – Neek
                Nov 1 '17 at 6:41





                1




                1





                I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                – YoungFrog
                Oct 31 '18 at 12:56





                I had an upgrade from Ubuntu 16.04 to 18.04 (LTS) which broke my mounts of a Lacie NAS. This did the trick for me.

                – YoungFrog
                Oct 31 '18 at 12:56











                12














                USB-stick at Fritz NAS showed "Host Down" for Ubuntu 17.10:



                Defining the version (vers=1.0) worked - here's the full string:



                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>





                share|improve this answer




















                • 2





                  Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                  – equivalent8
                  Jan 12 '18 at 13:02















                12














                USB-stick at Fritz NAS showed "Host Down" for Ubuntu 17.10:



                Defining the version (vers=1.0) worked - here's the full string:



                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>





                share|improve this answer




















                • 2





                  Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                  – equivalent8
                  Jan 12 '18 at 13:02













                12












                12








                12







                USB-stick at Fritz NAS showed "Host Down" for Ubuntu 17.10:



                Defining the version (vers=1.0) worked - here's the full string:



                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>





                share|improve this answer















                USB-stick at Fritz NAS showed "Host Down" for Ubuntu 17.10:



                Defining the version (vers=1.0) worked - here's the full string:



                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>






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 22 '17 at 19:15









                Mike Fiedler

                1,94311528




                1,94311528










                answered Dec 22 '17 at 10:16









                user449376user449376

                12112




                12112







                • 2





                  Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                  – equivalent8
                  Jan 12 '18 at 13:02












                • 2





                  Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                  – equivalent8
                  Jan 12 '18 at 13:02







                2




                2





                Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                – equivalent8
                Jan 12 '18 at 13:02





                Everything was working from within /etc/fstab cifs mount; after apt upgrade on my Ubuntu 16.04 this happened. Specifying the -o vers=1.0 did the trick. Thank you

                – equivalent8
                Jan 12 '18 at 13:02











                6














                Similar problem after upgrade to ubuntu 17.10, with an old Buffalo Diskstation. Solved by adding in /etc/fstab the "vers=1.0" option:



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






                share|improve this answer

























                • Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                  – Geppettvs D'Constanzo
                  May 26 '18 at 22:04











                • I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                  – Ben
                  Jul 9 '18 at 18:01















                6














                Similar problem after upgrade to ubuntu 17.10, with an old Buffalo Diskstation. Solved by adding in /etc/fstab the "vers=1.0" option:



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






                share|improve this answer

























                • Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                  – Geppettvs D'Constanzo
                  May 26 '18 at 22:04











                • I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                  – Ben
                  Jul 9 '18 at 18:01













                6












                6








                6







                Similar problem after upgrade to ubuntu 17.10, with an old Buffalo Diskstation. Solved by adding in /etc/fstab the "vers=1.0" option:



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






                share|improve this answer















                Similar problem after upgrade to ubuntu 17.10, with an old Buffalo Diskstation. Solved by adding in /etc/fstab the "vers=1.0" option:



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







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 4 '18 at 15:15

























                answered Mar 4 '18 at 14:12









                PatricePatrice

                6112




                6112












                • Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                  – Geppettvs D'Constanzo
                  May 26 '18 at 22:04











                • I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                  – Ben
                  Jul 9 '18 at 18:01

















                • Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                  – Geppettvs D'Constanzo
                  May 26 '18 at 22:04











                • I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                  – Ben
                  Jul 9 '18 at 18:01
















                Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                – Geppettvs D'Constanzo
                May 26 '18 at 22:04





                Anybody using Ubuntu 18.04, adding the ,vers=1.0 option solves the problem when using the tutorial provided by Ji m at ubuntuhandbook.org/index.php/2014/08/…

                – Geppettvs D'Constanzo
                May 26 '18 at 22:04













                I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                – Ben
                Jul 9 '18 at 18:01





                I have the same problem and can solve it by using version 1 in the protocoll. But I have a very low rate of transmission of data. I suspect it might be due to version 1, so using another version would be better.

                – Ben
                Jul 9 '18 at 18:01











                5














                Sorry if this is a late response (I realise it's an old thread), however I have just discovered there is another possible reason why mount.cifs would say the host is down.



                I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.
                Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.






                share|improve this answer























                • Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                  – Antonio Vinicius Menezes Medei
                  Sep 12 '16 at 13:44











                • My NAS is on Linux so I still have this problem, but thanks for sharing

                  – Olivier Pons
                  Jan 12 '18 at 10:48















                5














                Sorry if this is a late response (I realise it's an old thread), however I have just discovered there is another possible reason why mount.cifs would say the host is down.



                I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.
                Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.






                share|improve this answer























                • Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                  – Antonio Vinicius Menezes Medei
                  Sep 12 '16 at 13:44











                • My NAS is on Linux so I still have this problem, but thanks for sharing

                  – Olivier Pons
                  Jan 12 '18 at 10:48













                5












                5








                5







                Sorry if this is a late response (I realise it's an old thread), however I have just discovered there is another possible reason why mount.cifs would say the host is down.



                I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.
                Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.






                share|improve this answer













                Sorry if this is a late response (I realise it's an old thread), however I have just discovered there is another possible reason why mount.cifs would say the host is down.



                I have an antivirus with a firewall and even though I set it explicitly to allow "windows file and print sharing" -- a predefined rule, it was still blocking connections. I had that proven by disabling the firewall temporarily.
                Hope this helps someone, host is down might not mean it's not responding to pings, but could mean it's not responding to authentication attempts.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 28 '13 at 22:48









                lolinuxlolinux

                5113




                5113












                • Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                  – Antonio Vinicius Menezes Medei
                  Sep 12 '16 at 13:44











                • My NAS is on Linux so I still have this problem, but thanks for sharing

                  – Olivier Pons
                  Jan 12 '18 at 10:48

















                • Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                  – Antonio Vinicius Menezes Medei
                  Sep 12 '16 at 13:44











                • My NAS is on Linux so I still have this problem, but thanks for sharing

                  – Olivier Pons
                  Jan 12 '18 at 10:48
















                Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                – Antonio Vinicius Menezes Medei
                Sep 12 '16 at 13:44





                Remember to check the firewall in both sides: client and server (as well as any firewall that might there be in the way between them). In my case, it was the client's firewall that was blocking connections to the server. I had to add iptables rules to allow them: iptables -A INPUT -s 1.2.3.4/32 -j ACCEPT and iptables -A OUTPUT -d 1.2.3.4/32 -j ACCEPT, where 1.2.3.4 was the server's IP address.

                – Antonio Vinicius Menezes Medei
                Sep 12 '16 at 13:44













                My NAS is on Linux so I still have this problem, but thanks for sharing

                – Olivier Pons
                Jan 12 '18 at 10:48





                My NAS is on Linux so I still have this problem, but thanks for sharing

                – Olivier Pons
                Jan 12 '18 at 10:48











                4














                I received the same error without further ado from a new Samba client, when trying to mount a CIFS SMB network share:



                mount error(112): Host is down


                Eventually, it turned out I had previously restricted SMB server access to only a limited number of IP addresses by configuring /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


                Adding the fixed IP address of the new SMB client solved the issue in this specific case.



                Of course, there is a myriad of other reasons why one may receive above-mentioned error.






                share|improve this answer



























                  4














                  I received the same error without further ado from a new Samba client, when trying to mount a CIFS SMB network share:



                  mount error(112): Host is down


                  Eventually, it turned out I had previously restricted SMB server access to only a limited number of IP addresses by configuring /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


                  Adding the fixed IP address of the new SMB client solved the issue in this specific case.



                  Of course, there is a myriad of other reasons why one may receive above-mentioned error.






                  share|improve this answer

























                    4












                    4








                    4







                    I received the same error without further ado from a new Samba client, when trying to mount a CIFS SMB network share:



                    mount error(112): Host is down


                    Eventually, it turned out I had previously restricted SMB server access to only a limited number of IP addresses by configuring /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


                    Adding the fixed IP address of the new SMB client solved the issue in this specific case.



                    Of course, there is a myriad of other reasons why one may receive above-mentioned error.






                    share|improve this answer













                    I received the same error without further ado from a new Samba client, when trying to mount a CIFS SMB network share:



                    mount error(112): Host is down


                    Eventually, it turned out I had previously restricted SMB server access to only a limited number of IP addresses by configuring /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


                    Adding the fixed IP address of the new SMB client solved the issue in this specific case.



                    Of course, there is a myriad of other reasons why one may receive above-mentioned error.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Apr 23 '15 at 21:47









                    Serge StroobandtSerge Stroobandt

                    174211




                    174211





















                        2














                        Same trouble with Fritzbox 7490: mount error(112): Host is down



                        I didn't used -o vers=XX.
                        As fast as a shark i am, i first tried -o vers=2.0 and failed.

                        As soon as i used the option -o vers=1.0, everything works fine !



                        This works for me..



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


                        My env:

                        Client: Ubuntu 17.10 Linux 4.13.0-17-generic #20-Ubuntu SMP x86_64 GNU/Linux

                        Server: Fritzbox 7490 firmware 6.83.






                        share|improve this answer























                        • AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                          – 0xC0000022L
                          Jul 30 '18 at 21:09















                        2














                        Same trouble with Fritzbox 7490: mount error(112): Host is down



                        I didn't used -o vers=XX.
                        As fast as a shark i am, i first tried -o vers=2.0 and failed.

                        As soon as i used the option -o vers=1.0, everything works fine !



                        This works for me..



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


                        My env:

                        Client: Ubuntu 17.10 Linux 4.13.0-17-generic #20-Ubuntu SMP x86_64 GNU/Linux

                        Server: Fritzbox 7490 firmware 6.83.






                        share|improve this answer























                        • AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                          – 0xC0000022L
                          Jul 30 '18 at 21:09













                        2












                        2








                        2







                        Same trouble with Fritzbox 7490: mount error(112): Host is down



                        I didn't used -o vers=XX.
                        As fast as a shark i am, i first tried -o vers=2.0 and failed.

                        As soon as i used the option -o vers=1.0, everything works fine !



                        This works for me..



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


                        My env:

                        Client: Ubuntu 17.10 Linux 4.13.0-17-generic #20-Ubuntu SMP x86_64 GNU/Linux

                        Server: Fritzbox 7490 firmware 6.83.






                        share|improve this answer













                        Same trouble with Fritzbox 7490: mount error(112): Host is down



                        I didn't used -o vers=XX.
                        As fast as a shark i am, i first tried -o vers=2.0 and failed.

                        As soon as i used the option -o vers=1.0, everything works fine !



                        This works for me..



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


                        My env:

                        Client: Ubuntu 17.10 Linux 4.13.0-17-generic #20-Ubuntu SMP x86_64 GNU/Linux

                        Server: Fritzbox 7490 firmware 6.83.







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Nov 30 '17 at 11:53









                        d.dieckertd.dieckert

                        211




                        211












                        • AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                          – 0xC0000022L
                          Jul 30 '18 at 21:09

















                        • AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                          – 0xC0000022L
                          Jul 30 '18 at 21:09
















                        AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                        – 0xC0000022L
                        Jul 30 '18 at 21:09





                        AVM uses an outdated version of Samba that they maintain themselves. That probably explains why one has to use vers=1.0 instead of the more appropriate newer protocol versions.

                        – 0xC0000022L
                        Jul 30 '18 at 21:09











                        2














                        Same trouble connecting to Synology DiskStation (DSM 4.3).



                        Using vers=1.0 in the mount options works fine.



                        Additionally I had to use the option "noperm" because all files wrongly showed as not readable and writable by the owner.






                        share|improve this answer



























                          2














                          Same trouble connecting to Synology DiskStation (DSM 4.3).



                          Using vers=1.0 in the mount options works fine.



                          Additionally I had to use the option "noperm" because all files wrongly showed as not readable and writable by the owner.






                          share|improve this answer

























                            2












                            2








                            2







                            Same trouble connecting to Synology DiskStation (DSM 4.3).



                            Using vers=1.0 in the mount options works fine.



                            Additionally I had to use the option "noperm" because all files wrongly showed as not readable and writable by the owner.






                            share|improve this answer













                            Same trouble connecting to Synology DiskStation (DSM 4.3).



                            Using vers=1.0 in the mount options works fine.



                            Additionally I had to use the option "noperm" because all files wrongly showed as not readable and writable by the owner.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Dec 5 '17 at 10:58









                            BernhardBernhard

                            211




                            211





















                                2














                                The SMB1 version of the protocol has been deprecated, however this is the default version used in older versions of mount.cifs, e.g. I have this problem with version 6.2.



                                You can check with:

                                sudo mount.cifs --version



                                If you try to connect to an SMB3 server using SMB1 protocol, you get the Host is down error.



                                The workaround, as described by many other answers here, is to specify a different version of the protocol. The following command works for me:

                                sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0



                                However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.



                                You can check your kernel version with uname -a. In my case, it was 3.10 on CentOS7. I followed these instructions to upgrade and now it works.






                                share|improve this answer



























                                  2














                                  The SMB1 version of the protocol has been deprecated, however this is the default version used in older versions of mount.cifs, e.g. I have this problem with version 6.2.



                                  You can check with:

                                  sudo mount.cifs --version



                                  If you try to connect to an SMB3 server using SMB1 protocol, you get the Host is down error.



                                  The workaround, as described by many other answers here, is to specify a different version of the protocol. The following command works for me:

                                  sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0



                                  However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.



                                  You can check your kernel version with uname -a. In my case, it was 3.10 on CentOS7. I followed these instructions to upgrade and now it works.






                                  share|improve this answer

























                                    2












                                    2








                                    2







                                    The SMB1 version of the protocol has been deprecated, however this is the default version used in older versions of mount.cifs, e.g. I have this problem with version 6.2.



                                    You can check with:

                                    sudo mount.cifs --version



                                    If you try to connect to an SMB3 server using SMB1 protocol, you get the Host is down error.



                                    The workaround, as described by many other answers here, is to specify a different version of the protocol. The following command works for me:

                                    sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0



                                    However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.



                                    You can check your kernel version with uname -a. In my case, it was 3.10 on CentOS7. I followed these instructions to upgrade and now it works.






                                    share|improve this answer













                                    The SMB1 version of the protocol has been deprecated, however this is the default version used in older versions of mount.cifs, e.g. I have this problem with version 6.2.



                                    You can check with:

                                    sudo mount.cifs --version



                                    If you try to connect to an SMB3 server using SMB1 protocol, you get the Host is down error.



                                    The workaround, as described by many other answers here, is to specify a different version of the protocol. The following command works for me:

                                    sudo mount -t cifs //server.name.or.ip/shares/Public /target/directory -o username=someuser,domain=somedomain,vers=3.0



                                    However, if the server that you are connecting to uses DFS, then you will get the following error instead: mount error(38): Function not implemented. This is because DFS support on SMB3 was only added to the kernel in version 4.11.



                                    You can check your kernel version with uname -a. In my case, it was 3.10 on CentOS7. I followed these instructions to upgrade and now it works.







                                    share|improve this answer












                                    share|improve this answer



                                    share|improve this answer










                                    answered Sep 4 '18 at 8:43









                                    Dr John A StevensonDr John A Stevenson

                                    212




                                    212





















                                        0














                                        I typically use this type of command to mount a cifs/smb share.



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


                                        the credentials file looks like so:



                                        username=mydomainuser1
                                        password=somepass


                                        This can also be adapted to an automount setup so the mounting/unmounting can be handled by the system automatically via autofs.






                                        share|improve this answer



























                                          0














                                          I typically use this type of command to mount a cifs/smb share.



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


                                          the credentials file looks like so:



                                          username=mydomainuser1
                                          password=somepass


                                          This can also be adapted to an automount setup so the mounting/unmounting can be handled by the system automatically via autofs.






                                          share|improve this answer

























                                            0












                                            0








                                            0







                                            I typically use this type of command to mount a cifs/smb share.



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


                                            the credentials file looks like so:



                                            username=mydomainuser1
                                            password=somepass


                                            This can also be adapted to an automount setup so the mounting/unmounting can be handled by the system automatically via autofs.






                                            share|improve this answer













                                            I typically use this type of command to mount a cifs/smb share.



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


                                            the credentials file looks like so:



                                            username=mydomainuser1
                                            password=somepass


                                            This can also be adapted to an automount setup so the mounting/unmounting can be handled by the system automatically via autofs.







                                            share|improve this answer












                                            share|improve this answer



                                            share|improve this answer










                                            answered Nov 4 '12 at 7:23









                                            slmslm

                                            5,136124460




                                            5,136124460





















                                                0














                                                In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.



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





                                                share|improve this answer



























                                                  0














                                                  In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.



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





                                                  share|improve this answer

























                                                    0












                                                    0








                                                    0







                                                    In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.



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





                                                    share|improve this answer













                                                    In our case I checked the users login name (of user2) in the AD. There I noticed that the name was starting with an upper case letter and changed it to lower case as it is written in the mount script. Even if we did not touch neither user2 nor the mount script before, suddenly the mount command was successful.



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






                                                    share|improve this answer












                                                    share|improve this answer



                                                    share|improve this answer










                                                    answered Jun 29 '17 at 11:28









                                                    LudwigLudwig

                                                    1614




                                                    1614





















                                                        0














                                                        For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:



                                                        umount -l /mnt/share
                                                        mount -a





                                                        share|improve this answer



























                                                          0














                                                          For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:



                                                          umount -l /mnt/share
                                                          mount -a





                                                          share|improve this answer

























                                                            0












                                                            0








                                                            0







                                                            For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:



                                                            umount -l /mnt/share
                                                            mount -a





                                                            share|improve this answer













                                                            For me, the mounted cifs share was on a Windows server whose IP address had changed recently, so I could ping the server and resolve its new address, but the mount had not updated itself. By running a lazy unmount and then re-mounting my issue was solved:



                                                            umount -l /mnt/share
                                                            mount -a






                                                            share|improve this answer












                                                            share|improve this answer



                                                            share|improve this answer










                                                            answered Nov 28 '17 at 16:06









                                                            Jon.MozleyJon.Mozley

                                                            487




                                                            487





















                                                                0














                                                                I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.
                                                                What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.






                                                                share|improve this answer



























                                                                  0














                                                                  I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.
                                                                  What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.






                                                                  share|improve this answer

























                                                                    0












                                                                    0








                                                                    0







                                                                    I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.
                                                                    What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.






                                                                    share|improve this answer













                                                                    I also just ran into the problem mentioned after an upgrad to Xubuntu 17.10. I use a Synology DiskStation.
                                                                    What I saw there: In the DiskStation, you can choose which protocols to support. By adding he relevant protocols (up to SBM3) in the advanced options for file services in control panel, you can also solve the problem.







                                                                    share|improve this answer












                                                                    share|improve this answer



                                                                    share|improve this answer










                                                                    answered Feb 4 '18 at 3:09









                                                                    Matthias MielkeMatthias Mielke

                                                                    1




                                                                    1





















                                                                        -4














                                                                        Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and






                                                                        share|improve this answer


















                                                                        • 4





                                                                          Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                          – Andrew Schulman
                                                                          Feb 2 '18 at 2:08















                                                                        -4














                                                                        Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and






                                                                        share|improve this answer


















                                                                        • 4





                                                                          Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                          – Andrew Schulman
                                                                          Feb 2 '18 at 2:08













                                                                        -4












                                                                        -4








                                                                        -4







                                                                        Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and






                                                                        share|improve this answer













                                                                        Had a similar problem. The solution for me was on the Windows share server side. Even passing the value vers=2.0 to my Linux server, the mount wasn't working. So I had to enable on my Windows server smbv1 support. This article helped me: https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and







                                                                        share|improve this answer












                                                                        share|improve this answer



                                                                        share|improve this answer










                                                                        answered Feb 2 '18 at 1:42









                                                                        Vinicius FreitasVinicius Freitas

                                                                        1




                                                                        1







                                                                        • 4





                                                                          Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                          – Andrew Schulman
                                                                          Feb 2 '18 at 2:08












                                                                        • 4





                                                                          Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                          – Andrew Schulman
                                                                          Feb 2 '18 at 2:08







                                                                        4




                                                                        4





                                                                        Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                        – Andrew Schulman
                                                                        Feb 2 '18 at 2:08





                                                                        Don't do this. smbv1 is the vector that WannaCry uses to spread and is being phased out everywhere.

                                                                        – Andrew Schulman
                                                                        Feb 2 '18 at 2:08





                                                                        protected by Sven Mar 3 at 9:44



                                                                        Thank you for your interest in this question.
                                                                        Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                                                        Would you like to answer one of these unanswered questions instead?



                                                                        Popular posts from this blog

                                                                        How to write a 12-bar blues melodyI-IV-V blues progressionHow to play the bridges in a standard blues progressionHow does Gdim7 fit in C# minor?question on a certain chord progressionMusicology of Melody12 bar blues, spread rhythm: alternative to 6th chord to avoid finger stretchChord progressions/ Root key/ MelodiesHow to put chords (POP-EDM) under a given lead vocal melody (starting from a good knowledge in music theory)Are there “rules” for improvising with the minor pentatonic scale over 12-bar shuffle?Confusion about blues scale and chords

                                                                        What if the end-user didn't have the required library?What is setup.py?What is a clean, pythonic way to have multiple constructors in Python?What does Ruby have that Python doesn't, and vice versa?What is the reason for having '//' in Python?How do I create a namespace package in Python?How to package shared objects that python modules depend on?setuptools vs. distutils: why is distutils still a thing?Navigation in Windows 10 vs code not going to virtualenv library when the same library is installed at user levelPython create package for local usePackaging a project that uses multiple python versionsWhy is permission denied on pip install except for when “--user” is included at end of command?

                                                                        Esgonzo ibérico Índice Descrición Distribución Hábitat Ameazas Notas Véxase tamén "Acerca dos nomes dos anfibios e réptiles galegos""Chalcides bedriagai"Chalcides bedriagai en Carrascal, L. M. Salvador, A. (Eds). Enciclopedia virtual de los vertebrados españoles. Museo Nacional de Ciencias Naturales, Madrid. España.Fotos