File and Print Servers
This chapter guides you through the installation and configuration of Samba, an open source implementation of the Server Message Block (SMB) and common Internet file system (CIFS
) protocol, and vsftpd, the primary FTP server shipped with Fedora. Additionally, it explains how to use the Printer tool to configure printers.
Samba
Samba is the standard open source Windows interoperability suite of programs for Linux. It implements the server message block (SMB
) protocol. Modern versions of this protocol are also known as the common Internet file system (CIFS
) protocol. It allows the networking of Microsoft Windows, Linux, UNIX, and other operating systems together, enabling access to Windows-based file and printer shares. Samba’s use of SMB
allows it to appear as a Windows server to Windows clients.
Installing the samba package
In order to use Samba, first ensure the samba package is installed on your system by running, as ~]# dnf install samba For more information on installing packages with DNF, see Installing Packages. |
Introduction to Samba
Samba is an important component to seamlessly integrate Linux Servers and Desktops into Active Directory (AD) environments. It can function both as a domain controller (NT4-style) or as a regular domain member (AD or NT4-style). .What Samba can do:
-
Serve directory trees and printers to Linux, UNIX, and Windows clients
-
Assist in network browsing (with NetBIOS)
-
Authenticate Windows domain logins
-
Provide Windows Internet Name Service (
WINS
) name server resolution -
Act as a Windows NT-style Primary Domain Controller (PDC)
-
Act as a Backup Domain Controller (BDC) for a Samba-based PDC
-
Act as an Active Directory domain member server
-
Join a Windows NT/2000/2003/2008 PDC/Windows Server 2012
-
Act as a BDC for a Windows PDC (and vice versa)
-
Act as an Active Directory domain controller
Samba Daemons and Related Services
Samba is comprised of three daemons (smbd
, nmbd
, and winbindd
). Three services (smb
, nmb
, and winbind
) control how the daemons are started, stopped, and other service-related features. These services act as different init scripts. Each daemon is listed in detail below, as well as which specific service has control over it.
The smbd
server daemon provides file sharing and printing services to Windows clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the SMB
protocol. The default ports on which the server listens for SMB
traffic are TCP
ports 139 and 445.
The smbd
daemon is controlled by the smb
service.
The nmbd
server daemon understands and replies to NetBIOS name service requests such as those produced by SMB/CIFS in Windows-based systems. These systems include Windows 95/98/ME, Windows NT, Windows 2000, Windows XP, and LanManager clients. It also participates in the browsing protocols that make up the Windows Network Neighborhood
view. The default port that the server listens to for NMB
traffic is UDP
port 137
.
The nmbd
daemon is controlled by the nmb
service.
The winbind
service resolves user and group information received from a server running Windows NT, 2000, 2003, Windows Server 2008, or Windows Server 2012. This makes Windows user and group information understandable by UNIX platforms. This is achieved by using Microsoft RPC calls, Pluggable Authentication Modules (PAM), and the Name Service Switch (NSS). This allows Windows NT domain and Active Directory users to appear and operate as UNIX users on a UNIX machine. Though bundled with the Samba distribution, the winbind
service is controlled separately from the smb
service.
The winbind
daemon is controlled by the winbind
service and does not require the smb
service to be started in order to operate. winbind
is also used when Samba is an Active Directory member, and may also be used on a Samba domain controller (to implement nested groups and interdomain trust). Because winbind
is a client-side service used to connect to Windows NT-based servers, further discussion of winbind
is beyond the scope of this chapter.
Obtaining a list of utilities that are shipped with Samba
See Samba Distribution Programs for a list of utilities included in the Samba distribution. |
Connecting to a Samba Share
You can use either Nautilus or command line to connect to available Samba shares.
Mounting the Share
Sometimes it is useful to mount a Samba share to a directory so that the files in the directory can be treated as if they are part of the local file system.
To mount a Samba share to a directory, create a directory to mount it to (if it does not already exist), and execute the following command as root
:
mount -t cifs //servername/sharename /mnt/point/ -o username=username,password=password
This command mounts sharename from servername in the local directory /mnt/point/.
For more information about mounting a samba share, see the mount.cifs(8) manual page.
Installing cifs-utils package
The mount.cifs utility is a separate RPM (independent from Samba). In order to use mount.cifs, first ensure the cifs-utils package is installed on your system by running, as ~]# dnf install cifs-utils For more information on installing packages with DNF, see Installing Packages. Note that the cifs-utils package also contains the cifs.upcall binary called by the kernel in order to perform kerberized CIFS mounts. For more information on cifs.upcall, see the cifs.upcall(8) manual page. |
CIFS servers that require plain text passwords
Some CIFS servers require plain text passwords for authentication. Support for plain text password authentication can be enabled using the following command as ~]# echo 0x37 > /proc/fs/cifs/SecurityFlags
|
Configuring a Samba Server
The default configuration file (/etc/samba/smb.conf
) allows users to view their home directories as a Samba share. It also shares all printers configured for the system as Samba shared printers. You can attach a printer to the system and print to it from the Windows machines on your network.
Graphical Configuration
To configure Samba using a graphical interface, use one of the available Samba graphical user interfaces. A list of available GUIs can be found at https://www.samba.org/samba/GUI/.
Command-Line Configuration
Samba uses /etc/samba/smb.conf
as its configuration file. If you change this configuration file, the changes do not take effect until you restart the Samba daemon with the following command, as root
:
~]# systemctl restart smb.service
To specify the Windows workgroup and a brief description of the Samba server, edit the following lines in your /etc/samba/smb.conf
file:
workgroup = WORKGROUPNAME server string = BRIEF COMMENT ABOUT SERVER
Replace WORKGROUPNAME with the name of the Windows workgroup to which this machine should belong. The BRIEF COMMENT ABOUT SERVER is optional and is used as the Windows comment about the Samba system.
To create a Samba share directory on your Linux system, add the following section to your /etc/samba/smb.conf
file (after modifying it to reflect your needs and your system):
[sharename] comment = Insert a comment here path = /home/share/ valid users = tfox carole writable = yes create mask = 0765
The above example allows the users tfox and carole to read and write to the directory /home/share/
, on the Samba server, from a Samba client.
Starting and Stopping Samba
To start a Samba server, type the following command in a shell prompt, as root
:
~]# systemctl start smb.service
Setting up a domain member server
To set up a domain member server, you must first join the domain or Active Directory using the net join command before starting the |
To stop the server, type the following command in a shell prompt, as root
:
~]# systemctl stop smb.service
The restart
option is a quick way of stopping and then starting Samba. This is the most reliable way to make configuration changes take effect after editing the configuration file for Samba. Note that the restart option starts the daemon even if it was not running originally.
To restart the server, type the following command in a shell prompt, as root
:
~]# systemctl restart smb.service
The condrestart
(conditional restart) option only starts smb
on the condition that it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running.
Applying the changes to the configuration
When the |
To conditionally restart the server, type the following command, as root
:
~]# systemctl try-restart smb.service
A manual reload of the /etc/samba/smb.conf
file can be useful in case of a failed automatic reload by the smb
service. To ensure that the Samba server configuration file is reloaded without restarting the service, type the following command, as root
:
~]# systemctl reload smb.service
By default, the smb
service does not start automatically at boot time. To configure Samba to start at boot time, type the following at a shell prompt as root
:
~]# systemctl enable smb.service
See Services and Daemons for more information regarding this tool.
Samba Server Types and the smb.conf
File
Samba configuration is straightforward. All modifications to Samba are done in the /etc/samba/smb.conf
configuration file. Although the default smb.conf
file is well documented, it does not address complex topics such as LDAP, Active Directory, and the numerous domain controller implementations.
The following sections describe the different ways a Samba server can be configured. Keep in mind your needs and the changes required to the /etc/samba/smb.conf
file for a successful configuration.
Stand-alone Server
A stand-alone server can be a workgroup server or a member of a workgroup environment. A stand-alone server is not a domain controller and does not participate in a domain in any way. The following examples include several user-level security configurations. For more information on security modes, see Samba Security Modes.
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement anonymous read-only file sharing. Two directives are used to configure anonymous access – map to guest = Bad user
and guest account = nobody
.
[global] workgroup = DOCS netbios name = DOCS_SRV security = user guest account = nobody # default value map to guest = Bad user [data] comment = Documentation Samba Server path = /export read only = yes guest ok = yes
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement anonymous read/write file sharing. To enable anonymous read/write file sharing, set the read only
directive to no
. The force user
and force group
directives are also added to enforce the ownership of any newly placed files specified in the share.
Do not use anonymous read/write servers
Although having an anonymous read/write server is possible, it is not recommended. Any files placed in the share space, regardless of user, are assigned the user/group combination as specified by a generic user ( |
[global] workgroup = DOCS security = user guest account = nobody # default value map to guest = Bad user [data] comment = Data path = /export guest ok = yes writeable = yes force user = user force group = group
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement an anonymous print server. Setting browseable
to no
as shown does not list the printer in Windows Network Neighborhood
. Although hidden from browsing, configuring the printer explicitly is possible. By connecting to DOCS_SRV
using NetBIOS, the client can have access to the printer if the client is also part of the DOCS
workgroup. It is also assumed that the client has the correct local printer driver installed, as the use client driver
directive is set to yes
. In this case, the Samba server has no responsibility for sharing printer drivers to the client.
[global] workgroup = DOCS netbios name = DOCS_SRV security = user map to guest = Bad user printing = cups [printers] comment = All Printers path = /var/spool/samba guest ok = yes printable = yes use client driver = yes browseable = yes
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement a secure read/write file and print server. Setting the security
directive to user
forces Samba to authenticate client connections. Notice the [homes]
share does not have a force user
or force group
directive as the [public]
share does. The [homes]
share uses the authenticated user details for any files created as opposed to the force user
and force group
in [public]
.
[global] workgroup = DOCS netbios name = DOCS_SRV security = user printcap name = cups disable spools = yes show add printer wizard = no printing = cups [homes] comment = Home Directories valid users = %S read only = no browseable = no [public] comment = Data path = /export force user = docsbot force group = users guest ok = yes [printers] comment = All Printers path = /var/spool/samba printer admin = john, ed, @admins create mask = 0600 guest ok = yes printable = yes use client driver = yes browseable = yes
Domain Member Server
A domain member, while similar to a stand-alone server, is logged into a domain controller (either Windows or Samba) and is subject to the domain’s security rules. An example of a domain member server would be a departmental server running Samba that has a machine account on the Primary Domain Controller (PDC). All of the department’s clients still authenticate with the PDC, and desktop profiles and all network policy files are included. The difference is that the departmental server has the ability to control printer and network shares.
To implement an Active Directory domain member server, follow procedure below:
-
Create the
/etc/samba/smb.conf
configuration file on a member server to be added to the Active Directory domain. Add the following lines to the configuration file:[global] realm = EXAMPLE.COM security = ADS encrypt passwords = yes # Optional. Use only if Samba cannot determine the Kerberos server automatically. password server = kerberos.example.com
With the above configuration, Samba authenticates users for services being run locally but is also a client of the Active Directory. Ensure that your kerberos
realm
parameter is shown in all caps (for examplerealm = EXAMPLE.COM
). Since Windows 2000/2003/2008 requires Kerberos for Active Directory authentication, therealm
directive is required. If Active Directory and Kerberos are running on different servers, thepassword server
directive is required to help the distinction. -
Configure Kerberos on the member server. Create the
/etc/krb5.conf
configuration file with the following content:[logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = AD.EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d rdns = false forwardable = false [realms] # Define only if DNS lookups are not working # AD.EXAMPLE.COM = { # kdc = server.ad.example.com # admin_server = server.ad.example.com # master_kdc = server.ad.example.com # } [domain_realm] # Define only if DNS lookups are not working # .ad.example.com = AD.EXAMPLE.COM # ad.example.com = AD.EXAMPLE.COM
Uncomment the
[realms]
and[domain_realm]
sections if DNS lookups are not working.For more information on Kerberos, and the /etc/krb5.conf file, see the Using Kerberos section of the Red Hat Enterprise Linux 7 System Level Authentication Guide.
-
To join an Active Directory server, type the following command as
root
on the member server:~]# net ads join -U administrator%password
The net command authenticates as
Administrator
using the NT LAN Manager (NTLM) protocol and creates the machine account. Then net uses the machine account credentials to authenticate with Kerberos.The security optionSince
security = ads
and notsecurity = user
is used, a local password back end such assmbpasswd
is not needed. Older clients that do not supportsecurity = ads
are authenticated as ifsecurity = domain
had been set. This change does not affect functionality and allows local users not previously in the domain.
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement a Windows NT4-based domain member server. Becoming a member server of an NT4-based domain is similar to connecting to an Active Directory. The main difference is NT4-based domains do not use Kerberos in their authentication method, making the /etc/samba/smb.conf
file simpler. In this instance, the Samba member server functions as a pass through to the NT4-based domain server.
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = no browseable = no [public] comment = Data path = /export force user = docsbot force group = users guest ok = yes
Having Samba as a domain member server can be useful in many situations. There are times where the Samba server can have other uses besides file and printer sharing. It may be beneficial to make Samba a domain member server in instances where Linux-only applications are required for use in the domain environment. Administrators appreciate keeping track of all machines in the domain, even if not Windows-based. In the event the Windows-based server hardware is deprecated, it is quite easy to modify the /etc/samba/smb.conf
file to convert the server to a Samba-based PDC. If Windows NT-based servers are upgraded to Windows 2000/2003/2008 the /etc/samba/smb.conf
file is easily modifiable to incorporate the infrastructure change to Active Directory if needed.
Make sure you join the domain before starting Samba
After configuring the ~]# net rpc join -U administrator%password |
Note that the -S
option, which specifies the domain server host name, does not need to be stated in the net rpc join command. Samba uses the host name specified by the workgroup
directive in the /etc/samba/smb.conf
file instead of it being stated explicitly.
Domain Controller
A domain controller in Windows NT is functionally similar to a Network Information Service (NIS) server in a Linux environment. Domain controllers and NIS servers both host user and group information databases as well as related services. Domain controllers are mainly used for security, including the authentication of users accessing domain resources. The service that maintains the user and group database integrity is called the Security Account Manager (SAM). The SAM database is stored differently between Windows and Linux Samba-based systems, therefore SAM replication cannot be achieved and platforms cannot be mixed in a PDC/BDC environment.
In a Samba environment, there can be only one PDC and zero or more BDCs.
A mixed Samba/Windows domain controller environment
Samba cannot exist in a mixed Samba/Windows domain controller environment (Samba cannot be a BDC of a Windows PDC or vice versa). Alternatively, Samba PDCs and BDCs can coexist. |
tdbsam
The simplest and most common implementation of a Samba PDC uses the new default tdbsam
password database back end. Replacing the aging smbpasswd
back end, tdbsam
has numerous improvements that are explained in more detail in Samba Account Information Databases. The passdb backend
directive controls which back end is to be used for the PDC.
The following /etc/samba/smb.conf
file shows a sample configuration needed to implement a tdbsam
password database back end.
tdbsam
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = tdbsam security = user add user script = /usr/sbin/useradd -m "%u" delete user script = /usr/sbin/userdel -r "%u" add group script = /usr/sbin/groupadd "%g" delete group script = /usr/sbin/groupdel "%g" add user to group script = /usr/sbin/usermod -G "%g" "%u" add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines "%u" # The following specifies the default logon script # Per user logon scripts can be specified in the user # account using pdbedit logon script = logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon drive = H: domain logons = yes os level =