Few of us are lucky enough to work in a pure Linux environment. If you are, you can file this article under "Something for the future" because it doesn't apply to you—for now. Samba is the Windows interoperability suite for Linux and Unix environments. It applies to those of you who work in a heterogeneous environment that might include Linux, Unix, Windows, macOS, and who knows what else.
(Hopefully, there are no pure DOS computers or OS/2 left on your networks. But, if there are, you can leverage Samba to communicate to and from those systems too.)
Note: This article is not strictly a how-to tutorial. It is a general overview with tips for avoiding problems with Samba implementation. There are Samba how-tos coming soon to Enable Sysadmin.
Samba uses the Server Message Block (SMB) protocol, which is used by Windows systems to communicate with each other. Using Samba, you can have your Linux systems map drives to Windows systems, and you can have Windows systems map drives to Linux systems—though, the latter is far more likely.
You see, Samba lets you mimic file and print services on a Linux system. You might not have a full appreciation of what such a system can do for you, but in short, using Samba lets you create a Linux-based file and print server, potentially saving you money and allowing for easier administration.
[You might also enjoy: Life as a Linux system administrator.]
Domains not required
Contrary to the advice you'll find elsewhere, you do not have to implement a Windows Active Directory (AD) domain to use Samba file and print sharing. If you have a domain, you also don't have to join your Linux system to it in order to provide file and print services to Windows systems. But, there are two things you need to do in order to make these two operating systems work seamlessly as if you did have an AD domain in place: Sync the passwords and match the domain or workgroup name.
Note: I'm not against AD domains. On the contrary, I'm for them. I'm a Windows administrator too and I see the value in having one. If you don't have an AD domain or if you don't want to join your Linux system to the domain, there are workarounds.
Sync those passwords
One of the things you need to do when implementing Samba without an AD domain is to sync the passwords. On the Linux system, set your password to the same one that you use on your Windows systems (or on your domain). Remember that you have to use the
smbpasswd command to do this. The
passwd command is for Linux user accounts only and doesn't affect the Samba users' passwords.
Adding Samba users is actually a two-step process. First, you have to add the new user:
$ sudo smbpasswd -a mjones
And second, you need to enable the new user. This is the step that is most often forgotten:
$ sudo smbpasswd -e mjones
After that, change the Samba user's password with the
$ sudo smbpasswd mjones
There is a way to sync users and passwords using global configuration settings in the
/etc/samba/smb.conf file, but this option is beyond the scope of this article. There are other authors creating articles that will likely cover those configuration options.
[Related article: Linux capacity planning: 5 things you need to do.]
Match the domain or workgroup name
When you set up Samba, use the domain or workgroup name that your Windows systems use. The default workgroup name (SAMBA) probably isn't useful in a Windows environment. Matching the name will help you browse Windows systems and allow Windows systems to browse your Linux system's shares without issue.
Your Samba-enabled Linux system will also appear in domain computers' browse lists. Yet because this system is not a formal domain member, Windows admins won't be able to enforce policies or manage the system in any way. Someday I'll write the story of how I used Samba's features to drive a heavy-handed Windows admin to the brink and post it for your enjoyment. Until then, realize that you should get permission to configure your Linux system in this way.
Samba-enabled Linux systems look like Windows systems
If you have a properly configured Samba-enabled Linux system on your network, it's hard to distinguish it from Windows systems. You can even make your Linux system report itself as a Windows system by mimicking the Windows version of your choice. Most users won't know the difference, nor will they probably care that one or more of the systems they see in a network browse runs Linux.
Mapping drives to Samba shares
In the absence of an AD domain, you have to create a CMD (LOGIN.CMD, for example) file and place it into each user's Startup folder that maps drives to your Linux Samba file server. Good Windows administrators can implement mapped drives without touching each system. A simple PowerShell script can deploy the CMD file to every Windows system on the network. If you have a domain, you can create a Group Policy that maps the drives to a system and its shares. In either case, assume that for this example that your Linux file server is named FS1 and you have two shares: Public and Projects. Map drives in the usual way from your Windows computers:
NET USE P: \\FS1\Public NET USE Q: \\FS1\Projects
If everything is set up correctly, the drive will map without a password prompt, just as it would if you were using a Windows file server. Standard shares can be locked down to specific users or groups. Shares such as a Public drive are generally open with read and write access for everyone.
Administrative shares not included
Windows administrators will note that their beloved administrative shares (C$, D$, etc.) don't exist with Samba, nor should they. Sure, you can create administrative shares, but there's really no reason to do so unless you want to ruin your Linux system's security for some reason.
Setting up printer sharing via Samba is a fairly involved process. You have to create shares for the Windows drivers and for spooling print jobs, and you have to share each printer individually. When set up correctly, Samba printer sharing or serving works well. A full explanation of setting up printer sharing is beyond the scope of this article, but realize that it does work. Just be patient when setting this up, because the setup can be frustrating compared to Windows server setup, which is pretty much automatic.
Optional Samba features and deployment
Using Samba, your Linux system can become a browse master, a domain controller, or a domain member without any commercial software. Of course, the feature list will never fully compete with an actual Windows server, but for the cost savings and the general ease of setup you can't go wrong with Samba for integration with Windows systems.
To work with Windows, you only need to create the Samba-enabled Linux. In other words, once you have Samba set up, configured, and running there's nothing special that you have to do from a Windows system. From that standpoint, Samba is easy to implement and the only deployment is what you'd expect from a Windows server, in that there are no third-party agents to install or special configurations required to work with a Samba server.
Note: Because of the way browsing works on Windows networks, shares and systems might not appear for up to 45 minutes. Be patient and don't assume that anything is wrong when shares and systems don't immediately appear in a browse list.
[Check out what NFS has to offer: Getting started with NFS.]
For years, IT administrators have deployed tools to integrate Windows and Linux/Unix systems on corporate networks. NFS software for Windows, terminal emulation software for Windows, FTP clients, and SSH clients are/were common tools to deploy on Windows systems to communicate with these *nix systems. Samba, however, works pretty much out of the box. Samba also requires little computing overhead to work. Any Linux system can be used. First released in 1992, Samba has stood the test of time for proving its place in modern networks, and for providing no-cost interoperability to your heterogeneous environment. Now, let's dance!
[ Want to try out Red Hat Enterprise Linux? Download it now for free. ]