Enabling Samba Shares Across Subnets

Question

I was curious how I could go about setting up SAMBA so that shares could be seen and used across different subnets. We have some Linux devices that are bound to Active Directory and we would like to have them serve SAMBA shares to clients that will reside in a different subnet than what the servers reside in? Is there any way to do this without needing to setup a WINS server or use legacy NetBIOS methods since the majority of our clients are Windows 7, Windows Server 2003, Windows Server 2008, and Macintosh OS X (10.6 or newer)?

EDIT

Right now, only clients in the same subnet as the SAMBA server can see the shares. Clients outside of the subnet (i.e. the client subnet) cannot see or connect to the share.

The error returned is: The specified network name is no longer available. It does not seem to matter if I use IP, FQDN, or NetBIOS name to try and connect to the share with.

We have a common Cisco router handling the inter-subnet routing. Everything else seems to work correctly with this network setup and the device can be pinged from multiple subnets. I also do not believe it to be a firewall type of issue since the rules for this segment are rather lax.

Solution 1

Daniel of QNAP Taiwan helped me with this problem, and it turns out that it has to do with the workstation requiring signing of CIFS communications, which the QNAP does not yet do.

If you turn this registry key off (to zero) on the workstation in the other subnet, it will allow CIFS communications to the QNAP.

HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters\RequireSecuritySignature

I forget the exact error code we were getting on our Windows 7 workstations in the other subnet, but it was an obscure and meaninglessly generic error message, different from "The specified network name is no longer available." However, the symptoms are the same: systems on the same subnet as the QNAP work fine, systems on other subnets fail.

QNAP says that they will likely address this registry key setting by setting up the QNAP to sign its CIFS communications, but there is no estimate for delivery.

Solution 2

My initial reaction is that you're having name resolution issues. Accessing the shared folder from a client on a different subnet than then the server computer using the server computer's IP address in the UNC should result in successful access. Assuming it does you've got a name resolution problem.

You comment that you're not able to access the shared folder using the IP address or FQDN, though, befuddles me. I'd fire up tcpdump on the Samba server (or turn up the logging level) and make sure that you're actually seeing the attempted connection from the client. Samba's debug logging is probably going to give you the best diagnosis once you've determined that the connection attempt is actually getting to Samba.

re: a long term name resolution strategy - With the clients you describe you can use DNS to resolve the server computer's name. You may see some delays while NetBIOS resolution times-out unless you disable NetBIOS on Windows Server 2003. (I don't recall if Windows Server 2008 and Windows 7 will attempt NetBIOS resolution before DNS resolution.)

You're not going to get "network browsing" functionality without using NetBIOS. That means no "My Network Places", etc. If you need that then put up a WINS server and use NetBIOS.

Comments

[David Schwartz]

What error do you get when they try to connect to the share? They won't see them, but they should be able to connect to them.

[mdpc]

Firewall or port restriction issue?

[ravi yarlagadda]

What's doing your inter-subnet routing? Chances are, it's the culprit.

[John]

I am using a QNAP NAS device and the embedded version of Linux does not have tcpdump available. I did not know if there were some setting changes that could be made to the SAMBA config to help with this situation or not. I appreciate your suggestions and ideas.

[John]

For what it is worth, we do have DNS setup to resolve the server names and the client computer names since they are all part of our larger Active Directory infrastructure.