Samba is a powerful suite of applications that provides an open source implementation of the Server Message Block/Common Internet File System (SMB/CIFS) protocol. Among other things, Samba helps Linux-based systems interoperate with Windows-based operating systems.
Samba transparently provides file and print sharing services to Windows clients as well as other networked clients running other operating systems. It does this through the use of the native Microsoft networking protocols SMB/CIFS. From a system administrator’s point of view, this means you can deploy a Linux-based server and use it to provide file-sharing, authentication, print, and other services to other non-native Linux clients such as Microsoft Windows systems. Using Samba means that Windows systems can use their native tongue to talk to the Linux server—which means fewer hassles for you and seamless integration for your users.
This chapter covers the procedure for downloading, compiling, and installing Samba. As with any software of its caliber, Samba provides a rich set of configuration options that makes it suitable and flexible for use in various environments. And, thankfully, you should be able to get Samba up and running with very few changes to the default configuration. We’ll concentrate on how to perform customary tasks with Samba and how to avoid some common Samba pitfalls. We’ll also provide brief coverage of some common command-line utilities such as
No matter what task you’ve chosen for Samba to handle, be sure to take the time to read the program’s documentation. It is well written, complete, and thorough.
NOTE Samba has been ported to a significant number of platforms and almost any variant of UNIX you can imagine, and even several non-UNIX environments.
The Mechanics of SMB
For a complete understanding of the Linux/Samba/Windows relationship, you need to understand the relationships of the operating systems to their files, printers, users, and networks. To see how these relationships compare, let’s examine some of the fundamental issues of working with both Linux-based systems and Windows in the same environment.
Usernames and Passwords
The Linux login/password mechanism is radically different from the Windows Active Directory model, which uses domain controllers (DCs). For interoperability, it is important for the system administrator to maintain consistency in the logins and passwords across both platforms. Users may need to work in heterogeneous environments and may need access to the different platforms for various reasons. It is thus useful to make working in such environments as seamless as possible without having to worry about users’ needing to reauthenticate separately on the different platforms, worry about cached passwords that don’t match between servers, and so on.
Relative to Samba, several options are available for handling username and password issues in heterogeneous environments, including the following:
• Linux pluggable authentication modules (PAMs) Allow you to authenticate users against a DC. This means you still have two user lists—one local and one on the DC—but your users need to keep track of their passwords only on the Windows system.
• Samba as a DC Allows you to keep all your logins and passwords on the Linux system, while all your Windows boxes authenticate with Samba. When Samba is used with a Lightweight Directory Access Protocol (LDAP) back-end for this, you will have a scalable and extensible solution.
• Custom script Allows you to use your own custom script. For sites with a well-established system for maintaining logins and passwords, it isn’t unreasonable to come up with a custom script. This can be done using a scripting language with good cross-platform support. Such scripts can be coaxed to allow changes to the Security Access Manager (SAM) to update the DC’s password list. For example, a Perl or Python script on the Linux side can communicate with a Perl or Python script on the Windows side to keep accounts synchronized. (Both Perl and Python have been successfully ported to work on Windows platforms through various mechanisms.)
In the worst-case situation, you can always maintain the username and password databases of the different platforms by hand (which some early system admins did indeed have to do!), but this method is error-prone and not much fun to manage.
Windows-based systems use encrypted passwords when communicating with the DC and any server requiring authentication (including Linux and Samba). The encryption algorithm used by Windows is different from Linux’s, however, and, therefore, is not compatible.
Here are your choices for handling this conflict:
• Edit the Registry on Windows clients to disable the use of encrypted passwords. The Registry entries that need to be changed are listed in the docs directory in the Samba package. As of version 3 of Samba, this option is no longer necessary.
• Configure Samba to use Windows-style encrypted passwords.
The first solution has the benefit of not pushing you to a more complex password scheme. On the other hand, you may have to apply the Registry fix on all your clients. The second option, of course, has the opposite effect: for a little more complexity on the server side, you don’t have to modify any of your clients.
The Samba code is actually composed of several components and daemons. We will examine three of the main daemons here: smbd, nmbd, and winbindd.
The smbd daemon handles the actual sharing of file systems and printer services for clients. It is also responsible for user authentication and resource-locking issues. It starts by binding to port 139 or 445 and then listens for requests. Every time a client authenticates itself, smbd makes a copy of itself; the original goes back to listening to its primary port for new requests, and the copy handles the connection for the client. This new copy also changes its effective user ID from root to the authenticated user. For example, if the user yyang authenticated against smbd, the new copy would run with the permissions of yyang, not the permissions of root. The copy stays in memory as long as there is a connection from the client.
The nmbd daemon is responsible for handling NetBIOS name service requests. nmbd can also be used as a drop-in replacement for a Windows Internet Name Server (WINS). It begins by binding itself to port 137; unlike smbd, however, nmbd does not create a new instance of itself to handle every query. In addition to name service requests, nmbd handles requests from master browsers, domain browsers, and WINS servers—and as such, it participates in the network resource browsing protocols. The services provided by the smbd and nmbd daemons complement each other.
Finally, the service provided by winbindd can be used to query native Windows servers for user and group information, which can then be used on purely Linux/UNIX platforms. It does this by using Microsoft Remote Procedure Call (RPC) calls, PAM, and the name service switch (NSS) capabilities found in modern C libraries. Its use can be extended through the use of a PAM module (pam_winbind) to provide authentication services. This service is controlled separately from the main smb service and can run independently.
NOTE With the advent of Microsoft’s Active Directory, you shouldn’t need the services of nmbd anymore, but the reality is that you will, especially if you intend to allow very old Windows hosts on your network to access your Samba shares.
Installing Samba via RPM
Precompiled binaries for Samba exist for most Linux distributions. This section will show how to install Samba on Red Hat Package Manager (RPM) based distros like Fedora, RHEL, CentOS, and so on. To provide the server-side services of Samba, three packages are needed:
• samba*.rpm This package provides an SMB server that can be used to provide network services to SMB/CIFS clients.
• samba-common*.rpm This package provides files necessary for both the server and client packages of Samba—such as configuration files, log files, man pages, PAM modules, and other libraries.
• samba-client*.rpm This package provides the SMB client utilities that allow access to SMB shares and printing services on Linux and non-Linux–type systems. The package is used on Fedora, openSUSE, and other RHEL-type systems.
Assuming you have a working connection to the Internet, installing Samba can be as simple as issuing this command:
Install the samba-common-tools package by running the following:
You can similarly install the samba-client package like so:
Installing Samba via APT
The essential components of the Samba software on Debian-like distros, such as Ubuntu, are split into samba*.deb and samba-common*.deb packages. Getting the client and server components of Samba installed in Ubuntu is as easy as running this:
As with installing most other services under Ubuntu, the installer will automatically start the Samba daemons after installation.
This section describes some typical Samba administrative functions. You’ll learn how to start and stop Samba, how to perform common administrative tasks with Samba, how to use
smbclient, and so on.
Starting and Stopping Samba
On our sample systemd-enabled Linux server, the
systemctl utility can be used to manage Samba’s startup and shutdown.
For example, to start the smbd daemon, you can execute this command:
And to stop the service, type this:
After making any configuration changes to Samba, you can restart it with this command to make the changes go into effect:
Out of the box, the smb service might not automatically start up with the next system reboot. You can use the
systemctl command on modern Linux distros to make sure that the smb service unit is enabled to automatically start up when the system boots, as follows:
TIP Debian-based distros such as Ubuntu refer to the Samba daemon service unit as smbd instead of smb, which is used in the RPM world. Therefore, to start the Samba service in Ubuntu, you would instead type the following:
Creating a Share
We will walk through the process of creating a share under the /tmp directory to be shared on the Samba server. We’ll first create the directory to be shared and then edit Samba’s configuration file (/etc/samba/smb.conf) to create an entry for the share.
If you have any of the graphical desktop environments installed and running, you can often use some tools built into the environment to complete simple file-sharing tasks for Samba or use any of the available web-based utilities to manage your Samba server. However, it is useful for you to understand how to configure Samba in its rawest form, which makes it easier to understand what the GUI tools are doing in the back-end. Besides, you never know when you might be stranded in the Amazon jungle without any nice GUI configuration tools. So let’s get on with it:
1. Create a directory under the /tmp/ folder called testshare:
2. Create some empty files (foo1, foo2, moo3) under the directory you created in step 1:
3. Set up the permissions on the testshare folder so that its contents can be browsed by other users on the system:
4. As an administrator, open up Samba’s configuration file (/etc/samba/smb.conf) for editing in any text editor of your choice. Then scroll all the way to the end of the file and append the entry listed next at the bottom of the file. (Please omit the line numbers 1–5, which are added only to aid readability.)
• Line 1 is the name of the share (or “service” in Samba parlance). This is the name that SMB clients will see when they try to browse the shares stored on the Samba server.
• Line 2 is just a comment that users will see next to a share when browsing.
• Line 3 is important. It specifies the location on the file system that stores the actual content to be shared.
• Line 4 specifies that no password is required to access the share (access the share means “connecting to the service” in Samba-speak). The privileges on the share will be translated to the permissions of the guest account. If the value were set to
no instead, the share would not be accessible by the general public but by authenticated and permitted users only.
• Line 5, with the value of the directive set to
no, means that users of this service may not create or modify the files stored therein.
TIP Samba’s configuration file has options and directives that are too numerous to cover here. But you can learn more about the other possible options by reading the man page for smb.conf (
5. Save your changes to the /etc/samba/smb.conf file and then exit the editor.
Note that we have accepted all the other default values in the file. You may want to go back and personalize some of the settings to suit your environment.
One setting you might want to change quickly is the
workgroup directive, which defines the workgroup. It controls what workgroup your server will appear to be in when queried by clients or when viewed in Windows network browser.
Also note that the default configuration may contain other share definitions. You should comment out (or delete) those entries if it is not your intention to include them.
6. Use the
testparm utility to check the smb.conf file for internal correctness (that is, absence of syntax errors). Study the output for any serious errors, and try to fix them by going back to correct them in the smb.conf file. Type the following:
7. Now restart (or start) Samba to make the software acknowledge your changes. You can use the
systemctl command to restart the smb server (on an RPM-based distro like Fedora) by typing this:
We are done creating our test share. In the next section, we’ll attempt to access the share.
TIP On a system with SELinux running in enforcing mode (such as Fedora, RHEL, CentOS, and so on), you might need to properly label (with the correct security context) new files and directories on the Samba server to allow the remote clients to mount and access the Samba shares remotely.
To permanently label a directory so that SELinux allows Samba to read and write to it (on behalf of clients), you have to label it with the
samba_share_t SELinux context. Use the
semanage command to add a new SELinux record to do this, which for our example is the /tmp/testshare directory:
To immediately apply the SELinux label that you just created to the /tmp/testshare directory and its content, use the
restorecon command, like this:
TIP On older versions (pre-systemd) of Debian-based distributions, (such as Ubuntu) you can restart the smb daemon by running the following:
smbclient program is a command-line tool that provides FTP-like access to SMB/CIFS resources. You can use this utility to connect to Samba servers or even to actual Microsoft Windows servers.
smbclient is a flexible program and can be used to browse other servers, send and retrieve files from them, or even print to them. As you can imagine, this is also a great debugging tool, since you can quickly and easily check whether a new Samba installation works correctly without having to find a Windows client to test it.
In this section, we’ll show you how to do basic browsing, remote file access, and remote printer access with
smbclient program is packaged separately in Ubuntu. You’ll have to install it explicitly by running a command like the following:
Browsing a Server
With so many graphical interfaces around, we’ve come to equate browsing with “point-and-click.” But when your intention is simply to find out what a server has to offer, it’s not enough of a reason in itself to support or run an entire GUI stack.
smbclient with the
-L option allows you to view the service offerings of a Windows file server or Samba server. Here’s the format of the command:
hostname is the name of the server. For example, if we want to see what the local host (the Samba service running locally) has to offer, we type this:
You will be prompted for a password, but you can press ENTER to complete the command.
To list the shares on the Samba server again without being prompted for a password, you can use the
-N) option. This implies that you want to be authenticated as the guest user, which has no password. Type the following:
Notice the presence of the share we created earlier in line 4 of the preceding output.
Remote File Access
smbclient utility allows you to access files on a Windows server or a Samba server with a command-line hybrid UNIX/FTP client interface.
For its most straightforward usage, you’ll simply run the following:
server is the server name (or IP address) and
share_name is the share name to which you want to connect. By default, Samba automatically sets up all users’ home directories as shares. For instance, the user yyang can access her home directory on the server named fedora-server by browsing //fedora-server/yyang.
TIP Watch out for the orientation of the / (forward slash) character used with the
smbclient command to specify the server and share names! If you are used to doing similar things in Windows environments, you might absentmindedly use the \ (backslash) character instead!
The following are some command-line parameters you might need to use with smbclient to connect to a server:
Once connected, you’ll be able to browse directories using the
commands. You can also use
mput to transfer files back and forth. The online help explains the commands in detail. Type help at the prompt to see what is available.
TIP If your Samba server has a host-based or network-based firewall protecting it, don’t forget to open the necessary ports to allow external systems to access the Samba services running on your server.
On Red Hat–like systems such as Fedora that use firewalld, you can temporarily punch a hole in the host-based firewall by running this:
And on Debian-like systems such as Ubuntu that use the Uncomplicated Firewall (UFW) to manage host-based firewall rules, you can instead run this:
Let’s attempt an actual connection to the share we created earlier (samba-share). To demonstrate the process, the connection will be made from a different host named clientB.
We’ll use the
smbclient utility to connect to the server, connecting as a guest by specifying the
-U% option. After connecting, we will be dropped down to an smb shell with the prompt
While we’re connected, we’ll do a listing of the files available on the share using the
ls command. Then we’ll try to download one of the files that resides on the share using the FTP-like command
Finally, we’ll end the connection using
quit. A sample session on clientB connecting to the host, serverA, is shown here:
The file (foo2) that was downloaded from serverA should be in the current working directory on the local file system of clientB.
TIP If you can’t access the shares on your Samba server on Red Hat–like distros such as Fedora, it is possible that the SELinux security subsystem is getting in the way. To troubleshoot, you can temporarily put SELinux in permissive mode to eliminate it as being the cause of any issues. You can do this by running the following:
# setenforce 0
Mounting Remote Samba Shares
If your kernel is configured to support the SMB file system (as are most kernels that come with modern Linux distributions), you can actually mount a Windows share or Samba share onto your local system in much the same way you would mount an NFS export or a local volume. This is handy for providing easy access to a large disk/storage on a remote server across the network.
While logged into clientB, you can use the
mount command with the proper options to mount a Samba share that resides on serverA.
1. First, create the mount point if it does not exist:
2. Then run the mount.cifs command (via mount -t cifs) to do the actual mounting:
Here, //serverA/samba-share is the remote share being mounted, and /mnt/smb is the local mount point.
If the remote share that you want to mount is protected with a username/password combination, you can supply the username/password along with the
mount command like this example using the user yyang’s account:
To unmount this directory, use the
On Debian-based distros such as Ubuntu, you might have to install the cifs-utils package, if it is not already installed, so that you can use the
mount.cifs command (via
mount -t cifs). This can be done by running this command:
When configured to do so, Samba will honor requests from users that are stored in other databases that it knows about. The user databases can, in turn, be stored in various back-ends such as LDAP (ldapsam) and Trivial database (tdbsam). Versions of Samba earlier than version 3.0.23 also supported exotic back-ends such as XML (xmlsam) and MySQL (mysqlsam).
Here, we will add a sample user that already exists in the local /etc/passwd file to Samba’s user database. We will accept and use Samba’s native/default user database back-end (tdbsam) for demonstration purposes.
Creating Samba Users
Let’s create a Samba entry for an existing user (yyang). We will also set the user’s Samba password.
pdbedit command to create a Samba entry for the user yyang, and choose a good password when prompted to do so:
The new user will be created in Samba’s default user database, tdbsam. On Red Hat–like distros, the database file is /var/lib/samba/private/passdb.tdb.
With a Samba user created, you can make the shares available only to authenticated users, such as the one we just created for the user yyang.
If the user yyang now wants to access a resource on the Samba server that has been configured strictly for her use (a protected share or nonpublic share), the user can issue the
smbclient command shown here, for example:
It is, of course, also possible to access a protected Samba share from a native Microsoft Windows box. You’ll need to supply the proper Samba username and corresponding password when prompted on the Windows system.
Allowing Null Passwords
If you need to allow users to have no passwords (which is a bad idea, by the way, but for which you might have a legitimate use case), you can do so by using the
pdbedit program with the
-c option to set the “No password required (N)” flag, like so:
username is the name of the user whose password you want to set to empty.
For example, to allow the user yyang to access a share on the Samba server with a null password, type the following:
You can also do this by using the
smbpasswd program, like this:
Changing Passwords with smbpasswd
Users who prefer the command line over the GUI tools can use the
smbpasswd command to change their Samba passwords. This program works just like the regular
passwd program, except this program does not update the /etc/passwd file by default; instead, it updates Samba’s user/password database.
smbpasswd uses the standard Windows protocol/semantics for communicating with the server regarding password changes. Therefore, by using the right combination of parameters and options, you can coax the tool into changing a user password on a remote native Windows server—from a Linux-based host!
To change the user yyang’s Samba password, issue this command:
Samba can be configured to allow regular users to run the
smbpasswd command themselves to manage their own passwords; the only caveat is that they must know their previous/old password.
TIP You can also use the
pdbedit tool to change a user’s Samba password. For example, to update the user yyang’s Samba password using
Using Samba to Authenticate Against a Windows Server
Thus far, we’ve been talking about using Samba in the Samba/Linux world. Or, to put it literarily, we’ve been using Samba in its native environment, where it is lord and master of its domain (no pun intended). What this means is that our Samba software stack, in combination with the Linux-based server, has been responsible for managing all user authentication and authorization issues.
The simple Samba setup that we created earlier in the chapter had its own user database, which mapped the Samba users to real Linux/UNIX users. This allowed any files and directories created by Samba users to have the proper ownership contexts. But what if we wanted to deploy a Samba server in an environment with existing Windows servers that are being used to manage all users in the domain? And we don’t want to have to manage a separate user database in Samba? Enter the winbindd daemon!
NOTE Samba 4 is the latest and next-generation version of Samba. Among its many enhancements, Samba 4 implements an Active Directory (AD) compatible domain controller. It natively supports AD logon and administrative protocols (Kerberos, LDAP, RPC, and so on). This means that all current Windows clients can be transparently joined to a Samba 4 domain running on a Linux/UNIX-based Samba 4 server, and they will behave exactly as they would if they were members of native Windows AD domain.
The winbindd daemon is used for resolving user accounts (users and groups) information from native Windows servers. It can also be used to resolve other kinds of system information. It is able to do this through its use of pam_winbind (a PAM module that interacts with the winbindd daemon to help authenticate users), libnss_winbind (winbind’s Name Service Switch library) facility, and other relevant subsystems.
The process of setting up a Linux-based machine to consult a Windows server for its user authentication needs is also referred to as setting up Samba as a member server in an AD environment.
The steps to achieve this are straightforward and can be summarized in this way:
1. Install the winbind software if it isn’t already installed.
2. Configure Samba’s configuration file (smb.conf) with the proper directives.
3. Add winbind to the Linux system’s name service switch facility (/etc/nsswitch.conf).
4. Join the Linux/Samba server to the Windows domain.
5. Test things out!
Here we present a sample scenario in which a Linux server named serverA will use a Windows server for its user authentication needs. The Samba server is going to act as a Windows domain member server.
The Windows server in this scenario is configured as a domain controller. Its hostname is win-server and its IP address is 192.168.1.100. The short Windows domain name is WINDOWS-DOMAIN.
We have deliberately excluded any share definitions in this sample Samba configuration, and as such you’ll have to create or specify your own (if you require it; see the earlier parts of the chapter for how to do this). Let’s break down the process in better detail:
1. Install the winbind package if it isn’t already installed. On RPM-based systems such as Fedora, CentOS, and openSUSE, you can install it by issuing this command:
On a Debian-based distro such as Ubuntu, you can install the package using this command:
2. Create an /etc/samba/smb.conf file similar to this one:
3. Edit the /etc/nsswitch.conf file on the Linux server so that it will have entries similar to this one:
4. You will need to tell whatever subsystem (NetworkManager, systemd-resolved, Resolvconf, and so on) is in charge of managing your network name resolution routines your DNS search order and your name server.
In other words, you want to tell your resolver routines that the remote Windows server is the primary DNS server and the domain search suffix matches the name of the Windows AD realm. The /etc/resolv.conf file or its equivalent should have entries similar to this:
5. Join the Samba server to the Windows domain using the net command. Assuming the Windows Domain Administrator account password is windows_administrator_password, type the following:
6. On Red Hat–like systems, you can use the
authselect utility to configure the other necessary user information and authentication sources. Launch the tool from the command line, pass it the
winbindd option, and then apply the changes:
Apply the changes by running the following:
7. On Linux distributions using systemd as the service manager, you can start the winbind daemon and enable it’s auto-startup using the
8. Use the
wbinfo utility (provided with the samba-winbind-clients*.rpm package) to list all users available in the Windows domain to make sure that things are working properly:
$ wbinfo -u
That’s it. The Linux server will now be able to consult and query the Windows Server for its user authentication needs.
The following are a few typical solutions to simple problems you might encounter with Samba:
• Restart Samba. This might be necessary because either Samba has entered an undefined state or (more likely) you’ve made major changes to the configuration but forgot to reload Samba so that the changes take effect.
• Make sure the configuration options are correct. Errors in the smb.conf file are typically in directory names, usernames, network addresses, and hostnames. A common mistake occurs when a new client is added to a group that has special access to the server, but Samba isn’t told the name of the new client being added. Don’t forget that for syntax-type errors, the
testparm utility is your ally.
• Log files. Samba can be configured to generate as few or as many logs as you want, and with varying levels of detail. The log files are your friend when troubleshooting Samba issues. Most distros store Samba-specific log files under the /var/log/samba/ directory. Keep a watchful eye on the logs! You can also use the journalctl utility to view logs.
This chapter discussed the process of installing, configuring, and managing Samba so that your Linux-based server can integrate with a Windows-based network. Samba is a powerful application with the potential to replace Microsoft Windows servers dedicated to file and printer sharing and authentication services.
Reading through tons of documentation probably isn’t your favorite way to pass the time, but you’ll find the Samba documentation (https://wiki.samba.org) complete, helpful, and easy reading. At least skim through the files to see what’s there, so you know where you can go to get additional information when you need it. With all the Samba texts available today (some free, some not), you should have everything you need to manage even the most complicated Samba environments.