Shared File System Administration

6 Shared File System Administration

This chapter describes administration tasks for the NFS and Samba shared file systems.

About Shared File Systems

Oracle Linux supports the following shared file system types:

NFS: The Network File System (NFS) is a distributed file system that allows a client computer to access files over a network as though the files were on local storage. See About NFS.
Samba: Samba enables the provision of file and print services for Microsoft Windows clients and can integrate with a Windows workgroup, NT4 domain, or Active Directory domain. See About Samba.

About NFS

A Network File System (NFS) server can share directory hierarchies in its local file systems with remote client systems over an IP-based network. After an NFS server exports a directory, NFS clients mount this directory if they have been granted permission to do so. The directory appears to the client systems as if it were a local directory. NFS centralizes storage provisioning and can improves data consistency and reliability.

Oracle Linux 7 supports the following versions of the NFS protocol:

NFS version 3 (NFSv3), specified in RFC 1813.
NFS version 4 (NFSv4), specified in RFC 7530.
NFS version 4 minor version 1 (NFSv4.1), specified in RFC 5661.

NFSv3 relies on Remote Procedure Call (RPC) services, which are controlled by the rpcbind service. rpcbind responds to requests for an RPC service and sets up connections for the requested service. In addition, separate services are used to handle locking and mounting protocols. Configuring a firewall to cope with the various ranges of ports that are used by all these services can be complex and error prone.

NFSv4 does not use rpcbind as the NFS server itself listens on TCP port 2049 for service requests. The mounting and locking protocols are also integrated into the NFSv4 protocol, so separate services are also not required for these protocols. These refinements mean that firewall configuration for NFSv4 is no more difficult than for a service such as HTTP.

Configuring an NFS Server

To configure an NFS server:

Install the nfs-utils package:
```
sudo yum install nfs-utils
```
Edit the /etc/exports file to define the directories that the server will make available for clients to mount, for example:
```
/var/folder 192.0.2.102(rw,async)
/usr/local/apps *(all_squash,anonuid=501,anongid=501,ro)
/var/projects/proj1 192.168.1.0/24(ro) mgmtpc(rw)
```
Each entry consists of the local path to the exported directory, followed by a list of clients that can mount the directory with client-specific mount options in parentheses. If this example:
- The client system with the IP address 192.0.2.102 can mount /var/folder with read and write permissions. All writes to the disk are asynchronous, which means that the server does not wait for write requests to be written to disk before responding to further requests from the client.
- All clients can mount /usr/local/apps read-only, and all connecting users including root are mapped to the local unprivileged user with UID 501 and GID 501.
- All clients on the 192.168.1.0 subnet can mount /var/projects/proj1 read-only, and the client system named mgmtpc can mount the directory with read-write permissions.
Note:

There is no space between a client specifier and the parenthesized list of options.

For more information, see the exports(5) manual page.
Start the nfs-server service, and configure the service to start following a system reboot:
```
sudo systemctl start nfs-server
sudo systemctl enable nfs-server
```
If the server will serve NFSv4 clients, edit /etc/idmapd.conf and edit the definition for the Domain parameter to specify the DNS domain name of the server, for example:
```
Domain = mydom.com
```
This setting prevents the owner and group being unexpectedly listed as the anonymous user or group (nobody or nogroup) on NFS clients when the all_squash mount option has not been specified.
If you need to allow access through the firewall for NFSv4 clients only, use the following commands:
```
sudo firewall-cmd --zone=zone --add-service=nfs
sudo firewall-cmd --permanent --zone=zone --add-service=nfs
```
This configuration assumes that rpc.nfsd listens for client requests on TCP port 2049.
If you need to allow access through the firewall for NFSv3 clients as well as NFSv4 clients:
1. Edit /etc/sysconfig/nfs and create port settings for handling network mount requests and status monitoring:
```
# Port rpc.mountd should listen on.
MOUNTD_PORT=892

# Port rpc.statd should listen on.
STATD_PORT=662
```
  The port values shown in this example are the default settings that are commented-out in the file.
2. Edit /etc/sysctl.conf and configure settings for the TCP and UDP ports on which the network lock manager should listen:
```
fs.nfs.nlm_tcpport = 32803
fs.nfs.nlm_udpport = 32769
```
3. To verify that none of the ports that you have specified in /etc/sysconfig/nfs or /etc/sysctl.conf is in use, enter the following commands:
```
sudo lsof -i tcp:32803
sudo lsof -i udp:32769
sudo lsof -i :892
sudo lsof -i :662
```
  If any port is in use, use the lsof -i command to determine an unused port and amend the setting in /etc/sysconfig/nfs or /etc/sysctl.conf as appropriate.
