File and Print Servers

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

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:

To specify the Windows workgroup and a brief description of the Samba server, edit the following lines in your /etc/samba/smb.conf file:

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

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 are enabled by default because it is more secure to use them. To create a user with an encrypted password, use the smbpasswd utility:

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

To provide a functional PDC system which uses tdbsam follow these steps:

Keep in mind that Windows systems prefer to have a primary group which is mapped to a domain group such as Domain Users.

Windows groups and users use the same namespace thus not allowing the existence of a group and a user with the same name like in UNIX.

Although it is possible for Samba to be a member of an Active Directory, it is not possible for Samba to operate as an Active Directory domain controller.

User-level security is the default and recommended setting for Samba. Even if the security = user directive is not listed in the /etc/samba/smb.conf file, it is used by Samba. If the server accepts the client’s user name and password, the client can then mount multiple shares without specifying a password for each instance. Samba can also accept session-based user name and password requests. The client maintains multiple authentication contexts by using a unique UID for each logon.

In the /etc/samba/smb.conf file, the security = user directive that sets user-level security is:

As mentioned above, share-level security mode is deprecated. To configure a Samba guest share without using the security = share parameter, follow the procedure below:

The following sections describe other implementations of user-level security.

In domain security mode, the Samba server has a machine account (domain security trust account) and causes all authentication requests to be passed through to the domain controllers. The Samba server is made into a domain member server by using the following directives in the /etc/samba/smb.conf file:

If you have an Active Directory environment, it is possible to join the domain as a native Active Directory member. Even if a security policy restricts the use of NT-compatible authentication protocols, the Samba server can join an ADS using Kerberos. Samba in Active Directory member mode can accept Kerberos tickets.

In the /etc/samba/smb.conf file, the following directives make Samba an Active Directory member server:

With share-level security, the server accepts only a password without an explicit user name from the client. The server expects a password for each share, independent of the user name. There have been recent reports that Microsoft Windows clients have compatibility issues with share-level security servers. This mode is deprecated and has been removed from Samba. Configurations containing security = share should be updated to use user-level security. Follow the steps in Configuring Samba Guest Shares to avoid using the security = share directive.

By default, a Windows server PDC for a domain is also the domain master browser for that domain. A Samba server must not be set up as a domain master server in this type of situation.

For subnets that do not include the Windows server PDC, a Samba server can be implemented as a local master browser. Configuring the /etc/samba/smb.conf file for a local master browser (or no browsing at all) in a domain controller environment is the same as workgroup configuration (see Configuring a Samba Server).

Either a Samba server or a Windows NT server can function as a WINS server. When a WINS server is used with NetBIOS enabled, UDP unicasts can be routed which allows name resolution across networks. Without a WINS server, the UDP broadcast is limited to the local subnet and therefore cannot be routed to other subnets, workgroups, or domains. If WINS replication is necessary, do not use Samba as your primary WINS server, as Samba does not currently support WINS replication.

In a mixed NT/2000/2003/2008 server and Samba environment, it is recommended that you use the Microsoft WINS capabilities. In a Samba-only environment, it is recommended that you use only one Samba server for WINS.

The following is an example of the /etc/samba/smb.conf file in which the Samba server is serving as a WINS server:

The following example shows a very basic /etc/samba/smb.conf configuration for CUPS support:

Other printing configurations are also possible. To add additional security and privacy for printing confidential documents, users can have their own print spooler not located in a public path. If a job fails, other users would not have access to the file.

The print$ directive contains printer drivers for clients to access if not available locally. The print$ directive is optional and may not be required depending on the organization.

Setting browseable to yes enables the printer to be viewed in the Windows Network Neighborhood, provided the Samba server is set up correctly in the domain or workgroup.

Unlike most protocols used on the Internet, FTP requires multiple network ports to work properly. When an FTP client application initiates a connection to an FTP server, it opens port 21 on the server — known as the command port. This port is used to issue all commands to the server. Any data requested from the server is returned to the client via a data port. The port number for data connections, and the way in which data connections are initialized, vary depending upon whether the client requests the data in active or passive mode.

The following defines these modes:

The Very Secure FTP Daemon (vsftpd) is designed from the ground up to be fast, stable, and, most importantly, secure. vsftpd is the only stand-alone FTP server distributed with Fedora, due to its ability to handle large numbers of connections efficiently and securely.

The security model used by vsftpd has three primary aspects:

Use of these security practices has the following effect on how vsftpd deals with requests:

By default, firewalld blocks incoming FTP connections. To allow FTP connections, as root type:

The change will be applied immediately, but will be lost next time firewalld is reloaded or the system restarted. To make it permanent, type:

