Although Linux has made some inroads into the desktop market, its origins, and future are very much server based. It is unsurprising, therefore, that Rocky 9 can act as a file server. It is also common for Rocky Linux and Windows systems to be used side by side in networked environments. Therefore, it is a common requirement that files on a Rocky 9 system be accessible to Linux, UNIX, and Windows-based systems over network connections. Similarly, shared folders and printers residing on Windows systems may also need to be accessible from Rocky 9-based systems.

Windows systems share resources such as file systems and printers using a protocol known as Server Message Block (SMB). For a Rocky 9 system to serve such resources over a network to a Windows system and vice versa, it must support SMB. This is achieved using a technology called Samba. In addition to providing integration between Linux and Windows systems, Samba may also provide folder sharing between Linux systems (as an alternative to NFS covered in the previous chapter).

In this chapter, we will look at the steps necessary to share file system resources and printers on a Rocky 9 system with remote Windows and Linux systems and to access Windows resources from Rocky 9.

Accessing Windows Resources from the GNOME Desktop

Before getting into more details of Samba sharing, it is worth noting that if all you want to do is access Windows shared folders from within the GNOME desktop, then support is already provided within the GNOME Files application. The Files application is located in the dash as highlighted in Figure 19-1:

Once launched, select the Other Locations option in the left-hand navigation panel, followed by the Windows Network icon in the main panel to browse available Windows resources:

Samba and Samba Client

Samba allows both Rocky 9 resources to be shared with Windows systems and Windows resources to be shared with Rocky 9 systems. Rocky Linux accesses Windows resources using the Samba client. Rocky Linux resources, on the other hand, are shared with Windows systems by installing and configuring the Samba service.

Installing Samba on Rocky 9

The default settings used during the Rocky 9 installation process do not typically install the necessary Samba packages. Unless you specifically requested that Samba be installed, it is unlikely that you have Samba installed on your system. To check whether Samba is installed, open a terminal window and run the following command:

# rpm -q samba samba-common samba-clientCode language: plaintext (plaintext)

Any missing packages can be installed using the dnf command-line tool:

# dnf install samba samba-common samba-clientCode language: plaintext (plaintext)

Configuring the Rocky 9 Firewall to Enable Samba

Next, the firewall protecting the Rocky 9 system must be configured to allow Samba traffic. This can be achieved using the firewall-cmd command as follows:

# firewall-cmd --permanent --add-port={139/tcp,445/tcp}
# firewall-cmd --reloadCode language: plaintext (plaintext)

Before starting the Samba service, some configuration steps are necessary to define how the Rocky Linux system will appear to Windows systems and the resources to be shared with remote clients.

Most configuration tasks occur within the /etc/samba/smb.conf file.

Configuring the smb.conf File

Samba is a highly flexible and configurable system that provides many options for controlling how resources are shared on Windows networks. Unfortunately, this flexibility can lead to the sense that Samba is overly complex. In reality, however, the typical installation does not need many configuration options, and the learning curve to set up a basic configuration is relatively short.

For this chapter, we will look at joining a Rocky 9 system to a Windows workgroup and setting up a directory as a shared resource that a specific user can access. This is a configuration known as a standalone Samba server. More advanced configurations, such as integrating Samba within an Active Directory environment, are also available, though these are outside the scope of this book.

The first step in configuring Samba is to edit the /etc/samba/smb.conf file.

Configuring the [global] Section

The smb.conf file is divided into sections. The first section is the [global] section, where settings that apply to the entire Samba configuration can be specified. While these settings are global, each option may be overridden within other configuration file sections.

The first task is defining the Windows workgroup name on which the Rocky 9 resources will be shared. This is controlled via the workgroup = directive of the [global] section, which by default is configured as follows:

workgroup = SAMBACode language: plaintext (plaintext)

Begin by changing this to the actual name of the workgroup if necessary.

In addition to the workgroup setting, the other settings indicate that this is a standalone server on which user passwords will protect the shared resources. Before moving on to configuring the resources to be shared, other parameters also need to be added to the [global] section as follows:

[global]
.
.
        netbios name = LinuxServerCode language: plaintext (plaintext)

The “netbios name” property specifies the name by which the server will be visible to other systems on the network.

Configuring a Shared Resource

The next step is configuring the shared resources (in other words, the resources that will be accessible from other systems on the Windows network). To achieve this, the section is given a name by which it will be referred when shared. For example, if we plan to share the /sampleshare directory of our Rocky 9 system, we might entitle the section [sampleshare]. In this section, a variety of configuration options are possible. For this example, however, we will define the directory that is to be shared, indicate that the directory is both browsable and writable, and declare the resource public so that guest users can gain access:

[sampleshare]
        comment = Example Samba share
        path = /sampleshare
        browseable = Yes
        public = yes
        writable = yesCode language: plaintext (plaintext)

To restrict access to specific users, the “valid users” property may be used, for example:

valid users = demo, bobyoung, marcewingCode language: plaintext (plaintext)

Removing Unnecessary Shares

