Configuring and using network file services

Red Hat Enterprise Linux 10

A guide to configuring and using network file services in Red Hat Enterprise Linux 10

Red Hat Customer Content Services

Abstract

This document describes how to configure and run network file services on Red Hat Enterprise Linux 10, including Samba server and NFS server.

Providing feedback on Red Hat documentation

We appreciate your feedback on our documentation. Let us know how we can improve it.

Submitting feedback through Jira (account required)

Log in to the Jira website.
Click Create in the top navigation bar
Enter a descriptive title in the Summary field.
Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
Click Create at the bottom of the dialogue.

Chapter 1. Using Samba as a server

Samba implements the Server Message Block (SMB) protocol in Red Hat Enterprise Linux. The SMB protocol is used to access resources on a server, such as file shares and shared printers. Additionally, Samba implements the Distributed Computing Environment Remote Procedure Call (DCE RPC) protocol used by Microsoft Windows.

You can run Samba as:

An Active Directory (AD) or NT4 domain member
A standalone server
An NT4 Primary Domain Controller (PDC) or Backup Domain Controller (BDC)

Note

Red Hat supports the PDC and BDC modes only in existing installations with Windows versions which support NT4 domains. Red Hat recommends not setting up a new Samba NT4 domain, because Microsoft operating systems later than Windows 7 and Windows Server 2008 R2 do not support NT4 domains.

Red Hat does not support running Samba as an AD domain controller (DC).

Independently of the installation mode, you can optionally share directories and printers. This enables Samba to act as a file and print server.

1.1. Understanding the different Samba services and modes

The samba package provides multiple services. Depending on your environment and the scenario you want to configure, you require one or more of these services and configure Samba in different modes.

1.1.1. The Samba services

Samba provides the following services:

smbd

This service provides file sharing and printing services using the SMB protocol. Additionally, the service is responsible for resource locking and for authenticating connecting users. For authenticating domain members, smbd requires winbindd. The smb systemd service starts and stops the smbd daemon.

To use the smbd service, install the samba package.

nmbd

This service provides host name and IP resolution using the NetBIOS over IPv4 protocol. Additionally to the name resolution, the nmbd service enables browsing the SMB network to locate domains, work groups, hosts, file shares, and printers. For this, the service either reports this information directly to the broadcasting client or forwards it to a local or master browser. The nmb systemd service starts and stops the nmbd daemon.

Note that modern SMB networks use DNS to resolve clients and IP addresses. For Kerberos a working DNS setup is required.

To use the nmbd service, install the samba package.

winbindd

This service provides an interface for the Name Service Switch (NSS) to use AD or NT4 domain users and groups on the local system. This enables, for example, domain users to authenticate to services hosted on a Samba server or to other local services. The winbind systemd service starts and stops the winbindd daemon.

If you set up Samba as a domain member, winbindd must be started before the smbd service. Otherwise, domain users and groups are not available to the local system.

To use the winbindd service, install the samba-winbind package.

Important

Red Hat only supports running Samba as a server with the winbindd service to provide domain users and groups to the local system. Due to certain limitations, such as missing Windows access control list (ACL) support and NT LAN Manager (NTLM) fallback, SSSD is not supported.

samba-bgqd

The Samba background queue daemon regularly updates the printer list with printers from CUPS. For print servers with multiple printers, run this daemon. It is managed by the samba-bgqd systemd service. If it fails to run, rpcd_spoolss starts it on demand.

1.1.2. The Samba security services

The security parameter in the [global] section in the /etc/samba/smb.conf file manages how Samba authenticates users that are connecting to the service. Depending on the mode you install Samba in, the parameter must be set to different values:

On an AD domain member, set security = ads

In this mode, Samba uses Kerberos to authenticate AD users.

For details about setting up Samba as a domain member, see Setting up Samba as an AD domain member server.

On a standalone server, set security = user

In this mode, Samba uses a local database to authenticate connecting users.

For details about setting up Samba as a standalone server, see Setting up Samba as a standalone server.

On an NT4 PDC or BDC, set security = user

In this mode, Samba authenticates users to a local or LDAP database.

On an NT4 domain member, set security = domain

In this mode, Samba authenticates connecting users to an NT4 PDC or BDC. You cannot use this mode on AD domain members.

For details about setting up Samba as a domain member, see Setting up Samba as an AD domain member server.

Additional resources

security parameter in the smb.conf(5) man page on your system

1.1.3. Scenarios when Samba services and Samba client utilities load and reload their configuration

The following describes when Samba services and utilities load and reload their configuration:

Samba services reload their configuration:
- Automatically every 3 minutes
- On manual request, for example, when you run the smbcontrol all reload-config command.
Samba client utilities read their configuration only when you start them.

