Chapter 14. Mounting file systems
As a system administrator, you can mount file systems on your system to access data on them.
14.1. The Linux mount mechanism
This section explains basic concepts of mounting file systems on Linux.
On Linux, UNIX, and similar operating systems, file systems on different partitions and removable devices (CDs, DVDs, or USB flash drives for example) can be attached to a certain point (the mount point) in the directory tree, and then detached again. While a file system is mounted on a directory, the original content of the directory is not accessible.
Note that Linux does not prevent you from mounting a file system to a directory with a file system already attached to it.
When mounting, you can identify the device by:
a universally unique identifier (UUID): for example,
a volume label: for example,
a full path to a non-persistent block device: for example,
When you mount a file system using the
mount command without all required information, that is without the device name, the target directory, or the file system type, the
mount utility reads the content of the
/etc/fstab file to check if the given file system is listed there. The
/etc/fstab file contains a list of device names and the directories in which the selected file systems are set to be mounted as well as the file system type and mount options. Therefore, when mounting a file system that is specified in
/etc/fstab, the following command syntax is sufficient:
Mounting by the mount point:
# mount directory
Mounting by the block device:
# mount device
- For information on how to list persistent naming attributes such as the UUID, see Section 9.6, “Listing persistent naming attributes”.
14.2. Listing currently mounted file systems
This procedure describes how to list all currently mounted file systems on the command line.
To list all mounted file systems, use the
To limit the listed file systems only to a certain file system type, add the
$ findmnt --types fs-type
Example 14.1. Listing only XFS file systems
$ findmnt --types xfs TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/luks-5564ed00-6aac-4406-bfb4-c59bf5de48b5 xfs rw,relatime ├─/boot /dev/sda1 xfs rw,relatime └─/home /dev/mapper/luks-9d185660-7537-414d-b727-d92ea036051e xfs rw,relatime
14.3. Mounting a file system with mount
This procedure describes how to mount a file system using the
Make sure that no file system is already mounted on your chosen mount point:
$ findmnt mount-point
To attach a certain file system, use the
# mount device mount-point
Example 14.2. Mounting an XFS file system
For example, to mount a local XFS file system identified by UUID:
# mount UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /mnt/data
mountcannot recognize the file system type automatically, specify it using the
# mount --types type device mount-point
Example 14.3. Mounting an NFS file system
For example, to mount a remote NFS file system:
# mount --types nfs4 host:/remote-export /mnt/nfs
14.4. Moving a mount point
This procedure describes how to change the mount point of a mounted file system to a different directory.
To change the directory in which a file system is mounted:
# mount --move old-directory new-directory
Example 14.4. Moving a home file system
For example, to move the file system mounted in the
/mnt/userdirs/directory to the
# mount --move /mnt/userdirs /home
Verify that the file system has been moved as expected:
$ findmnt $ ls old-directory $ ls new-directory
14.5. Unmounting a file system with umount
This procedure describes how to unmount a file system using the
Try unmounting the file system using either of the following commands:
By mount point:
# umount mount-point
# umount device
If the command fails with an error similar to the following, it means that the file system is in use because of a process is using resources on it:
umount: /run/media/user/FlashDrive: target is busy.
If the file system is in use, use the
fuserutility to determine which processes are accessing it. For example:
$ fuser --mount /run/media/user/FlashDrive /run/media/user/FlashDrive: 18351
Afterwards, terminate the processes using the file system and try unmounting it again.
14.6. Common mount options
This section lists some commonly used options of the
You can use these options in the following syntax:
# mount --options option1,option2,option3 device mount-point
Table 14.1. Common mount options
| || |
Enables asynchronous input and output operations on the file system.
| || |
Enables the file system to be mounted automatically using the
| || |
Provides an alias for the
| || |
Allows the execution of binary files on the particular file system.
| || |
Mounts an image as a loop device.
| || |
Default behavior disables the automatic mount of the file system using the
| || |
Disallows the execution of binary files on the particular file system.
| || |
Disallows an ordinary user (that is, other than root) to mount and unmount the file system.
| || |
Remounts the file system in case it is already mounted.
| || |
Mounts the file system for reading only.
| || |
Mounts the file system for both reading and writing.
| || |
Allows an ordinary user (that is, other than root) to mount and unmount the file system.
14.8. Persistently mounting file systems
As a system administrator, you can persistently mount file systems to configure non-removable storage.
14.8.1. The /etc/fstab file
This section describes the
/etc/fstab configuration file, which controls persistent mount points of file systems. Using
/etc/fstab is the recommended way to persistently mount file systems.
Each line in the
/etc/fstab file defines a mount point of a file system. It includes six fields separated by white space:
The block device identified by a persistent attribute or a path it the
- The directory where the device will be mounted.
- The file system on the device.
Mount options for the file system. The option
defaultsmeans that the partition is mounted at boot time with default options. This section also recognizes
systemdmount unit options in the
Backup option for the
Check order for the
Example 14.9. The
/boot file system in
|Block device||Mount point||File system||Options||Backup||Check|
| || || || || || |
systemd service automatically generates mount units from entries in
The fstab section of the
14.8.2. Adding a file system to /etc/fstab
This procedure describes how to configure persistent mount point for a file system in the
/etc/fstab configuration file.
Find out the UUID attribute of the file system:
$ lsblk --fs storage-device
Example 14.10. Viewing the UUID of a partition
$ lsblk --fs /dev/sda1 NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot
If the mount point directory does not exist, create it:
# mkdir --parents mount-point
As root, edit the
/etc/fstabfile and add a line for the file system, identified by the UUID.
Example 14.11. The /boot mount point in /etc/fstab
UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0
Regenerate mount units so that your system registers the new configuration:
# systemctl daemon-reload
Try mounting the file system to verify that the configuration works:
# mount mount-point
- Other persistent attributes that you can use to identify the file system: Section 9.3, “Device names managed by the udev mechanism in /dev/disk/”
14.8.3. Persistently mounting a file system using RHEL System Roles
This section describes how to persistently mount a file system using the
An Ansible playbook that uses the
For information on how to apply such a playbook, see Applying a role.
184.108.40.206. Example Ansible playbook to persistently mount a file system
This section provides an example Ansible playbook. This playbook applies the
storage role to immediately and persistently mount an XFS file system.
Example 14.12. A playbook that mounts a file system on /dev/sdb to /mnt/data
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage
This playbook adds the file system to the
/etc/fstabfile, and mounts the file system immediately.
If the file system on the
/dev/sdbdevice or the mount point directory do not exist, the playbook creates them.
For details about the parameters used in the
storagesystem role, see the
220.127.116.11. Additional resources
For more information about the
storagerole, see Section 2.1, “Introduction to the storage role”.
14.9. Mounting file systems on demand
As a system administrator, you can configure file systems, such as NFS, to mount automatically on demand.
14.9.1. The autofs service
This section explains the benefits and basic concepts of the
autofs service, used to mount file systems on demand.
One drawback of permanent mounting using the
/etc/fstab configuration is that, regardless of how infrequently a user accesses the mounted file system, the system must dedicate resources to keep the mounted file system in place. This might affect system performance when, for example, the system is maintaining NFS mounts to many systems at one time.
An alternative to
/etc/fstab is to use the kernel-based
autofs service. It consists of the following components:
- A kernel module that implements a file system, and
- A user-space service that performs all of the other functions.
autofs service can mount and unmount file systems automatically (on-demand), therefore saving system resources. It can be used to mount file systems such as NFS, AFS, SMBFS, CIFS, and local file systems.
14.9.2. The autofs configuration files
This section describes the usage and syntax of configuration files used by the
The master map file
autofs service uses
/etc/auto.master (master map) as its default primary configuration file. This can be changed to use another supported network source and name using the
autofs configuration in the
/etc/autofs.conf configuration file in conjunction with the Name Service Switch (NSS) mechanism.
All on-demand mount points must be configured in the master map. Mount point, host name, exported directory, and options can all be specified in a set of files (or other supported network sources) rather than configuring them manually for each host.
The master map file lists mount points controlled by
autofs, and their corresponding configuration files or network sources known as automount maps. The format of the master map is as follows:
mount-point map-name options
The variables used in this format are:
autofsmount point; for example,
- The map source file, which contains a list of mount points and the file system location from which those mount points should be mounted.
- If supplied, these apply to all entries in the given map, if they do not themselves have options specified.
Example 14.13. The /etc/auto.master file
The following is a sample line from
Map files configure the properties of individual on-demand mount points.
The automounter creates the directories if they do not exist. If the directories exist before the automounter was started, the automounter will not remove them when it exits. If a timeout is specified, the directory is automatically unmounted if the directory is not accessed for the timeout period.
The general format of maps is similar to the master map. However, the options field appears between the mount point and the location instead of at the end of the entry as in the master map:
mount-point options location
The variables used in this format are:
This refers to the
autofsmount point. This can be a single directory name for an indirect mount or the full path of the mount point for direct mounts. Each direct and indirect map entry key (mount-point) can be followed by a space separated list of offset directories (subdirectory names each beginning with
/) making them what is known as a multi-mount entry.
- When supplied, these are the mount options for the map entries that do not specify their own options. This field is optional.
This refers to the file system location such as a local file system path (preceded with the Sun map format escape character
:for map names beginning with
/), an NFS file system or other valid file system location.
Example 14.14. A map file
The following is a sample from a map file; for example,
payroll -fstype=nfs4 personnel:/dev/disk/by-uuid/52b94495-e106-4f29-b868-fe6f6c2789b1 sales -fstype=xfs :/dev/disk/by-uuid/5564ed00-6aac-4406-bfb4-c59bf5de48b5
The first column in the map file indicates the
autofs mount point:
payroll from the server called
personnel. The second column indicates the options for the
autofs mount. The third column indicates the source of the mount.
Following the given configuration, the
autofs mount points will be
-fstype= option is often omitted and is generally not needed for correct operation.
Using the given configuration, if a process requires access to an
autofs unmounted directory such as
autofs service automatically mounts the directory.
The amd map format
autofs service recognizes map configuration in the
amd format as well. This is useful if you want to reuse existing automounter configuration written for the
am-utils service, which has been removed from Red Hat Enterprise Linux.
However, Red Hat recommends using the simpler
autofs format described in the previous sections.
For details on the
amdmap format, see the
/usr/share/doc/autofs/README.amd-mapsfile, which is provided by the
14.9.3. Configuring autofs mount points
This procedure describes how to configure on-demand mount points using the
# yum install autofs
Start and enable the
# systemctl enable --now autofs
Create a map file for the on-demand mount point, located at
/etc/auto.identifier. Replace identifier with a name that identifies the mount point.
- In the map file, fill in the mount point, options, and location fields as described in Section 14.9.2, “The autofs configuration files”.
- Register the map file in the master map file, as described in Section 14.9.2, “The autofs configuration files”.
Try accessing content in the on-demand directory:
$ ls automounted-directory
14.9.4. Automounting NFS server user home directories with autofs service
This procedure describes how to configure the autofs service to mount user home directories automatically.
- The autofs package is installed.
- The autofs service is enabled and running.
Specify the mount point and location of the map file by editing the
/etc/auto.masterfile on a server on which you need to mount user home directories. To do so, add the following line into the
Create a map file with the name of
/etc/auto.homeon a server on which you need to mount user home directories, and edit the file with the following parameters:
* -fstype=nfs,rw,sync host.example.com:/home/&i
You can skip
fstypeparameter, as it is
nfsby default. For more information, see
# systemctl reload autofs
14.9.5. Overriding or augmenting autofs site configuration files
It is sometimes useful to override site defaults for a specific mount point on a client system.
Example 14.15. Initial conditions
For example, consider the following conditions:
Automounter maps are stored in NIS and the
/etc/nsswitch.conffile has the following directive:
automount: files nis
auto.mastermap file contains:
beth fileserver.example.com:/export/home/beth joe fileserver.example.com:/export/home/joe * fileserver.example.com:/export/home/&
The file map
/etc/auto.homedoes not exist.
Example 14.16. Mounting home directories from a different server
Given the preceding conditions, let’s assume that the client system needs to override the NIS map
auto.home and mount home directories from a different server.
In this case, the client needs to use the following
/home /etc/auto.home +auto.master
/etc/auto.homemap contains the entry:
Because the automounter only processes the first occurrence of a mount point, the
/home directory contains the content of
/etc/auto.home instead of the NIS
Example 14.17. Augmenting auto.home with only selected entries
Alternatively, to augment the site-wide
auto.home map with just a few entries:
/etc/auto.homefile map, and in it put the new entries. At the end, include the NIS
auto.homemap. Then the
/etc/auto.homefile map looks similar to:
mydir someserver:/export/mydir +auto.home
With these NIS
auto.homemap conditions, listing the content of the
$ ls /home beth joe mydir
This last example works as expected because
autofs does not include the contents of a file map of the same name as the one it is reading. As such,
autofs moves on to the next map source in the
14.9.6. Using LDAP to store automounter maps
This procedure configures
autofs to store automounter maps in LDAP configuration rather than in
autofs map files.
LDAP client libraries must be installed on all systems configured to retrieve automounter maps from LDAP. On Red Hat Enterprise Linux, the
openldappackage should be installed automatically as a dependency of the
To configure LDAP access, modify the
/etc/openldap/ldap.conffile. Ensure that the
schemaoptions are set appropriately for your site.
The most recently established schema for storing automount maps in LDAP is described by the
rfc2307bisdraft. To use this schema, set it in the
/etc/autofs.confconfiguration file by removing the comment characters from the schema definition. For example:
Example 14.18. Setting autofs configuration
DEFAULT_MAP_OBJECT_CLASS="automountMap" DEFAULT_ENTRY_OBJECT_CLASS="automount" DEFAULT_MAP_ATTRIBUTE="automountMapName" DEFAULT_ENTRY_ATTRIBUTE="automountKey" DEFAULT_VALUE_ATTRIBUTE="automountInformation"
Ensure that all other schema entries are commented in the configuration. The
automountKeyattribute replaces the
cnattribute in the
rfc2307bisschema. Following is an example of an LDAP Data Interchange Format (LDIF) configuration:
Example 14.19. LDF Configuration
# extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectclass=automountMap)(automountMapName=auto.master)) # requesting: ALL # # auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master # extended LDIF # # LDAPv3 # base <automountMapName=auto.master,dc=example,dc=com> with scope subtree # filter: (objectclass=automount) # requesting: ALL # # /home, auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: automount cn: /home automountKey: /home automountInformation: auto.home # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectclass=automountMap)(automountMapName=auto.home)) # requesting: ALL # # auto.home, example.com dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home # extended LDIF # # LDAPv3 # base <automountMapName=auto.home,dc=example,dc=com> with scope subtree # filter: (objectclass=automount) # requesting: ALL # # foo, auto.home, example.com dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo # /, auto.home, example.com dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: / automountInformation: filer.example.com:/export/&
14.10. Setting read-only permissions for the root file system
Sometimes, you need to mount the root file system (
/) with read-only permissions. Example use cases include enhancing security or ensuring data integrity after an unexpected system power-off.
14.10.1. Files and directories that always retain write permissions
For the system to function properly, some files and directories need to retain write permissions. When the root file system is mounted in read-only mode, these files are mounted in RAM using the
tmpfs temporary file system.
The default set of such files and directories is read from the
/etc/rwtab file, which contains:
dirs /var/cache/man dirs /var/gdm <content truncated> empty /tmp empty /var/cache/foomatic <content truncated> files /etc/adjtime files /etc/ntp.conf <content truncated>
Entries in the
/etc/rwtab file follow this format:
In this syntax:
- Replace copy-method with one of the keywords specifying how the file or directory is copied to tmpfs.
- Replace path with the path to the file or directory.
/etc/rwtab file recognizes the following ways in which a file or directory can be copied to
An empty path is copied to
tmpfs. For example:
A directory tree is copied to
tmpfs, empty. For example:
A file or a directory tree is copied to
tmpfsintact. For example:
The same format applies when adding custom paths to
14.10.2. Configuring the root file system to mount with read-only permissions on boot
With this procedure, the root file system is mounted read-only on all following boots.
/etc/sysconfig/readonly-rootfile, set the
# Set to 'yes' to mount the file systems as read-only. READONLY=yes
rooption in the root entry (
/) in the
/dev/mapper/luks-c376919e... / xfs x-systemd.device-timeout=0,ro 1 1
rooption to the
GRUB_CMDLINE_LINUXdirective in the
/etc/default/grubfile and ensure that the directive does not contain
GRUB_CMDLINE_LINUX="rhgb quiet... ro"
Recreate the GRUB2 configuration file:
# grub2-mkconfig -o /boot/grub2/grub.cfg
If you need to add files and directories to be mounted with write permissions in the
tmpfsfile system, create a text file in the
/etc/rwtab.d/directory and put the configuration there.
For example, to mount the
/etc/example/filefile with write permissions, add this line to the
Changes made to files and directories in
tmpfsdo not persist across boots.
- Reboot the system to apply the changes.
If you mount the root file system with read-only permissions by mistake, you can remount it with read-and-write permissions again using the following command:
# mount -o remount,rw /