The smb.conf file is pre-configured with sections for sharing printers and the home folders of the users on the system. If these resources do not need to be shared, the corresponding sections can be commented out so that Samba ignores them. In the following example, the [homes] section has been commented out:

.
.
#[homes]
#       comment = Home Directories
#       valid users = %S, %D%w%S
#       browseable = No
#       read only = No
#       inherit acls = Yes
.
.Code language: plaintext (plaintext)

Configuring SELinux for Samba

SELinux is a system integrated by default into the Linux kernel on all Rocky 9 systems, providing an extra layer of security and protection to the operating system and user files.

Traditionally, Linux security has been based on allowing users to decide who has access to their files and other resources they own. Consider, for example, a file located in the home directory of, and owned by, a particular user. That user can control the access permissions of that file in terms of whether other users on the system can read and write to or, in the case of a script or binary, execute the file. This type of security is called discretionary access control since resource access is left to the user’s discretion.

With SELinux, however, access is controlled by the system administrator and cannot be overridden by the user. This is called mandatory access control and is defined by the administrator using the SELinux policy. To continue the previous example, the owner of a file can only perform tasks on that file if the SELinux policy, defined either by default by the system or by the administrator, permits it.

The current status of SELinux on a Rocky 9 system may be identified using the sestatus tool as follows:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:            enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33Code language: plaintext (plaintext)

SELinux can be run in either enforcing or permissive mode. When enabled, enforcing mode denies all actions that are not permitted by SELinux policy. On the other hand, permissive mode allows actions that would generally have been denied to proceed but records the violation in a log file.

SELinux security is based on the concept of context labels. All resources on a system (including processes and files) are assigned SELinux context labels consisting of user, role, type, and optional security level. The SELinux context of files or folders, for example, may be viewed as follows:

$ ls -Z /home/demo
 unconfined_u:object_r:user_home_t:s0 Desktop
 unconfined_u:object_r:user_home_t:s0 DocumentsCode language: plaintext (plaintext)

Similarly, the ps command may be used to identify the context of a running process, in this case, the ls command:

$ ps -eZ | grep ls
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 14311 tty1 00:00:18 lsCode language: plaintext (plaintext)

When a process (such as the above ls command) attempts to access a file or folder, the SELinux system will check the policy to identify whether or not access is permitted. Now consider the context of the Samba service:

$ ps -eZ | grep smb
system_u:system_r:smbd_t:s0     14129 ?        00:00:00 smbd
system_u:system_r:smbd_t:s0     14132 ?        00:00:00 smbd-notifydCode language: plaintext (plaintext)

SELinux implements security in several ways, the most common of which is called type enforcement. In basic terms, when a process attempts to perform a task on an object (for example, writing to a file), SELinux checks the context types of both the process and the object and verifies that the security policy allows the action to be taken. Suppose a process of type A, for example, attempts to write to a file of type B. In that case, it will only be permitted if SELinux policy states explicitly that a process of type A may perform a write operation to a file of type B. In SELinux enforcement, all actions are denied by default unless a rule specifically allows the action to be performed.

The issue with SELinux and Samba is that SELinux policy is not configured to allow processes of type smb_t to perform actions on files of any type other than samba_share_t. For example, the /home/demo directory listed above will be inaccessible to the Samba service because it has a type of user_home_t. To make files or folders on the system accessible to the Samba service, the enforcement type of those specific resources must be changed to samba_share_t.

For this example, we will create the /sampleshare directory referenced previously in the smb.conf file and change the enforcement type to make it accessible to the Samba service. Begin by creating the directory as follows:

# mkdir /sampleshareCode language: plaintext (plaintext)

Next, check the current SELinux context on the directory:

$ ls -aZ /sampleshare/
unconfined_u:object_r:root_t:s0 .Code language: plaintext (plaintext)

In this instance, the context label of the folder has been assigned a type of root_t. To make the folder sharable by Samba, the enforcement type needs to be set to samba_share_t using the semanage tool as follows:

# semanage fcontext -a -t samba_share_t "/sampleshare(/.*)?"Code language: plaintext (plaintext)

Note the use of a wildcard in the semanage command to ensure that the type is applied to any sub-directories and files contained within the /sampleshare directory. Once added, the change needs to be applied using the restorecon command, making use of the -R flag to apply the change recursively through any sub-directories:

# restorecon -R -v /sampleshare
Relabeled /sampleshare from unconfined_u:object_r:default_t:s0 to unconfined_u:object_r:samba_share_t:s0Code language: plaintext (plaintext)

Once these changes have been made, the folder is configured to comply with SELinux policy for the smb process and is ready to be shared by Samba.

Creating a Samba User

Any user that requires access to a Samba shared resource must be configured as a Samba User and assigned a password. This task is achieved using the smbpasswd command-line tool. Consider, for example, that a user named demo is required to be able to access the /sampleshare directory of our Rocky 9 system from a Windows system. To fulfill this requirement, we must add demo as a Samba user as follows:

# smbpasswd -a demo
New SMB password:
Retype new SMB password:
Added user demo.Code language: plaintext (plaintext)