Note that certain parameters, such as security require a restart of the smb service to take effect and a reload is not sufficient.

Additional resources

The How configuration changes are applied section in the smb.conf(5) man page on your system
smbd(8), nmbd(8), and winbindd(8) man pages on your system

1.1.4. Editing the Samba configuration in a safe way

Samba services automatically reload their configuration every 3 minutes. To prevent that the services reload the changes before you have verified the configuration using the testparm utility, you can edit the Samba configuration in a safe way.

Prerequisites

Samba is installed.

Procedure

Create a copy of the /etc/samba/smb.conf file:

cp /etc/samba/smb.conf /etc/samba/samba.conf.copy

# cp /etc/samba/smb.conf /etc/samba/samba.conf.copy

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

Edit the copied file and make the required changes.
Verify the configuration in the /etc/samba/samba.conf.copy file:
```
testparm -s /etc/samba/samba.conf.copy
```
```
# testparm -s /etc/samba/samba.conf.copy
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If testparm reports errors, fix them and run the command again.
Override the /etc/samba/smb.conf file with the new configuration:
```
mv /etc/samba/samba.conf.copy /etc/samba/smb.conf
```
```
# mv /etc/samba/samba.conf.copy /etc/samba/smb.conf
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Wait until the Samba services automatically reload their configuration or manually reload the configuration:
```
smbcontrol all reload-config
```
```
# smbcontrol all reload-config
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow

Additional resources

Scenarios when Samba services and Samba client utilities load and reload their configuration

1.2. Verifying the smb.conf file by using the testparm utility

The testparm utility verifies that the Samba configuration in the /etc/samba/smb.conf file is correct. The utility detects invalid parameters and values, but also incorrect settings, such as for ID mapping. If testparm reports no problem, the Samba services will successfully load the /etc/samba/smb.conf file. Note that testparm cannot verify that the configured services will be available or work as expected.

Important

Red Hat recommends that you verify the /etc/samba/smb.conf file by using testparm after each modification of this file.

Prerequisites

You installed Samba.
The /etc/samba/smb.conf file exists.

Procedure

Run the testparm utility as the root user:

testparm
Global parameters

# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Unknown parameter encountered: "log level"
Processing section "[example_share]"
Loaded services file OK.
ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN (ad)!

Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

# Global parameters
[global]
	...

[example_share]
	...

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

The previous example output reports a non-existent parameter and an incorrect ID mapping configuration.

If testparm reports incorrect parameters, values, or other errors in the configuration, fix the problem and run the utility again.

1.3. Setting up Samba as a standalone server

You can set up Samba as a server that is not a member of a domain. In this installation mode, Samba authenticates users to a local database instead of to a central DC. Additionally, you can enable guest access to allow users to connect to one or multiple services without authentication.

1.3.1. Setting up the server configuration for the standalone server

You can set up the server configuration for a Samba standalone server.

Procedure

Install the samba package:
```
dnf install samba
```
```
# dnf install samba
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Edit the /etc/samba/smb.conf file and set the following parameters:
```
[global]
	workgroup = Example-WG
	netbios name = Server
	security = user

	log file = /var/log/samba/%m.log
	log level = 1
```
```
[global]
	workgroup = Example-WG
	netbios name = Server
	security = user

	log file = /var/log/samba/%m.log
	log level = 1
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
This configuration defines a standalone server named Server within the Example-WG work group. Additionally, this configuration enables logging on a minimal level (1) and log files will be stored in the /var/log/samba/ directory. Samba will expand the %m macro in the log file parameter to the NetBIOS name of connecting clients. This enables individual log files for each client.
Optional: Configure file or printer sharing. See:
Verify the /etc/samba/smb.conf file:
```
testparm
```
```
# testparm
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If you set up shares that require authentication, create the user accounts.

For details, see Creating and enabling local user accounts.
Open the required ports and reload the firewall configuration by using the firewall-cmd utility:
```
firewall-cmd --permanent --add-service=samba
firewall-cmd --reload
```
```
# firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Enable and start the smb service:
```
systemctl enable --now smb
```
```
# systemctl enable --now smb
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow

Additional resources

smb.conf(5) man page on your system

1.3.2. Creating and enabling local user accounts

To enable users to authenticate when they connect to a share, you must create the accounts on the Samba host both in the operating system and in the Samba database. Samba requires the operating system account to validate the Access Control Lists (ACL) on file system objects and the Samba account to authenticate connecting users.

If you use the passdb backend = tdbsam default setting, Samba stores user accounts in the /var/lib/samba/private/passdb.tdb database.

You can create a local Samba user named example.

Prerequisites

Samba is installed and configured as a standalone server.

Procedure