4. Shut down and reboot the server.
```
sudo systemctl reboot
```
  NFS fails to start if one of the specified ports is in use, and reports an error in /var/log/messages. Edit /etc/sysconfig/nfs or /etc/sysctl.conf as appropriate to use a different port number for the service that could not start, and attempt to restart the nfslock and nfs-server services. You can use the rpcinfo -p command to confirm on which ports RPC services are listening.
5. Restart the firewall service and configure the firewall to allow NFSv3 connections:
```
sudo systemctl restart firewalld
```
```
sudo firewall-cmd --zone=zone \
  --add-port=2049/tcp --add-port=2049/udp \
  --add-port=111/tcp --add-port=111/udp \
  --add-port=32803/tcp --add-port=32769/udp \
  --add-port=892/tcp --add-port=892/udp \
  --add-port=662/tcp --add-port=662/udp
```
```
sudo firewall-cmd --permanent --zone=zone \
  --add-port=2049/tcp --add-port=2049/udp \
  --add-port=111/tcp --add-port=111/udp \
  --add-port=32803/tcp --add-port=32769/udp \
  --add-port=892/tcp --add-port=892/udp \
  --add-port=662/tcp --add-port=662/udp
```
  The port values shown in this example assume that the default port settings in /etc/sysconfig/nfs and /etc/sysctl.conf are available for use by RPC services. This configuration also assumes that rpc.nfsd and rpcbind listen on ports 2049 and 111 respectively.
Use the showmount -e command to display a list of the exported file systems, for example:
```
sudo showmount -e
```
```
Export list for host01.mydom.com
/var/folder 192.0.2.102
/usr/local/apps *
/var/projects/proj1 192.168.1.0/24 mgmtpc
```
showmount -a lists the current clients and the file systems that they have mounted, for example:
```
sudo showmount -a
```
```
mgmtpc.mydom.com:/var/projects/proj1
```
Note:

To be able to use the showmount command from NFSv4 clients, MOUNTD_PORT must be defined in /etc/sysconfig/nfs and a firewall rule must allow access on this TCP port.

If you want to export or unexport directories without editing /etc/exports and restarting the NFS service, use the exportfs command. The following example makes /var/dev available with read and write access by all clients, and ignores any existing entries in /etc/exports.

sudo exportfs -i -o ro *:/var/dev

For more information, see the exportfs(8), exports(5), and showmount(8) manual pages.

Mounting an NFS File System

To mount an NFS file system on a client:

Install the nfs-utils package:
```
sudo yum install nfs-utils
```

Use showmount -e to discover what file systems an NFS server exports, for example:

sudo showmount -e host01.mydom.com

Export list for host01.mydom.com
/var/folder 192.0.2.102
/usr/local/apps *
/var/projects/proj1 192.168.1.0/24 mgmtpc

Use the mount command to mount an exported NFS file system on an available mount point:
```
sudo mount -t nfs -o ro,nosuid host01.mydoc.com:/usr/local/apps /apps
```
This example mounts /usr/local/apps exported by host01.mydoc.com with read-only permissions on /apps. The nosuid option prevents remote users from gaining higher privileges by running a setuid program.
To configure the system to mount an NFS file system at boot time, add an entry for the file system to /etc/fstab, for example:
```
host01.mydoc.com:/usr/local/apps      /apps      nfs      ro,nosuid  0 0
```

For more information, see the mount(8), nfs(5), and showmount(8) manual pages.

About Samba

Samba is an open-source implementation of the Server Message Block (SMB) protocol that allows Oracle Linux to interoperate with Windows systems as both a server and a client. Samba can share Oracle Linux files and printers with Windows systems, and it enables Oracle Linux users to access files on Windows systems. Samba uses the NetBIOS over TCP/IP protocol that allows computer applications that depend on the NetBIOS API to work on TCP/IP networks.

Configuring a Samba Server

To configure a Samba server:

Install the samba and samba-winbind packages:
```
sudo yum install samba samba-winbind
```
Edit /etc/samba/smb.conf and configure the sections to support the required services, for example:
```
[global]
security = ADS
realm = MYDOM.REALM
password server = krbsvr.mydom.com
load printers = yes
printing = cups
printcap name = cups

[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
printer admin = root, @ntadmins, @smbprintadm

[homes]
comment = User home directories
valid users = @smbusers
browsable = no
writable = yes
guest ok = no

[apps]
comment = Shared /usr/local/apps directory
path = /usr/local/apps
browsable = yes
writable = no
guest ok = yes
```
The [global] section contains settings for the Samba server. In this example, the server is assumed to be a member of an Active Directory (AD) domain that is running in native mode. Samba relies on tickets issued by the Kerberos server to authenticate clients who want to access local services.

