Mount error 112 host is down centos 7

CentOS

The Community ENTerprise Operating System

[Solved] Can no longer mount cifs — mount error(112)

[Solved] Can no longer mount cifs — mount error(112)

Post by kbrown » 2014/07/07 15:55:44

I am running CentOS 6.4 (Final). Up until July 4, 2014 I have successfully been mounting Windows Shares from a Windows Server 2012 R2 Standard with the following command:

mount -t cifs //Server-IP-Address/Share-Name -o username=name, password=password /winmount/Share-Name

On the evening of July 3, 2014 I did a number of Microsoft Windows updates on the Windows Server. After these Windows updates the mount command no longer works and I get this error:

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

The host (the Windows Server at the specified Server-IP-Address) in NOT down, it is UP. All the Windows 7 and Macintosh OSX clients CAN access the very same Share-Name without any problems, as has always been the case.

It appears that these Microsoft Windows Updates have altered something very critical that now prevents mounting the Windows Shares from mounting.

This is all internal to our network and there are no firewalls running on or between the CentOS and Windows boxes.

Any pointers, tips, or tricks to help me troubleshoot this would be most helpful.

Re: Can no longer mount cifs — mount error(112)

Post by drk » 2014/07/08 02:27:52

Re: Can no longer mount cifs — mount error(112)

Post by Whoever » 2014/07/08 04:54:32

kbrown wrote: Hello experts,

I am running CentOS 6.4 (Final). Up until July 4, 2014 I have successfully been mounting Windows Shares from a Windows Server 2012 R2 Standard with the following command:

mount -t cifs //Server-IP-Address/Share-Name -o username=name, password=password /winmount/Share-Name

On the evening of July 3, 2014 I did a number of Microsoft Windows updates on the Windows Server. After these Windows updates the mount command no longer works and I get this error:

mount error(112): Host is down

Are you sure that the Windows Server has the same IP address as before?

Re: Can no longer mount cifs — mount error(112)

Post by kbrown » 2014/07/08 15:24:03

Thank you «drk» and Whoever»,

Recall that the problem occurred immediately AFTER the Windows Updates I did on the evening of July 3. Prior to that the last Windows Update was on February 28.

Let me assure you that NOTHING has changed on the CentOS side — a cron job issues the mount command (repeated manually by me as needed) and so the IP address of the Windows Server has not changed and is correct — nor on our network for that matter. Typos do happen, but not in this case.

It is a bit heavy handed (IMHO) to consider upgrading the entire CentOS to 6.5 (or something higher) on this production machine. I would rather find the actual cause/solution than pin my hopes on thinking that a full OS upgrade might possibly solve the problem when in fact it might not and could introduce other unexpected changes, not to mention the time involved.

Let me mention that we have a Xerox WorkCentre 7435 that also uses SMB to save incoming faxes and scans to Windows Shares on the same Windows Server 2012 R2 Standard. Immediately after the said Windows Updates this system too is unable to speak to the Windows Shares and can no longer save faxes or scans.

I believe this has something to do with MS changing some aspect of SMB protocols. Searching MS site is like looking for a needle in a haystack, but I just stumbled upon MS KB2896636 http://support.microsoft.com/kb/2896636 which is titled «You cannot use certain third-party devices to send a document to a shared folder in Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2» and under Symptoms says:

Consider the following scenario:

— You connect a third-party device, such as a multifunction printer, to a computer that is running Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2.
— The third-party device is configured to use a deprecated dialect of the Server Message Block version 1 (SMBv1) protocol to transfer files.
— You create a shared folder on the computer. The device has read and write access to the shared folder.
— You try to send a document to the shared folder by using the device.

In this scenario, you cannot send the document to the shared folder. Therefore, no file is created in the shared folder. says

I think the problem I am experiencing has to do with versions/changes to how Microsoft implements SMB.

Источник

mount.cifs: mount error(112): Host is down

I am trying to mount a windows samba share on CentOS and RHEL 6 machines, but gives following error.

]# mount.cifs //example.com/Linux_Support /mnt -o credentials=/root/cifsauth,noserverino,vers=3.0

mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Messages logs has this error:

CIFS VFS: cifs_mount failed w/return code = -112

The same above command works in rhel7 and centos7. Any clue on how to make this work?

4 Answers 4

I found this link here which says SMB 2 and 3 is not supported for rhel and Centos 6. It can only mount SMB1. From Centos and rhel 7 this is supported.

I solved this problem by forcing version 1 of the smb protocol.
In my fstab this is done like this:

By default, the system certainly use SMB2 or 3, and it doesn’t work with my box. In fact it depends on your NAS. You have to give the good version depending on the SMB server.

First check the accessibility of your windows host in generally under centos6. If that is given then proceed.

At them moment, I dont have a test-setup to reproduce.I can only imagine. So maybe the default firewall-settings on your centos6 differs from the centos7 default firewall-settings. Did you try to mount with firewall switched off on your centos host? And what about SELinux? Maybe it has it fingers in it too.

My issue has been resolved by adding the ip address and hostname of windows server in /etc/hosts file in linux. then creating user in windows server with password. shared the folder with created user. created the file in /.smbcredentials adding following 2 lines

try to ping the windows machine with hostname it should ping. otherwise change windows firewall settings. now finally add the entry in fstab as below.

save the file and exit now run mount -av command you should get mounted successfully.

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Как в Linux монтировать шару CIFS

Что такое Linux и CIFS простыми словами.

Работа с общими папками Windows происходит с использованием протокола CIFS (SMB). Все примеры в данном руководстве выполняются на Linux Ubuntu и CentOS.

Подготовка

Установка пакетов

Для монтирования общей папки необходимо установить набор утилит для работы с CIFS.

yum install cifs-utils

apt-get install cifs-utils

Сетевые порты

Если мы будем монтировать сетевую папку, сервер которой находится за брандмауэром, необходимо открыть следующие порты:

Синтаксис

* вместо mount.cifs можно написать mount -t cifs.

mount.cifs //192.168.1.1/public /mnt

* простой пример монтирования папки public на сервере 192.168.1.1 в локальный каталог /mnt.

Ручное монтирование

Теперь монтирование можно выполнить следующей командой:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk

* в данном примере будет примонтирован каталог share на сервере 192.168.1.10 в локальную папку /mnt под учетной записью dmosk.

То же самое, с использованием домена:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk,domain=dmosk.local

Автоматическое монтирование CIFS через fstab

Для начала создаем файл, в котором будем хранить данные авторизации при подключении к общей папке:

И добавляем в него данные следующего вида:

username=dmosk
password=dPassw0rd
domain=dmosk.local

* в этом примере создана пара логин/пароль — dmosk/dPassw0rd; domain указывать не обязательно, если аутентификация выполняется без него.

Теперь открываем конфигурационный файл fstab:

и добавляем в него следующее:

//192.168.1.10/share /mnt cifs user,rw,credentials=/root/.smbclient 0 0

* в данном примере выполняется монтирование общей папки share на сервере с IP-адресом 192.168.1.10 в каталог /mnt. Параметры для подключения — user: позволяет выполнить монтирование любому пользователю, rw: с правом на чтение и запись, credentials: файл, который мы создали на предыдущем шаге.

Чтобы проверить правильность настроек, вводим следующую команду:

Примеры использования опций

Версии SMB

Если на стороне Windows используется старая или слишком новая версия протокола SMB, при попытке монтирования мы можем получить ошибку mount error(112): Host is down. Чтобы это исправить, указываем версию:

mount.cifs //192.168.1.10/share /mnt/ -o vers=1.0

* монтирование по протоколу SMB1.0

Монтирование от гостевой учетной записи

Если сервер принимает запросы без логина и пароля, то клиент подключается, как гость:

mount.cifs //192.168.1.10/share /mnt -o guest

//192.168.1.10/share /mnt cifs guest 0 0

Права на примонтированные каталоги

При монтировании папки мы можем указать определенные права:

mount.cifs //192.168.1.10/share /mnt -o file_mode=0777,dir_mode=0777

Для указания владельца, который будет назначен для примонтированного каталога, используем:

mount.cifs //192.168.1.10/share /mnt -o uid=33,gid=33

* чтобы посмотреть идентификаторы пользователя, вводим id -u и id -g .

Источник

Mount CIFS Host is down

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:

But I get the error:

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

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

15 Answers 15

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:

you will get the error:

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)

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

,iocharset=utf8,sec=ntlm,vers=1.0 0 0

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.

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

Defining the version ( vers=1.0 ) worked — here’s the full string:

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

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.

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

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 :

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.

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.

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.

Источник

CentOS

The Community ENTerprise Operating System

[Solved] Can no longer mount cifs — mount error(112)

[Solved] Can no longer mount cifs — mount error(112)

Post by kbrown » 2014/07/07 15:55:44

I am running CentOS 6.4 (Final). Up until July 4, 2014 I have successfully been mounting Windows Shares from a Windows Server 2012 R2 Standard with the following command:

mount -t cifs //Server-IP-Address/Share-Name -o username=name, password=password /winmount/Share-Name

On the evening of July 3, 2014 I did a number of Microsoft Windows updates on the Windows Server. After these Windows updates the mount command no longer works and I get this error:

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

The host (the Windows Server at the specified Server-IP-Address) in NOT down, it is UP. All the Windows 7 and Macintosh OSX clients CAN access the very same Share-Name without any problems, as has always been the case.

It appears that these Microsoft Windows Updates have altered something very critical that now prevents mounting the Windows Shares from mounting.

This is all internal to our network and there are no firewalls running on or between the CentOS and Windows boxes.

Any pointers, tips, or tricks to help me troubleshoot this would be most helpful.

Re: Can no longer mount cifs — mount error(112)

Post by drk » 2014/07/08 02:27:52

Re: Can no longer mount cifs — mount error(112)

Post by Whoever » 2014/07/08 04:54:32

kbrown wrote: Hello experts,

I am running CentOS 6.4 (Final). Up until July 4, 2014 I have successfully been mounting Windows Shares from a Windows Server 2012 R2 Standard with the following command:

mount -t cifs //Server-IP-Address/Share-Name -o username=name, password=password /winmount/Share-Name

On the evening of July 3, 2014 I did a number of Microsoft Windows updates on the Windows Server. After these Windows updates the mount command no longer works and I get this error:

mount error(112): Host is down

Are you sure that the Windows Server has the same IP address as before?

Re: Can no longer mount cifs — mount error(112)

Post by kbrown » 2014/07/08 15:24:03

Thank you «drk» and Whoever»,

Recall that the problem occurred immediately AFTER the Windows Updates I did on the evening of July 3. Prior to that the last Windows Update was on February 28.

Let me assure you that NOTHING has changed on the CentOS side — a cron job issues the mount command (repeated manually by me as needed) and so the IP address of the Windows Server has not changed and is correct — nor on our network for that matter. Typos do happen, but not in this case.

It is a bit heavy handed (IMHO) to consider upgrading the entire CentOS to 6.5 (or something higher) on this production machine. I would rather find the actual cause/solution than pin my hopes on thinking that a full OS upgrade might possibly solve the problem when in fact it might not and could introduce other unexpected changes, not to mention the time involved.

Let me mention that we have a Xerox WorkCentre 7435 that also uses SMB to save incoming faxes and scans to Windows Shares on the same Windows Server 2012 R2 Standard. Immediately after the said Windows Updates this system too is unable to speak to the Windows Shares and can no longer save faxes or scans.

I believe this has something to do with MS changing some aspect of SMB protocols. Searching MS site is like looking for a needle in a haystack, but I just stumbled upon MS KB2896636 http://support.microsoft.com/kb/2896636 which is titled «You cannot use certain third-party devices to send a document to a shared folder in Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2» and under Symptoms says:

Consider the following scenario:

— You connect a third-party device, such as a multifunction printer, to a computer that is running Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2.
— The third-party device is configured to use a deprecated dialect of the Server Message Block version 1 (SMBv1) protocol to transfer files.
— You create a shared folder on the computer. The device has read and write access to the shared folder.
— You try to send a document to the shared folder by using the device.

In this scenario, you cannot send the document to the shared folder. Therefore, no file is created in the shared folder. says

I think the problem I am experiencing has to do with versions/changes to how Microsoft implements SMB.

Источник

Как в Linux монтировать шару CIFS

Что такое Linux и CIFS простыми словами.

Работа с общими папками Windows происходит с использованием протокола CIFS (SMB). Все примеры в данном руководстве выполняются на Linux Ubuntu и CentOS.

Подготовка

Установка пакетов

Для монтирования общей папки необходимо установить набор утилит для работы с CIFS.

yum install cifs-utils

apt-get install cifs-utils

Сетевые порты

Если мы будем монтировать сетевую папку, сервер которой находится за брандмауэром, необходимо открыть следующие порты:

Синтаксис

* вместо mount.cifs можно написать mount -t cifs.

mount.cifs //192.168.1.1/public /mnt

* простой пример монтирования папки public на сервере 192.168.1.1 в локальный каталог /mnt.

Ручное монтирование

Теперь монтирование можно выполнить следующей командой:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk

* в данном примере будет примонтирован каталог share на сервере 192.168.1.10 в локальную папку /mnt под учетной записью dmosk.

То же самое, с использованием домена:

mount.cifs //192.168.1.10/share /mnt -o user=dmosk,domain=dmosk.local

Автоматическое монтирование CIFS через fstab

Для начала создаем файл, в котором будем хранить данные авторизации при подключении к общей папке:

И добавляем в него данные следующего вида:

username=dmosk
password=dPassw0rd
domain=dmosk.local

* в этом примере создана пара логин/пароль — dmosk/dPassw0rd; domain указывать не обязательно, если аутентификация выполняется без него.

Теперь открываем конфигурационный файл fstab:

и добавляем в него следующее:

//192.168.1.10/share /mnt cifs user,rw,credentials=/root/.smbclient 0 0

* в данном примере выполняется монтирование общей папки share на сервере с IP-адресом 192.168.1.10 в каталог /mnt. Параметры для подключения — user: позволяет выполнить монтирование любому пользователю, rw: с правом на чтение и запись, credentials: файл, который мы создали на предыдущем шаге.

Чтобы проверить правильность настроек, вводим следующую команду:

Примеры использования опций

Версии SMB

Если на стороне Windows используется старая или слишком новая версия протокола SMB, при попытке монтирования мы можем получить ошибку mount error(112): Host is down. Чтобы это исправить, указываем версию:

mount.cifs //192.168.1.10/share /mnt/ -o vers=1.0

* монтирование по протоколу SMB1.0

Монтирование от гостевой учетной записи

Если сервер принимает запросы без логина и пароля, то клиент подключается, как гость:

mount.cifs //192.168.1.10/share /mnt -o guest

//192.168.1.10/share /mnt cifs guest 0 0

Права на примонтированные каталоги

При монтировании папки мы можем указать определенные права:

mount.cifs //192.168.1.10/share /mnt -o file_mode=0777,dir_mode=0777

Для указания владельца, который будет назначен для примонтированного каталога, используем:

mount.cifs //192.168.1.10/share /mnt -o uid=33,gid=33

* чтобы посмотреть идентификаторы пользователя, вводим id -u и id -g .

Источник

Centos 7 mount error 112 host is down

Question

Hi. I am attempting to use the new Azure Files feature, following the video on the blog from MSDN. When I attempt to mount the share on my CentOS VM, I get the error message:

mount error(112): Host is down

How can I troubleshoot this or what is the known issue?

I caught a mention in the Azure release blog that only Ubuntu images are supporting the Azure Files preview at this time. Is this true?

Answers

• Proposed as answer by Jason Tang 501 Tuesday, September 22, 2015 5:31 PM
• Marked as answer by Michael Curd Microsoft employee Thursday, October 1, 2015 5:51 PM

