31

I have my CIFS setup in fstab and they are working as they are supposed to on boot. They mount as they should and work for a while. Out of nowhere it seems (could be after unlocking machine etc) I get "Host is down" error trying to access it. I have multiple and they are all down. They are also shared from the same server. At this time i check on a windows computer and an outdated 14.04 machine and they are up and functioning as they are supposed to. After clicking around on the shares in nautilus and getting repeat errors they will just start working again. To access a share that is "down" takes about 2-3min of randomly clicking different mounts and going back to the first one when automagically it shows the data in the mount point.

I do not have this problem on 14.04 machines that have not been updated in a while. All of those machines are fully functional and the CIFS never go "down". On 16.04 they were not a problem until more recently.

I have made sure to update every other day and have cleaned old linux headers (in hind sight i probably should have reverted). I do this because im begging for a fix to just appear but its been weeks of battling CIFS mounts without any solution.

DevinM
  • 423
  • 1
  • 4
  • 6

5 Answers5

38

After many tests adding vers=1.0 in the mount line seems to fix the problem. The mount works now on Ubuntu 17.10 like it did for years on older Ubuntu releases.

Eliah Kagan
  • 116,445
  • 54
  • 318
  • 493
Stéphane PIOTROWSKI
  • 481
  • 1
  • 4
  • 2
  • 3
    After many x 10 tries this is the only solution that worked. `vers=2.0` didn't work. – Olivier Pons Jan 12 '18 at 10:55
  • I don't know about vers=1.0 vs 2.0 or 3.0, and I can't find any mention in the man pages, but this worked for me. – Greg Chabala Feb 01 '18 at 21:33
  • 3
    //192.168.1.222/volume_1 /media/nas cifs username=****,password=****,vers=1.0 – Steven Apr 04 '18 at 18:32
  • @GregChabala: perhaps check out `mount.cifs(8)` i.e. with `man 8 mount.cifs`? With `mount.cifs` version 6.8 (from the `cifs-utils` package) the man page does contain a mentioning of `vers=arg`. – 0xC0000022L Jul 30 '18 at 21:15
  • `vers=1.0` worked in my case. – Sohel Pathan Dec 11 '19 at 09:29
  • If it works with `vers=1.0`, it probably means you have not open the correct SMB ports, they have changed over time: https://wiki.centos.org/HowTos/SetUpSamba . So I guess people who opened the old ports (137, 138, 139) have version 1.0 working and people who opened the 445 port have the version 3.0 working – nraynaud Oct 16 '20 at 02:24
17

I'm facing the same problem. It seems it has something to do with newest Kernel versions and samba.

I've managed to solve this by adding vers=2.0 at mount commands (or a the end of each fstab line)

josepcoves
  • 194
  • 1
  • 2
  • 3
    Could you perhaps try to make this clearer for others? Show the line from your fstab or shell and explain why it helps? – Zanna May 29 '17 at 09:25
  • Hi, I applied this workaround following steps stated at launchpad: https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1687273 – josepcoves May 29 '17 at 13:08
  • I am testing this fix now. So far so good. If its still working by tomorrow i will accept this as the answer. Thanks for the info! – DevinM May 31 '17 at 15:39
  • Doesn't work for me - can you post what you did? How do you tell which version number to use? – hippyjim Nov 16 '17 at 10:27
  • 4
    Since this is the accepted answer it should perhaps mention that trying out the valid values for `vers` would yield the best results, instead of recommending one particular protocol version (which will not work on outdated servers). Start with a high protocol version and go down one by one. If you end up with `vers=1.0` the remote server may have to be upgraded (if possible) or otherwise secured. – 0xC0000022L Jul 30 '18 at 21:17
  • For me, this worked, and `vers=1.0` did not work. – John Walthour Nov 29 '18 at 18:08
  • Note of course, that vers=x.x needs to be added to mount OPTIONS, not the actual end of fstab line. For me fstab entry is `//cifs-serv/share /mtpoint cifs all-options,vers=1.0 0 0` – Gnudiff Nov 15 '19 at 09:17
  • `vers=1.0` worked for me as well. – Sohel Pathan Dec 11 '19 at 09:28
  • I had the same issue after a client update of the cifs-utils to 6.7-2. And basically the solution from josepcoves and user695658 worked for me. But only the value 1.0 for the mount option 'vers' worked for me. It seems like the default value for the param 'vers' is not 1.0 anymore. – stackunderflow Oct 09 '17 at 12:03
8

Others have already hinted at the solution, but it may be worth shortly explaining the reason.

mount.cifs in Ubuntu 16.04 uses the SMB1 protocol by default.

In later versions of mount.cifs, the default SMB version is 2.1 or 3.0.

Current Windows servers do not support the SMB 1.0 protocol anymore, unless specifically configured in their registry to accept it. So by default, they reject connections from clients using the SMB1 protocol. Which leads to the misleading message "Host is down".

But some older systems (most often NASes) do not support protocols 2.1 or 3.

