Documentation for a newer release is available. View Latest

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 root:

~]# 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

What Samba cannot do:

  • Act as a BDC for a Windows PDC (and vice versa)

  • Act as an Active Directory domain controller

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.

smbd

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.

nmbd

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.

winbindd

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.

Connecting to a Samba Share Using Nautilus

  1. To view a list of Samba workgroups and domains on your network, select Places    Network from the GNOME panel, and then select the desired network. Alternatively, type smb: in the File    Open Location bar of Nautilus.

    An icon appears for each available SMB workgroup or domain on the network.

    SMB Workgroups in Nautilus
    Figure 1. SMB Workgroups in Nautilus

  2. Double-click one of the workgroup or domain icon to view a list of computers within the workgroup or domain.

  3. An icon exists for each machine within the workgroup. Double-click on an icon to view the Samba shares on the machine. If a user name and password combination is required, you are prompted for them.

    Alternately, you can also specify the Samba server and sharename in the Location: bar for Nautilus using the following syntax (replace servername and sharename with the appropriate values):

    smb://servername/sharename

Connecting to a Samba Share Using the Command Line

  1. To connect to a Samba share from a shell prompt, type the following command:

    ~]$ smbclient //hostname/sharename -U username

    Replace hostname with the host name or IP address of the Samba server you want to connect to, sharename with the name of the shared directory you want to browse, and username with the Samba user name for the system. Enter the correct password or press Enter if no password is required for the user.

    If you see the smb:\> prompt, you have successfully logged in. Once you are logged in, type help for a list of commands. If you want to browse the contents of your home directory, replace sharename with your user name. If the -U switch is not used, the user name of the current user is passed to the Samba server.

  2. To exit smbclient, type exit at the smb:\> prompt.

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 root:

~]# 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 root:

~]# echo 0x37 > /proc/fs/cifs/SecurityFlags
This operation can expose passwords by removing password encryption.

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):

Example 1. An Example Configuration of a Samba Server
[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.

Encrypted Passwords

Encrypted passwords are enabled by default because it is more secure to use them. To create a user with an encrypted password, use the smbpasswd utility:

smbpasswd -a username

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 smb service. Also, it is recommended to run winbind before smbd.

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 /etc/samba/smb.conf file is changed, Samba automatically reloads it after a few minutes. Issuing a manual restart or reload is just as effective.

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.

Anonymous Read-Only

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.

Example 2. An Example Configuration of a Anonymous Read-Only Samba Server
[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
Anonymous Read/Write

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 (force user) and group (force group) in the /etc/samba/smb.conf file.
Example 3. An Example Configuration of a Anonymous Read/Write Samba Server
[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
Anonymous Print Server

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.

Example 4. An Example Configuration of a Anonymous Print Samba Server
[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
Secure Read/Write File and Print Server

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].

Example 5. An Example Configuration of a Secure Read/Write File and Print Samba Server
[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.

Active Directory Domain Member Server

To implement an Active Directory domain member server, follow procedure below:

Adding a Member Server to an Active Directory Domain

  1. 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 example realm = EXAMPLE.COM). Since Windows 2000/2003/2008 requires Kerberos for Active Directory authentication, the realm directive is required. If Active Directory and Kerberos are running on different servers, the password server directive is required to help the distinction.

  2. 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.

  3. 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 option

    Since security = ads and not security = user is used, a local password back end such as smbpasswd is not needed. Older clients that do not support security = ads are authenticated as if security = domain had been set. This change does not affect functionality and allows local users not previously in the domain.
Windows NT4-based Domain Member Server

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.

Example 6. An Example Configuration of Samba Windows NT4-based Domain Member 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 /etc/samba/smb.conf file, join the domain before starting Samba by typing the following command as root:

~]# 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.
Primary Domain Controller (PDC) Using 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.

Example 7. An Example Configuration of Primary Domain Controller (PDC) Using 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 =