Now that we have completed the configuration of an elementary Samba server, it is time to test our configuration file and then start the Samba services.

Testing the smb.conf File

The settings in the smb.conf file may be checked for errors using the testparm command-line tool as follows:

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed

Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
 
# Global parameters
[global]
	log file = /var/log/samba/%m.log
	netbios name = LINUXSERVER
	printcap name = cups
	security = USER
	wins support = Yes
	idmap config * : backend = tdb
	cups options = raw
 
[sampleshare]
	comment = Example Samba share
	guest ok = Yes
	path = /sampleshare
	read only = No
 
[homes]
	browseable = No
	comment = Home Directories
	inherit acls = Yes
	read only = No
	valid users = %S %D%w%S
 
[printers]
	browseable = No
	comment = All Printers
	create mask = 0600
	path = /var/tmp
	printable = Yes
.
.Code language: plaintext (plaintext)

Starting the Samba and NetBIOS Name Services

For a Rocky 9 server to operate within a Windows network, the Samba (SMB) and NetBIOS nameservice (NMB) services must be started. Optionally, also enable the services so that they start each time the system boots:

# systemctl enable smb nmb
# systemctl start smb nmbCode language: plaintext (plaintext)

Before attempting to connect from a Windows system, use the smbclient utility to verify that the share is configured:

# smbclient -U demo -L localhost 
Enter WORKGROUP\demo’s password: 
 
	Sharename       Type      Comment
	---------       ----      -------
	sampleshare     Disk      Example Samba share
	print$          Disk      Printer Drivers
	IPC$            IPC       IPC Service (Samba 4.9.1)
	demo            Disk      Home Directories
Code language: plaintext (plaintext)

Accessing Samba Shares

Now that the Samba resources are configured and the services are running, it is time to access the shared resource from a Windows system. On a suitable Windows system on the same workgroup as the Rocky 9 system, open Windows Explorer and navigate to the Network panel. At this point, explorer should search the network and list any systems using the SMB protocol that it finds. The following figure illustrates a Rocky 9 system named LINUXSERVER located using Windows Explorer on a Windows system:

Double-clicking on the LINUXSERVER host will prompt for the name and password of a user with access privileges. In this case, it is the demo account that we configured using the smbpasswd tool:

Entering the username and password will result in the shared resources configured for that user appearing in the explorer window, including the previously configured /sampleshare resource:

Double-clicking on the /sampleshare shared resource will display a listing of the files and directories contained therein.

If you are unable to see the Linux system or have problems accessing the shared folder, try mapping the Samba share to a local Windows drive as follows:

1. Open Windows File Explorer, right-click on the Network entry in the left-hand panel and select Map network drive… from the resulting menu.
2. Select a drive letter from the Map Network Drive dialog before entering the path to the shared folder. For example:

\\LinuxServer\sampleshareCode language: plaintext (plaintext)

Enable the checkbox next to Connect using different credentials. For example, if you do not want the drive to be mapped each time you log into the Windows system, turn off the corresponding check box:

With the settings entered, click the Finish button to map the drive, entering the username and password for the Samba user configured earlier in the chapter when prompted. After a short delay, the content of the Samba share will appear in a new File Explorer window.

Accessing Windows Shares from Rocky 9

As previously mentioned, Samba is a two-way street, allowing not only Windows systems to access files and printers hosted on a Rocky 9 system but also allowing the Rocky 9 system to access shared resources on Windows systems. This is achieved using the samba-client package, installed at this chapter’s start. If it is not currently installed, install it from a terminal window as follows:

# dnf install samba-clientCode language: plaintext (plaintext)

Shared resources on a Windows system can be accessed from the Rocky Linux desktop using the Files application or from the command-line prompt using the smbclient and mount tools. The steps in this section assume that the Windows system has enabled appropriate network-sharing settings.

To access any shared resources on a Windows system using the GNOME desktop, launch the Files application and select the Other Locations option. This will display the screen shown in Figure 19-7 below, including an icon for the Windows Network (if one is detected):

Selecting the Windows Network option will display the Windows systems detected on the network and allow access to any shared resources.

Alternatively, the Connect to Server option may be used to connect to a specific system. Note that the name or IP address of the remote system must be prefixed by smb:// and may be followed by the path to a specific shared resource, for example:

smb://WinServer/DocumentsCode language: plaintext (plaintext)

Without a desktop environment, a remote Windows share may be mounted from the command line using the mount command and specifying the cifs filesystem type. The following command, for example, mounts a share named Documents located on a Windows system named WinServer at a local mount point named /winfiles:

# mount -t cifs //WinServer/Documents /winfiles -o user=demoCode language: plaintext (plaintext)

Summary

In this chapter, we have looked at how to configure a Rocky 9 system to act as both a Samba client and server, allowing the sharing of resources with Windows systems. Topics covered included the installation of Samba client and server packages and configuring Samba as a standalone server. In addition, the basic concepts of SELinux were introduced together with the steps to provide Samba access to a shared resource.