For more information on configuring firewalld, see the Red Hat Enterprise Linux 7 Security Guide.

Sometimes one computer is used to serve multiple FTP domains. This is a technique called multihoming. One way to multihome using vsftpd is by running multiple copies of the daemon, each with its own configuration file.

To do this, first assign all relevant IP addresses to network devices or alias network devices on the system. For more information about configuring network devices, device aliases, and additional information about network configuration scripts, refer to the Fedora Networking Guide.

Next, the DNS server for the FTP domains must be configured to reference the correct machine. For information about BIND and its configuration files, refer to the Fedora Networking Guide.

If there is more configuration files present in the /etc/vsftpd directory, calling systemctl start vsftpd.service results in the /etc/rc.d/init.d/vsftpd initscript starting the same number of processes as the number of configuration files. Each configuration file must have a unique name in the /etc/vsftpd/ directory and must be readable and writable only by root.

The following is a list of directives which control the overall behavior of the vsftpd daemon.

The following is a list of directives which control the login behavior and access control mechanisms.

The following lists directives which control anonymous user access to the server. To use these options, the anonymous_enable directive must be set to YES.

The following lists directives which characterize the way local users access the server. To use these options, the local_enable directive must be set to YES.

The following lists directives which affect directories.

The following lists directives which affect directories.

The following lists directives which affect vsftpd's logging behavior.

The following lists directives which affect how vsftpd interacts with the network.

To change printer driver configuration, double-click the corresponding name in the Printer list and click the Settings label on the left to display the Settings page.

You can modify printer settings such as make and model, print a test page, change the device location (URI), and more.

Click the Policies button on the left to change settings in printer state and print output.

You can select the printer states, configure the Error Policy of the printer (you can decide to abort the print job, retry, or stop it if an error occurs).

You can also create a banner page (a page that describes aspects of the print job such as the originating printer, the user name from the which the job originated, and the security status of the document being printed): click the Starting Banner or Ending Banner drop-down menu and choose the option that best describes the nature of the print jobs (for example, confidential).

On the Policies page, you can mark a printer as shared: if a printer is shared, users published on the network can use it. To allow the sharing function for printers, go to Server  Settings and select Publish shared printers connected to this system.

Make sure that the firewall allows incoming TCP connections to port 631, the port for the Network Printing Server (IPP) protocol. To allow IPP traffic through the firewall on Fedora 40, make use of firewalld's IPP service. To do so, proceed as follows:

Alternatively, to start the graphical firewall configuration tool using the command line, enter the following command as root user:

The Firewall Configuration window opens.

Look for the word “Connected” in the lower left corner. This indicates that the firewall-config tool is connected to the user space daemon, firewalld.

To immediately change the current firewall settings, ensure the drop-down selection menu labeled Configuration is set to Runtime. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select Permanent from the drop-down list.

You can change user-level access to the configured printer on the Access Control page. Click the Access Control label on the left to display the page. Select either Allow printing for everyone except these users or Deny printing for everyone except these users and define the user set below: enter the user name in the text box and click the Add button to add the user to the user set.

The Printer Options page contains various configuration options for the printer media and output, and its content may vary from printer to printer. It contains general printing, paper, quality, and printing size settings.

On the Job Options page, you can detail the printer job options. Click the Job Options label on the left to display the page. Edit the default settings to apply custom job options, such as number of copies, orientation, pages per side, scaling (increase or decrease the size of the printable area, which can be used to fit an oversize print area onto a smaller physical sheet of print medium), detailed text options, and custom job options.

The Ink/Toner Levels page contains details on toner status if available and printer status messages. Click the Ink/Toner Levels label on the left to display the page.

When you send a print job to the printer daemon, such as printing a text file from Emacs or printing an image from GIMP, the print job is added to the print spool queue. The print spool queue is a list of print jobs that have been sent to the printer and information about each print request, such as the status of the request, the job number, and more.

During the printing process, messages informing about the process appear in the notification area.

To cancel, hold, release, reprint or authenticate a print job, select the job in the GNOME Print Status and on the Job menu, click the respective command.

To view the list of print jobs in the print spool from a shell prompt, type the command lpstat -o. The last few lines look similar to the following:

If you want to cancel a print job, find the job number of the request with the command lpstat -o and then use the command cancel job number. For example, cancel 60 would cancel the print job in Example of lpstat -o output. You cannot cancel print jobs that were started by other users with the cancel command. However, you can enforce deletion of such job by issuing the cancel -U root job_number command. To prevent such canceling, change the printer operation policy to Authenticated to force root authentication.

You can also print a file directly from a shell prompt. For example, the command lp sample.txt prints the text file sample.txt. The print filter determines what type of file it is and converts it into a format the printer can understand.