|
Enabling Samba Shares Across Subnets, Part 2
Sharing With Windows and Multiple SubnetsLinuxPlanet Classics: originally published January 17, 2008 In Part 1 we set up a simple anonymous Samba file and printer server. Now we're going to share it across subnets. Both Windows and Linux clients will be able to use this server. Our example network has three segments, as this elegant ASCII network diagram shows:
router
|
--------------------switch----------------------
| | |
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
lan1 lan2 lan3
For ease of discussion, we'll call them lan1, lan2, and lan3. Our Samba server sits on lan1, with an address of 192.168.1.10. lan2 and lan3 contain a motley assortment of Windows and Linux clients. In this example there is no domain controller, but only a peer network. We'll get to Windows-type domains in a moment.
Your Windows clients need three things to be able to use the Samba server:
You can save a step by delivering the WINS address via DHCP. Windows 2000, XP, and Vista should have NetBIOS-over-TCP enabled by default, but it never hurts to check. It can be disabled, and in Active Directory domains that do not have antique, unsafe Windows 9x/ME clients it is often turned off. Then the Samba server must be the WINS (Windows Internetworking Name) server and domain master browser. You must have one, and one only WINS server per workgroup to enable cross-subnet Samba browsing. WINS is the magic ingredient that makes it all work. WINS performs NetBIOS name resolution, because ordinary DNS does not include the necessary NetBIOS extensions. NetBIOS-based networking uses UDP broadcasts; since broadcast traffic cannot cross routers, your Samba WINS server encapsulates NetBIOS over TCP/IP. The domain master browser controls the browse lists; it has nothing to do with Active Directory or NT domains. Take the smb.conf from part 1 and add these lines to the [global] section: domain master = yes preferred master = yes local master = yes wins support = yes wins proxy = yes os level = 65Test and restart Samba just like we did in Part 1. Once your Windows clients are correctly configured, they should all be able to browse the file shares on your Samba server and use your shared printers. Figure 1 shows what an example cross-subnet workgroup looks like on Windows Vista. Xena is the Samba server on lan1, Freya and Uberpc are on lan2, and Newpad is on lan3.
Master BrowsersYou need one local master browser per subnet. The various Windowses on a subnet will duke it out amongst themselves for who gets to be the master browser. If you prefer more correct terminology, Windows calls it the Computer Browser Service, and if there is more than one Windows PC they will have elections every 15 minutes or so to elect a master browser. The newest Windows usually wins, and its address is reported to WINS. You can turn this off in Control Panel | Administrative Tools | Computer Browser, but it's not necessary unless you're trying to isolate a problem. Leaving it enabled in all of your Windows PCs means you'll always have a LMB available. You may prefer to use Samba as a LMB. All you need is a Linux PC running Samba server, and this smb.conf: [global] netbios name = freya security = share domain master = no preferred master = yes local master = yes wins support =no wins proxy = no wins server = 192.168.1.10 os level = 65That's all you need; you don't need to define any other shares. The preferred master directive forces an election when Samba starts up, and setting the os level to 65 ensures that it will always win elections. You don't need a Samba LMB when you have Windows PCs on the same subnet. However, all Linux clients need Samba server running with this minimal configuration: [global] netbios name = uberpc security = share domain master = no preferred master = no local master = no wins support = no wins proxy = no wins server = 192.168.1.10 os level = 0You now have a fully-functioning cross-subnet Samba server that is available to all members of a single workgroup.
Windows Domain IntegrationIf you are using Samba as your primary domain controller (PDC), then your Samba PDC should also be the domain master browser. If your Samba boxes are part of a Windows NT or Active Directory domain, then all the Sambas need to be LMBs, because by default Windows domain controllers are also the domain master browsers. You do not want conflicting domain master browsers, because then network browsing won't work. Because browse lists are updated at approximately 15 minute intervals, it can take some time for them to get all up-to-date. Windows caches the browse lists, so a common problem is it will appear to hang when it tries to establish a connection with a share that is no longer on the network. The bigger your network and the more shares and hosts there on it, the more this can be a problem. The quickest fix is for users to simply delete the shortcuts to the unavailable hosts. Once you get a simple anonymous Samba server shared reliably across subnets, you can go ahead and set up additional shares, restricted password-protected shares, and user's home directories just like on any Samba server. ResourcesTwo indispensible references are:
Carla Schroder is the author of the Linux Cookbook and the Linux Networking Cookbook. Both books have extensive Samba chapters. Carla is also the managing editor of Linux Planet. LinuxPlanet Classics: originally published, January 17, 2008
|