I have recently installed Linux Mint 19 Cinnamon (version 3.8.8, kernel 4.15.0-20 generic) running in VMware Workstation 14 Player (version 14.1.3 build 9474260) on host Windows 10 Pro (version 1803 build 17134.228).

I created a folder on the desktop & then used the following mount command in terminal in order to access the documents folder from the desktop PC (called Chillblast):
sudo mount.cifs //192.168.1.88/Documents-on-Chillblast Desktop/Docs-on-Chillblast -o user=~~~~,password=~~~~
This worked fine and the Documents folder from the desktop PC can be accessed under Linux.

In a similar way I next I tried to access a folder that is on a USB drive attached to the router. My Terminal command was:
sudo mount.cifs //192.168.1.1/Common-docs-on-router Desktop/Common-docs-on-router -o user=~~~~,password=~~~~~
In this case the user name & password were the relevant ones for the router, not the same as previously for the desktop PC. This mount command failed, the message being:
Mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

The router was not down, as I could immediately log onto it from a browser under Windows on the desktop PC. The page in the manual to which I was referred threw no light on the problem. My user name on Windows and Linux is mike, and on the router mike has R/W permission for all files.

Can anyone suggest where I have gone wrong?

Hello

The error message "host is down" usually means the server is responding, but not on the ports used by file sharing. You could get that error message if the file service sharing is stopped or disabled. And samba/cifs have different versions, so it could be the client/server is not on the same version. It could be you need to add "-o vers=X.0" to the mount command.

Here's a link with some workarounds:

https://serverfault.com/questions/41...s-host-is-down

1 members found this post helpful.

Yes, the missing version number was the problem. I amended the option string to:
-o vers=1.0,username=~~~~,password=~~~~
and the mount command now works. Many thanks for your response.

A follow-on question, if I may.
How do I ensure that the mount.cifs commands are executed automatically at log-on?

It may be that you can mount shares at boot time with an fstab entry. Something along these lines.

https://wiki.ubuntu.com/MountWindowsSharesPermanently

Many thanks jefro for the link that you provided. However, my application (or misunderstanding) of its information had an unexpected result. In Terminal I did:

sudo gedit /etc/fstab and then added the following two lines to the end of /etc/fstab:

//192.168.1.88/Documents-on-Chillblast /home/mike/Desktop/Docs-on-Chillblast auto username=~~~,password=~~~,iocharset=uft8 0 0
//192.168.1.1/Common-docs-on-router /home/mike/Desktop/Common-docs-on-router auto vers=1.0,username=~~~,password=~~~,iocharset=uft8 0 0

I then did:

sudo mount –a

All appeared to be OK, no error was reported, and both sets of files were now accessible. However, on restarting, the following error message was given;

Using nano I edited /etc/fstab by commenting out the two lines that I had entered earlier, and after a restart I was back to the previous position. Which leaves me with some questions:

1. What was wrong with the two lines that I added to /etc/fstab?
2. Why didn’t the command sudo mount –a report an error?
3. How else can I check the integrity of any changes that I make to /etc/fstab?

Any further thoughts?

I would use cifs instead of auto. Network mounts should wait until the network becomes available which I believe is handled by the NetworkManager-wait-online.service. I assume that systemd can not tell this is a network mount and since the network isn't up yet results in your error message.

If you are not using NetworkManager then you might look into systemd-networkd-wait-online.service, x-systemd.automount or autofs.

1 members found this post helpful.

Many thanks michaelk. In /etc/fstab for both lines I changed auto to cifs and also specified vers=1.0 for both. The two sets of files are now accessible and there is no problem on a restart.

There was one oddity which hasn't (yet) caused a problem. After I did the gedit I was given three warning messages:
gedit:3649 ... Set document metadata failed: Setting attribute metadata: : gedit-spell-language not supported
ditto ... gedit-encoding not supported
ditto ... gedit-position not supported

The attachement shows a listing of the fstab contents. Is the warning message anything to be concerned about?

I think the warnings were from using gksudo or something along those lines???