Create the operating system account:
```
useradd -M -s /sbin/nologin example
```
```
# useradd -M -s /sbin/nologin example
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
This command adds the example account without creating a home directory. If the account is only used to authenticate to Samba, assign the /sbin/nologin command as shell to prevent the account from logging in locally.
Set a password to the operating system account to enable it:
```
passwd example
```
```
# passwd example
Enter new UNIX password: password
Retype new UNIX password: password
passwd: password updated successfully
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Samba does not use the password set on the operating system account to authenticate. However, you need to set a password to enable the account. If an account is disabled, Samba denies access if this user connects.
Add the user to the Samba database and set a password to the account:
```
smbpasswd -a example
```
```
# smbpasswd -a example
New SMB password: password
Retype new SMB password: password
Added user example.
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Use this password to authenticate when using this account to connect to a Samba share.
Enable the Samba account:
```
smbpasswd -e example
```
```
# smbpasswd -e example
Enabled user example.
```
Copy to Clipboard Copied! Toggle word wrap Toggle overflow

1.4. Understanding and configuring Samba ID mapping

Windows domains distinguish users and groups by unique Security Identifiers (SID). However, Linux requires unique UIDs and GIDs for each user and group. If you run Samba as a domain member, the winbindd service is responsible for providing information about domain users and groups to the operating system.

To enable the winbindd service to provide unique IDs for users and groups to Linux, you must configure ID mapping in the /etc/samba/smb.conf file for:

The local database (default domain)
The AD or NT4 domain the Samba server is a member of
Each trusted domain from which users must be able to access resources on this Samba server

Samba provides different ID mapping back ends for specific configurations. The most frequently used back ends are:

Expand

Back end	Use case
`tdb`	The `*` default domain only
`ad`	AD domains only
`rid`	AD and NT4 domains
`autorid`	AD, NT4, and the `*` default domain

1.4.1. Planning Samba ID ranges

Regardless of whether you store the Linux UIDs and GIDs in AD or if you configure Samba to generate them, each domain configuration requires a unique ID range that must not overlap with any of the other domains.

Warning

If you set overlapping ID ranges, Samba fails to work correctly.

Example 1.1. Unique ID Ranges

The following shows non-overlapping ID mapping ranges for the default (*), AD-DOM, and the TRUST-DOM domains.

[global]
...
idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config AD-DOM:backend = rid
idmap config AD-DOM:range = 2000000-2999999

idmap config TRUST-DOM:backend = rid
idmap config TRUST-DOM:range = 4000000-4999999

[global]
...
idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config AD-DOM:backend = rid
idmap config AD-DOM:range = 2000000-2999999

idmap config TRUST-DOM:backend = rid
idmap config TRUST-DOM:range = 4000000-4999999

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

Important

You can only assign one range per domain. Therefore, leave enough space between the domains ranges. This enables you to extend the range later if your domain grows.

If you later assign a different range to a domain, the ownership of files and directories previously created by these users and groups will be lost.

1.4.2. The * default domain

In a domain environment, you add one ID mapping configuration for each of the following:

The domain the Samba server is a member of
Each trusted domain that should be able to access the Samba server

However, for all other objects, Samba assigns IDs from the default domain. This includes:

Local Samba users and groups
Samba built-in accounts and groups, such as BUILTIN\Administrators

Important

You must configure the default domain as described to enable Samba to operate correctly.

The default domain back end must be writable to permanently store the assigned IDs.

For the default domain, you can use one of the following back ends:

tdb

When you configure the default domain to use the tdb back end, set an ID range that is big enough to include objects that will be created in the future and that are not part of a defined domain ID mapping configuration.

For example, set the following in the [global] section in the /etc/samba/smb.conf file:

idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config * : backend = tdb
idmap config * : range = 10000-999999

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

For further details, see Using the TDB ID mapping back end.

autorid

When you configure the default domain to use the autorid back end, adding additional ID mapping configurations for domains is optional.

Note

The range should be a multiple of the rangesize and must be at least twice its value to ensure sufficient id range space for the mandatory BUILTIN domain. With a default rangesize of 100000, the range must span at least 200000. For example, range = 100000 - 299999.

For example, set the following in the [global] section in the /etc/samba/smb.conf file:

idmap config * : backend = autorid
idmap config * : range = 10000-999999

idmap config * : backend = autorid
idmap config * : range = 10000-999999

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

For further details, see Using the autorid ID mapping back end.

1.4.3. Using the tdb ID mapping back end

The winbindd service uses the writable tdb ID mapping back end by default to store Security Identifier (SID), UID, and GID mapping tables. This includes local users, groups, and built-in principals.

Use this back end only for the * default domain. For example:

idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config * : backend = tdb
idmap config * : range = 10000-999999

Copy to Clipboard Copied! Toggle word wrap Toggle overflow

Additional resources

The * default domain.

1.4.4. Using the ad ID mapping back end

You can configure a Samba AD member to use the ad ID mapping back end.

The ad ID mapping back end implements a read-only API to read account and group information from AD. This provides the following benefits:

All user and group settings are stored centrally in AD.
User and group IDs are consistent on all Samba servers that use this back end.
The IDs are not stored in a local database which can corrupt, and therefore file ownerships cannot be lost.

Note

The ad ID mapping back end does not support {AD} domains with one-way trusts. If you configure a domain member in an {AD} with one-way trusts, use instead one of the following ID mapping back ends: tdb, rid, or autorid.

The ad back end reads the following attributes from AD:

Expand

AD attribute name	Object type	Mapped to
`sAMAccountName`	User and group	User or group name, depending on the object
`uidNumber`	User	User ID (UID)
`gidNumber`	Group	Group ID (GID)
`loginShell` ^[a]	User	Path to the shell of the user
`unixHomeDirectory` ^[a]	User	Path to the home directory of the user
`primaryGroupID` ^[b]	User	Primary group ID
^[a] Samba only reads this attribute if you set `idmap config DOMAIN:unix_nss_info = yes`. ^[b] Samba only reads this attribute if you set `idmap config DOMAIN:unix_primary_group = yes`.

AD attribute name	Object type	Mapped to
`sAMAccountName`	User and group	User or group name, depending on the object
`uidNumber`	User	User ID (UID)
`gidNumber`	Group	Group ID (GID)
`loginShell` ^[a]	User	Path to the shell of the user
`unixHomeDirectory` ^[a]	User	Path to the home directory of the user
`primaryGroupID` ^[b]	User	Primary group ID
^[a] Samba only reads this attribute if you set `idmap config DOMAIN:unix_nss_info = yes`. ^[b] Samba only reads this attribute if you set `idmap config DOMAIN:unix_primary_group = yes`.

Prerequisites

Both users and groups must have unique IDs set in AD, and the IDs must be within the range configured in the /etc/samba/smb.conf file. Objects whose IDs are outside of the range will not be available on the Samba server.
Users and groups must have all required attributes set in AD. If required attributes are missing, the user or group will not be available on the Samba server. The required attributes depend on your configuration.
You installed Samba.
The Samba configuration, except ID mapping, exists in the /etc/samba/smb.conf file.

Procedure

Edit the [global] section in the /etc/samba/smb.conf file:
1. Add an ID mapping configuration for the default domain (*) if it does not exist. For example:
```
idmap config * : backend = tdb
idmap config * : range = 10000-999999
```
```
idmap config * : backend = tdb
idmap config * : range = 10000-999999
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2. Enable the ad ID mapping back end for the AD domain:
```
idmap config DOMAIN : backend = ad
```
```
idmap config DOMAIN : backend = ad
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3. Set the range of IDs that is assigned to users and groups in the AD domain. For example:
```
idmap config DOMAIN : range = 2000000-2999999
```
```
idmap config DOMAIN : range = 2000000-2999999
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
  Important
  
  The range must not overlap with any other domain configuration on this server. Additionally, the range must be set big enough to include all IDs assigned in the future. For further details, see Planning Samba ID ranges.