The solution is to tell mount.cifs to use the right protocol to connect to your server, using the vers= option. For example, to connect to a Windows 10 machine:

mount -t cifs ... -o vers=3.0,...

or to an old NAS from Ubuntu 18.04 or later :

mount -t cifs ... -o vers=1.0,...

From man mount.cifs (in Ubuntu 16.04): 

   vers=
       SMB protocol version. Allowed values are:

       ·   1.0 - The classic CIFS/SMBv1 protocol. This is the default.

       ·   2.0 - The SMBv2.002 protocol. This was initially introduced in
           Windows Vista Service Pack 1, and Windows Server 2008. Note
           that the initial release version of Windows Vista spoke a
           slightly different dialect (2.000) that is not supported.

       ·   2.1 - The SMBv2.1 protocol that was introduced in Microsoft
           Windows 7 and Windows Server 2008R2.

       ·   3.0 - The SMBv3.0 protocol that was introduced in Microsoft
           Windows 8 and Windows Server 2012.

       Note too that while this option governs the protocol version used,
       not all features of each version are available.

If you define your mount in /etc/fstab, it might look something like this:

//server/share  /mnt/share  cifs  defaults,vers=3.0,...your_other_options...,nofail,x-systemd.device-timeout=15 0 0
mivk
  • 5,082
  • 1
  • 47
  • 56
  • cifs vers=1.0,credentials=/root/.smbcredentials, worked for me in 18.04 LTS. Including "defaults," in fsatb generated a parse error so deleting that text avoided the error. – graham Mar 19 '19 at 10:21
  • @Graham smb1 is extremely outdated and dangerous. It's also slower. Try to get to at least `vers=2.1` – Joel Coehoorn Apr 10 '19 at 14:17
  • @JoelCoehoorn but vers=1.0 worked whereas the later versions did not... I started at 3 and changed the vers down until 1.0 worked. Since then absolutely no problems. – graham Apr 10 '19 at 16:55
  • @Graham Then you need to fix the host you're connecting to so it supports smb2.1 or later. SMB1.0 is **really bad**. – Joel Coehoorn Apr 10 '19 at 17:00
  • @JoelCoehoorn I followed the advice contained in this thread: https://serverfault.com/questions/414074/mount-cifs-host-is-down to resolve the issue. Just tried vers=3.0 again and the same error persists and the drive does not mount. What is so terrible about vers=1.0 ? – graham Apr 10 '19 at 18:34
  • 1
    @Graham There is nothing so terrible in SMB1 for most users. Mainly, it is slower. It is also less secure, but that is often irrelevant. If you use Samba only on your LAN, and it's a small company where you can trust your users, then the security weakness is no big deal. It would of course be different if you give the Internet access to your Samba shares, or have secrets to hide from hacker-employees. So you have to weigh the hassle of upgrading vs. the speed and security benefits. – mivk Apr 11 '19 at 15:05
  • @mivk That's quite reassuring, thank you. It's a home based system and the files stored on the samba share are accessed between my Ubuntu box and a windoze laptop. – graham Apr 11 '19 at 16:14
7

I've faced the same problem myself, I wanted to auto mount using the method found in the Ubuntu wiki (https://wiki.ubuntu.com/MountWindowsSharesPermanently) although I've got the same problem as stated above: mount error(112): Host is down

The thing is what helped me is adding vers=3.0 at the and of the options:

//servername/sharename /media/windowMBsshare cifs credentials=/home/ubuntuusername/.smbcredentials,iocharset=utf8,sec=ntlm,vers=3.0 0 0

So it seems it only works now if you bypass SMB1 and use other specified one, SMB3 worked for me so I haven't tried anything else.

I've used a local account on the windows machine not one with outlook.com domain name as I've read something that this could cause conflicts too.

Marc Vanhoomissen
  • 2,198
  • 6
  • 24
  • 36
user695658
  • 71
  • 1
  • it seems that a recent update to windows 10 pro insider preview build 16232.rs_prerelease.170624-1334 included a change that required me to add `vers=3.0` to mount a share that was previously working without it. – dylan oliver Jul 13 '17 at 23:52
1

For Windows 9x (95, 98, ME) servers, in addition to vers=1.0, you need to add the servern[etbiosname] switch when invoking mount:

mount -t cifs -o vers=1.0,sec=none,user=alice,file_mode=0644,servern=SERVER //server/share /mount/point

The value should be the NetBIOS name of the remote server.

Here's the documentation of the switch:

       servernetbiosname=arg
              Specify  the  server netbios name (RFC1001 name) to use when at‐
              tempting to setup a  session  to  the  server.  Although  rarely
              needed  for mounting to newer servers, this option is needed for
              mounting to some older servers (such as OS/2 or Windows  98  and
              Windows  ME)  since  when  connecting over port 139 they, unlike
              most newer servers, do not support  a  default  server  name.  A
              server  name  can be up to 15 characters long and is usually up‐
              percased.

NetBIOS over TCP/IP is documented in RFC 1001 and 1002.

Bass
  • 151
  • 5