For more information, see About Samba Configuration for Windows Workgroups and Domains.

The [printers] section specifies support for print services. The path parameter specifies the location of a spooling directory that receives print jobs from Windows clients before submitting them to the local print spooler. Samba advertises all locally configured printers on the server.

The [homes] section provide a personal share for each user in the smbusers group. The settings for browsable and writable prevent other users from browsing home directories, while allowing full access to valid users.

The [apps] section specifies a share named apps, which grants Windows users browsing and read-only permission to the /usr/local/apps directory.
Configure the system firewall to allow incoming TCP connections to ports 139 and 445, and incoming UDP datagrams on ports 137 and 138:
```
sudo firewall-cmd --zone=zone --add-port=139/tcp --add-port=445/tcp --add-port=137-138/udp
sudo firewall-cmd --permanent --zone=zone --add-port=139/tcp --add-port=445/tcp --add-port=137-138/udp
```
Add similar rules for other networks from which Samba clients can connect.

The nmdb daemon services NetBIOS Name Service requests on UDP port 137 and NetBIOS Datagram Service requests on UDP port 138.

The smbd daemon services NetBIOS Session Service requests on TCP port 139 and Microsoft Directory Service requests on TCP port 445.
Start the smb service, and configure the service to start following a system reboot:
```
sudo systemctl start smb
sudo systemctl enable smb
```

If you change the /etc/samba/smb.conf file and any files that it references, the smb service will reload its configuration automatically after a delay of up to one minute. You can force smb to reload its configuration by sending a SIGHUP signal to the service daemon:

sudo killall -SIGHUP smbd

Making smb reload its configuration has no effect on established connections. You must restart the smb service or the existing users of the service must disconnect and then reconnect.

To restart the smb service, use the following command:

sudo systemctl restart smb

For more information, see the smb.conf(5) and smbd(8) manual pages and https://www.samba.org/samba/docs/.

About Samba Configuration for Windows Workgroups and Domains

Windows systems on an enterprise network usually belong either to a workgroup or to a domain.

Workgroups are usually only configured on networks that connect a small number of computers. A workgroup environment is a peer-to-peer network where systems do not rely on each other for services and there is no centralized management. User accounts, access control, and system resources are configured independently on each system. Such systems can share resources only if configured to do so.

A Samba server can act as a standalone server within a workgroup.

More typically, corporate networks configure domains to allow large numbers of networked systems to be administered centrally. A domain is a group of trusted computers that share security and access control. Systems known as domain controllers provides centralized management and security. Windows domains are usually configured to use Active Directory (AD), which uses the Lightweight Directory Access Protocol (LDAP) to implement versions of Kerberos and DNS providing authentication, access control to domain resources, and name service. Some Windows domains use Windows NT4 security, which does not use Kerberos to perform authentication.

A Samba server can be a member of an AD or NT4 security domain, but it cannot operate as a domain controller. As domain member Samba server must authenticate itself with a domain controller and so is controlled by the security rules of the domain. The domain controller authenticates clients, and the Samba server controls access to printers and network shares.

Configuring Samba as a Standalone Server

A standalone Samba server can be a member of a workgroup. The following [global] section from /etc/samba/smb.conf shows an example of how to configure a standalone server using share-level security:

[global]
security = share
workgroup = workgroup_name
netbios name = netbios_name

The client provides only a password and not a user name to the server. Typically, each share is associated with a valid users parameter and the server validates the password against the hashed passwords stored in /etc/passwd, /etc/shadow, NIS, or LDAP for the listed users. Using share-level security is discouraged in favor of user-level security, for example:

[global]
security = user
workgroup = workgroup_name
netbios name = netbios_name

In the user security model, a client must supply a valid user name and password. This model supports encrypted passwords. If the server successfully validates the client's user name and password, the client can mount multiple shares without being required to specify a password. Use the smbpasswd command to create an entry for a user in the Samba password file, for example:

# smbpasswd -a guest
New SMB password: password
Retype new SMB password: password
Added user guest.

The user must already exist as a user on the system. If a user is permitted to log into the server, he or she can use the smbpasswd command to change his or her password.

If a Windows user has a different user name from his or her user name on the Samba server, create a mapping between the names in the /etc/samba/smbusers file, for example:

root = admin administrator root
nobody = guest nobody pcguest smbguest
eddie = ejones
fiona = fchau

