Enabling Samba Shares Across Subnets, Part 1

Serving Multiple Subnets

It's a common belief that Samba shares cannot be accessed across subnets. But actually Samba can cross subnets. It's easy for Linux hosts, and a bit less easy for Windows clients. But fear not, for we shall guide you through safely past the traps and pitfalls.

In this series we'll set up a Samba server that serves two subnets, which is is a common scenario even on home networks: one wired and one wireless. Then we'll hook up a third subnet just to show how it's done. Once you know how to do that you can easily expand to as many subnets as you want. In Part 1, we'll start out with a simple anonymous file and printer server.

If you're wondering why not just bridge your wired and wireless subnets, you can, and this works well for small networks. But Ethernet bridging does not scale very well because it generates a lot of broadcast traffic, and as you add more subnets it becomes pointless--if you're going to bridge them you might as well have one big address space instead of dividing it. Routing is more efficient, and you have more control over what goes where. So you can have it all--a nice efficient routed network, and a central Samba server available to all your network segments. (You can also share printers across subnets with CUPS, and make them available to Windows clients with CUPS + Samba.)

There are several possible scenarios:

• Samba as a domain controller.
• Samba as a member of an Active Directory domain.
• More than one Samba server.
• Samba as a plain old file and printer server.

We're going to create a simple anonymous Samba fileserver that both Linux and Windows users can read and write to. All it will do is share files--it is not a login server. This is not a very secure setup, but I'm keeping it simple on purpose. Once you share an anonymous server successfully, you can easily add access controls and restricted shares. Your prerequisites are:

• Routing works all across your network--all hosts in the different subnets can ping each other.
• Optionally, and even better, you have local name services working, and can ping by hostname as well.
• Windows clients have TCP/IP and Client for Microsoft Networks installed and working.
• Windows clients do not have IPX installed. Having both IPX and TCP/IP will slow down performance considerably. You don't need IPX unless you're running some incredibly ancient Novell Netware. If you are, I cannot help you.