Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to connect a client running Ubuntu 13.04 to a network share hosted by a file server which has recently been upgraded from Windows Server 2003 to 2012.

Currently I am able to mount the remote share while connected to the LAN using:

sudo mount -t cifs //myserver.mydomain.co.uk/myshare /media/myshare/ -o user=myself,domain=myworkgroup,pass=**********

However, I'm having trouble mounting the share via a Cisco (IPsec/Xauth) VPN. Prior to the server upgrade I had no problem with this, but now I get the following message:

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

dmesg | tail gives me [ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112

The host is most definitely not down - I am still able to connect to the same share over the VPN using smbclient:

smbclient //myserver.mydomain.co.uk/myshare -U myself -W myworkgroup
Enter myself's password: 
session request to MYSERVER.MYDOMAIN failed (Called name not present)
Domain=[MYWORKGROUP] OS=[Windows Server 2012 Standard 9200] Server=[Windows Server 2012 Standard 6.2]
smb: \>

I'm not sure of the significance of the "session request to MYSERVER.MYDOMAIN failed (Called name not present)" error, since I'm still able to browse the directory structure.

Any suggestions for what to try next?

share|improve this question
    
Hi! Linux questions are absolutely on topic here, so we're hesitant to migrate those away. In fact, as your question is about connecting to a Windows share, I'm unsure whether it'd be on topic for Unix & Linux at all. –  slhck Jun 6 '13 at 16:17
    
Can you verify that pining is actually working over VPN? When connected via VPN is the Ubuntu system in the same subnet than the windows server? Also this could be a MTU issue. Determine the maximum MTU in both directions (bit.ly/199o0Xt) and see if you need to manually decrease it for the connection to work. –  leepfrog Jun 8 '13 at 14:38
    
I think you might be on the right track with this being a subnetting issue. Pinging does not work over the VPN, and my subnet mask while connected via the VPN is 255.255.255.255 (so I can't possibly be on the same subnet as the server I'm trying to connect to). What I find most puzzling is why smbclient still works over the VPN. –  ali_m Jun 8 '13 at 15:14
    
I was asking about Ping because I had experiences in the past where CIFS access between two windows machines was problematic if ICMP Echo was blocked (in your situation this might be caused by the windows 2012 firewall if it isn't disabled). The subnet 255.255.255.255 however can be correct as all connections need to be routed through that adapter (default route might also point to your VPN adapter IP) –  leepfrog Jun 8 '13 at 15:26
    
Regarding firewalls, I can't really make any changes on the server side. Besides it seems to me that it shouldn't be necessary to change anything on the server side in order to make this work, since (A) I can still connect to the share using smbclient, and (B) other Windows and Mac users in my department are also able to connect to the share over the VPN. Do you think it might have something to do with the VPN client? I'm using vpnc, whereas the Windows/Mac people are using the Cisco AnyConnect client. –  ali_m Jun 9 '13 at 0:09

3 Answers 3

You can connect with SMB Client because you can connect as "anonymous". But being able to connect as anonymous doesn't mean that the authentification service for the regular users is working.

You probably have a firewall issue. Open these 4 ports :

- UDP&TCP/137
- UDP&TCP/138
- UDP&TCP/139
- TCP/445

Check that you are allowing the Netlogon Service on the Windows Side to communicate too.

share|improve this answer
    
Thanks, that definitely helped my understanding of the problem! Unfortunately, as I mentioned to leepfrog, I'm not able to make any changes on the server side (it's a departmental server that I have no admin rights to). On the other hand, my Windows/Mac colleagues who use the proprietary Cisco AnyConnect VPN client rather than vpnc have no problem connecting to the share - any ideas why they can and I can't? –  ali_m Jun 15 '13 at 14:44
    
Could you try with an other client like OpenConnect ? –  Yannovitch Jun 15 '13 at 15:06
    
I just tried connecting with OpenConnect, still no luck (although I can connect over the VPN to a remote share on a different server on the same network). Perhaps there is some additional configuration flag that I need to pass to openconnect or vpnc? I've tried experimenting with --target-network=<CIDR>, but that didn't help. –  ali_m Jun 15 '13 at 16:43
    
I'm giving you the bounty since your answer has been the most helpful, even though it hasn't quite solved my problem –  ali_m Jun 16 '13 at 14:23

Can you access port 445/tcp when connect via VPN. Use

nc -v myserver.mydomain.co.uk 445.  

If it worked.

Connection to myserver.mydomain.co.uk 445 port [tcp/microsoft-ds] succeeded! 

The only issue you might see is if the firewall proxies the connect that might come up succeeded anyway. Then you would want to do a packet capture and see if the Windows server is sending anything.

share|improve this answer
    
Hi Ross, tried your suggestion and could not connect to port 445 (timed out after 2min). –  ali_m Jun 13 '13 at 19:03
    
Then you have a device blocking your connection. Most likely it is a firewall but could be router also. –  Ross Jun 13 '13 at 19:54
    
OK, but in that case, why can I still connect using smbclient? –  ali_m Jun 13 '13 at 20:54
up vote 0 down vote accepted

Well, a year later I finally figured it out!

The root cause turned out to be a problem with hostname resolution. The clue came when I was trying to solve a different problem with SSHing into a machine on the same remote network via the VPN.

From the output of ssh -v:

debug1: Connecting to myserver2.mydomain.ox.ac.uk [163.1.21.182] port 22.

I found that OpenSSH was trying to connect to a nonsense IP address (it was actually resolving the hostname of my server to the IP address of a network printer!). I found that ping was also failing to correctly resolve hostnames, whereas host seemed to work. That eventually led me to this thread on Ask Ubuntu.

It turns out that ping and ssh both use the glibc resolver, as does mount.cifs. The sources from which glibc obtains name-service information are configured in /etc/nsswitch.conf.

The contents of my nsswitch.conf originally looked like this:

passwd:         compat
group:          compat
shadow:         compat

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns wins mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

The important line is the one that starts with hosts:, which lists the order of sources that glibc queries when performing hostname resolution. Note that in my version, dns comes after [NOTFOUND=return] in the search order.

My interpretation is that if glibc fails to resolve the hostname according to the first four sources, it will return before it has actually queried any DNS servers! I have no idea why nsswitch.conf was configured in this way (I certainly didn't set it up like that), but changing the line to:

hosts:          files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

suddenly made everything work properly, including ping, ssh and mount.cifs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.