4. Set that Samba uses the RFC 2307 schema when reading attributes from AD:
```
idmap config DOMAIN : schema_mode = rfc2307
```
```
idmap config DOMAIN : schema_mode = rfc2307
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5. To enable Samba to read the login shell and the path to the users home directory from the corresponding AD attribute, set:
```
idmap config DOMAIN : unix_nss_info = yes
```
```
idmap config DOMAIN : unix_nss_info = yes
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
  Alternatively, you can set a uniform domain-wide home directory path and login shell that is applied to all users. For example:
```
template shell = /bin/bash
template homedir = /home/%U
```
```
template shell = /bin/bash
template homedir = /home/%U
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6. By default, Samba uses the primaryGroupID attribute of a user object as the user’s primary group on Linux. Alternatively, you can configure Samba to use the value set in the gidNumber attribute instead:
```
idmap config DOMAIN : unix_primary_group = yes
```
```
idmap config DOMAIN : unix_primary_group = yes
```
  Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verify the /etc/samba/smb.conf file:
```
testparm
```
```
# testparm
```
Copy to Clipboard

Antler Setup

Layout Mode

Background Style

Color Scheme

Header Position

Body Font

Text Direction

Choisir la langue

Notifications

Connexion - Accès restreint

Cloud VPS SSD Get 50% Discount

Now $9.99 /mo

Support Premium

Hosting

Domains

G Suite

Wilcard

Antler WHMCS Template

Best Hosting Provider with Support Premium 24/7/365.

Base de connaissances

Catégories

Catégories

Nuage de tags

Assistance