Just incase someone else finds this and has the same issue as me. You may also get the above error if in your mount command you aren’t specifying vers=2.1 as the documentation suggests:

sudo mount -t cifs //myaccountname.file.core.windows.net/mysharename ./mymountpoint -o vers=2.1,username=myaccountname,password=StorageAccountKeyEndingIn==

adding in that vers=2.1 solved it for me.

• Proposed as answer by shan5 Tuesday, July 12, 2016 10:48 AM
• Marked as answer by SadiqhAhmed-MSFT Microsoft employee Tuesday, July 12, 2016 2:05 PM

This happens only when storage ccount is in a different region than the virtual machine. For now, they have to be in the same region.

Yes, if you tried use CentOS 7.1 within the same region as your file share, then it should work.

Both latest version of Ubuntu and CentOS 7.1 support SMB 2.1 so they can be used to mount the file share created in Azure File Storage (within same region)

Источник

Centos 7 mount error 112 host is down

Question

Hi. I am attempting to use the new Azure Files feature, following the video on the blog from MSDN. When I attempt to mount the share on my CentOS VM, I get the error message:

mount error(112): Host is down

How can I troubleshoot this or what is the known issue?

I caught a mention in the Azure release blog that only Ubuntu images are supporting the Azure Files preview at this time. Is this true?

Answers

• Proposed as answer by Jason Tang 501 Tuesday, September 22, 2015 5:31 PM
• Marked as answer by Michael Curd Microsoft employee Thursday, October 1, 2015 5:51 PM

Just incase someone else finds this and has the same issue as me. You may also get the above error if in your mount command you aren’t specifying vers=2.1 as the documentation suggests:

sudo mount -t cifs //myaccountname.file.core.windows.net/mysharename ./mymountpoint -o vers=2.1,username=myaccountname,password=StorageAccountKeyEndingIn==

adding in that vers=2.1 solved it for me.

• Proposed as answer by shan5 Tuesday, July 12, 2016 10:48 AM
• Marked as answer by SadiqhAhmed-MSFT Microsoft employee Tuesday, July 12, 2016 2:05 PM

This happens only when storage ccount is in a different region than the virtual machine. For now, they have to be in the same region.

Yes, if you tried use CentOS 7.1 within the same region as your file share, then it should work.

Both latest version of Ubuntu and CentOS 7.1 support SMB 2.1 so they can be used to mount the file share created in Azure File Storage (within same region)

Источник

Centos 7 mount error 112 host is down

Question

Hi. I am attempting to use the new Azure Files feature, following the video on the blog from MSDN. When I attempt to mount the share on my CentOS VM, I get the error message:

mount error(112): Host is down

How can I troubleshoot this or what is the known issue?

I caught a mention in the Azure release blog that only Ubuntu images are supporting the Azure Files preview at this time. Is this true?

Answers

• Proposed as answer by Jason Tang 501 Tuesday, September 22, 2015 5:31 PM
• Marked as answer by Michael Curd Microsoft employee Thursday, October 1, 2015 5:51 PM

Just incase someone else finds this and has the same issue as me. You may also get the above error if in your mount command you aren’t specifying vers=2.1 as the documentation suggests:

sudo mount -t cifs //myaccountname.file.core.windows.net/mysharename ./mymountpoint -o vers=2.1,username=myaccountname,password=StorageAccountKeyEndingIn==

adding in that vers=2.1 solved it for me.

• Proposed as answer by shan5 Tuesday, July 12, 2016 10:48 AM
• Marked as answer by SadiqhAhmed-MSFT Microsoft employee Tuesday, July 12, 2016 2:05 PM

This happens only when storage ccount is in a different region than the virtual machine. For now, they have to be in the same region.

Yes, if you tried use CentOS 7.1 within the same region as your file share, then it should work.

Both latest version of Ubuntu and CentOS 7.1 support SMB 2.1 so they can be used to mount the file share created in Azure File Storage (within same region)

Источник