[SOLVED] Mount error 115 on some shares

Johnnie.it · 03-24-2014, 07:13 AM

Hi there guys,

I hope you can help me with a small issue that is kinda driving me crazy.
I'm running debian wheezy on a virtual machine and trying to mount some shares from the win8.1 host.
The lines I put in the /etc/fstab are:

Code:

//192.168.0.10/dir1 /home/user/dir1 cifs credentials=/root/.secret.pwd,uid=1000,gid=1000,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0
//192.160.0.10/dir2 /home/user/dir2 cifs credentials=/root/.secret.pwd,uid=1000,gid=1000,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0
//192.160.0.10/dir3 /home/user/dir3 cifs credentials=/root/.secret.pwd,uid=1000,gid=1000,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0

The first share gets mounted correctly, but not the other two.
This is the output I get when sudo-ing a mount -a:

Code:

mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

and this is what /var/log/syslog shows:

Code:

Mar 24 12:56:12 hostname kernel: [ 1887.029043] CIFS VFS: Error connecting to socket. Aborting operation
Mar 24 12:56:12 hostname kernel: [ 1887.030013] CIFS VFS: cifs_mount failed w/return code = -115
Mar 24 12:56:22 hostname kernel: [ 1897.052130] CIFS VFS: Error connecting to socket. Aborting operation
Mar 24 12:56:22 hostname kernel: [ 1897.053885] CIFS VFS: cifs_mount failed w/return code = -115

The same happens at boot time.

Now, the crazy thing is that if I run manually a:

Code:

sudo mount //192.168.0.10/dir2 /home/user/dir2 -t cifs -o credentials=/root/.secret.pwd,uid=1000,gid=1000

it works perfectly.

Now, I'm no power user, but I thought I'd be able to manage a couple of simple cifs shares...but then again I guess not

So, my questions so far are:
1. how the heck do I make that work?
2. why is it not working? Might be the security? Should I choose perhaps ntlmv2? I read a bit around but I don't know this kind of security mechanisms, so...
3. why on earth is the first mount working just like a charm and not the other two?

You know what? I'm trying now to remove the sec option from the fstab, and see how that works out.

In the meantime, if anyone could lend a hand I'd appreciate it very much

Johnnie.it · 03-24-2014, 09:11 AM

AAAALlllright. How can I get a mod to delete this thread?
This is just too embarassing

Solved, by the way.
Thanks everybody who took the time to even read it.

ibiza82 · 03-16-2015, 10:31 AM

So nice of you to post the solution

maples · 05-13-2015, 05:14 PM

Actually, could you post your solution? I'm having issues with mounting my CIFS shares, and I can't see anything "obviously wrong" with your fstab entries.

EDIT: Found OP's problem. He mis-typed the IP addresses in the second and third entries. Which is not the problem I'm having. So I'll start a new thread.

xzatech · 02-03-2016, 10:11 AM

How did you solve it?/

desiagui · 02-07-2016, 12:39 PM

Not sure how he solved it but I was having the same issue. I had it working but had to reinstall and then was having the issue. My fstab entry looks like this:

//servera/Movies /media/Movies cifs credentials=/home/linuxuser/.smbcredentials,iocharset=utf8,sec=ntlm 0 0

Turns out the new system did not have servera in the hosts file. Just adding an entry for it did it

Tim Abracadabra · 02-10-2016, 08:12 PM

Not sure how it was resolved either but .. looking considering the error connecting to socket and
noting that the IP address of the first mount that works is different than the IP address of the
two failed mounts, I suspect the IP address for those two was wrong ;-)

Tim Abracadabra · 02-10-2016, 11:43 PM

err, revived necro thread, just noticed. + to maples!

Damascus01 · 12-11-2016, 03:37 AM

I had 2 of my 3 remote shares mounting but couldn't get my share at //10.1.1.5 to mount for the life of me.

Then I realised my remote folder was actually at //10.1.1.4

ntsagkas · 04-08-2017, 06:47 PM

Make sure the remote mount address does not resolve to an IPv6 address but to an IPv4 one. It took me a while to solve this one by adding a manual IPv4 entry to /etc/hosts. Not sure if the IPv6 mount.cifs problem was something on my system setup or something more general

Spelevink · 02-21-2019, 03:19 PM

Sorry for revisiting this, but I have struggled all morning and had the exact same issues with the exact same solution

i had typo-ed the share ip address to '192.167.11.55' instead of the correct '192.168.11.55'

timblaktu · 05-27-2021, 03:54 PM

A co-worker sent me this link, and I'm a little confused about where the actual solution is posted above, so I'll post my solution:

On some older systems, adding `_netdev` mount option might fix the issue. `_netdev` is supposed to delay the mount until after the network connects.

However, in our case, we're using Debian Buster, which like many modern linux systems uses Systemd. The proper solution for modern systemd systems is to use options `noauto,x-systemd.automount` which will:
* NOT mount the network drive boot
* mount the drive at first access

This is the most fault-tolerant way to mount network shares in a systemd system, because systemd.mount takes care of managing the dependencies that network mounts have, and can ensure the mount will not be attempted until it is most likely to succeed.

Enjoy!