The first entry on each line is the user name on the Samba server. The entries after the equals sign (=) are the equivalent Windows user names.

Note:

Only the user security model uses Samba passwords.

The server security model, where the Samba server relies on another server to authenticate user names and passwords, is deprecated as it has numerous security and interoperability issues.

Configuring Samba as a Member of an ADS Domain

In the Activity Directory Server (ADS) security model, Samba acts as a domain member server in an ADS realm, and clients use Kerberos tickets for Active Directory authentication. You must configure Kerberos and join the server to the domain, which creates a machine account for your server on the domain controller.

To add a Samba server to an Active Directory domain:

Edit /etc/samba/smb.conf and configure the [global] section to use ADS:
```
[global]
security = ADS
realm = KERBEROS.REALM
```
It might also be necessary to specify the password server explicitly if different servers support AD services and Kerberos authentication:
```
password server = kerberos_server.your_domain
```
Install the krb5-server package:
```
# yum install krb5-server
```
Create a Kerberos ticket for the Administrator account in the Kerberos domain, for example:
```
# kinit Administrator@MYDOMAIN.COM
```
This command creates the Kerberos ticket that is required to join the server to the AD domain.
Join the server to the AD domain:
```
# net ads join -S winads.mydom.com -U Administrator%password
                              
```
In this example, the AD server is winads.mydom.com and password is the password for the Administrator account.

The command creates a machine account in Active Directory for the Samba server and allows it to join the domain.
Restart the smb service:
```
# systemctl restart smb
```

Configuring Samba as a Member of a Windows NT4 Security Domain

Note:

If the Samba server acts as a Primary or Backup Domain Controller, do not use the domain security model. Configure the system as a standalone server that uses the user security model instead. See Configuring Samba as a Standalone Server.

The domain security model is used with domains that implement Windows NT4 security. The Samba server must have a machine account in the domain (a domain security trust account). Samba authenticates user names and passwords with either a primary or a secondary domain controller.

To add a Samba server to an NT4 domain:

On the primary domain controller, use the Server Manager to add a machine account for the Samba server.
Edit /etc/samba/smb.conf and configure the [global] section to use ADS:
```
[global]
security = domain
workgroup = DOMAIN
netbios name = SERVERNAME
```
Join the server to the domain:
```
# net rpc join -S winpdc.mydom.com -U Administrator%password
                              
```
In this example, the primary domain controller is winpdc.mydom.com and password is the password for the Administrator account.
Restart the smb service:
```
# systemctl restart smb
```

Create an account for each user who is allowed access to shares or printers:

# useradd -s /sbin/nologin username
                              
# passwd username

In this example, the account's login shell is set to /sbin/nologin to prevent direct logins.

Accessing Samba Shares from a Windows Client

To access a share on a Samba server from Windows, open Computer or Windows Explorer, and enter the host name of the Samba server and the share name using the following format:

\\server_name\share_name

If you enter \\server_name, Windows displays the directories and printers that the server is sharing. You can also use the same syntax to map a network drive to a share name.

Accessing Samba Shares from an Oracle Linux Client

Note:

To be able to use the commands described in this section, use yum to install the samba-client and cifs-utils packages.

You can use the findsmb command to query a subnet for Samba servers. The command displays the IP address, NetBIOS name, workgroup, operating system and version for each server that it finds.

Alternatively, you can use the smbtree command, which is a text-based SMB network browser that displays the hierarchy of known domains, servers in those domains, and shares on those servers.

The GNOME and KDE desktops provide browser-based file managers that you can use to view Windows shares on the network. Enter smb: in the location bar of a file manager to browse network shares.

To connect to a Windows share from the command line, use the smbclient command:

smbclient //server_name/share_name [-U username]

After logging in, enter help at the smb:\> prompt to display a list of available commands.

To mount a Samba share, use a command such as the following:

sudo mount -t cifs //server_name/share_name mountpoint -o credentials=credfile

In the previous command, the credentials file contains settings for username, password, and domain, for example:

username=eddie
password=clydenw
domain=MYDOMWKG

The argument to domain can be the name of a domain or a workgroup.

Caution:

As the credentials file contains a plain-text password, use chmod to make it readable only by you, for example:

sudo chmod 400 credfile

If the Samba server is a domain member server in an AD domain and your current login session was authenticated by the Kerberos server in the domain, you can use your existing session credentials by specifying the sec=krb5 option instead of a credentials file:

sudo mount -t cifs //server_name/share_name mountpoint -o sec=krb5

For more information, see the findsmb(1), mount.cifs(8), smbclient(1), and smbtree(1) manual pages.