Managing file systems

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: xfs

   • The volume name (barefs in the example) is currently arbitrary. The storage role identifies the volume by the disk device listed under the disks: attribute.
   • You can omit the fs_type: xfs line because XFS is the default file system in RHEL 8.

   • To create the file system on an LV, provide the LVM setup under the disks: attribute, including the enclosing volume group. For details, see Managing logical volumes by using the storage RHEL system role.

     Do not provide the path to the LV device.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: xfs
           mount_point: /mnt/data
           mount_user: somebody
           mount_group: somegroup
           mount_mode: 0755

   • This playbook adds the file system to the /etc/fstab file, and mounts the file system immediately.
   • If the file system on the /dev/sdb device or the mount point directory do not exist, the playbook creates them.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_pools:
         - name: myvg
           disks:
             - sda
             - sdb
             - sdc
           volumes:
             - name: mylv
               size: 2G
               fs_type: ext4
               mount_point: /mnt/dat

   • The myvg volume group consists of the following disks: /dev/sda, /dev/sdb, and /dev/sdc.
   • If the myvg volume group already exists, the playbook adds the logical volume to the volume group.
   • If the myvg volume group does not exist, the playbook creates it.
   • The playbook creates an Ext4 file system on the mylv logical volume, and persistently mounts the file system at /mnt.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: xfs
           mount_point: /mnt/data
           mount_options: discard

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: ext4
           fs_label: label-name
           mount_point: /mnt/data

   • The playbook creates the file system on the /dev/sdb disk.
   • The playbook persistently mounts the file system at the /mnt/data directory.
   • The label of the file system is label-name.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: all
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: ext3
           fs_label: label-name
           mount_point: /mnt/data
           mount_user: somebody
           mount_group: somegroup
           mount_mode: 0755

   • The playbook creates the file system on the /dev/sdb disk.
   • The playbook persistently mounts the file system at the /mnt/data directory.
   • The label of the file system is label-name.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create LVM pool over three disks
     hosts: managed-node-01.example.com
     tasks:
       - name: Resize LVM logical volume with file system
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
             - name: myvg
               disks:
                 - /dev/sda
                 - /dev/sdb
                 - /dev/sdc
               volumes:
                 - name: mylv1
                   size: 10 GiB
                   fs_type: ext4
                   mount_point: /opt/mount1
                 - name: mylv2
                   size: 50 GiB
                   fs_type: ext4
                   mount_point: /opt/mount2

   This playbook resizes the following existing file systems:

   • The Ext4 file system on the mylv1 volume, which is mounted at /opt/mount1, resizes to 10 GiB.
   • The Ext4 file system on the mylv2 volume, which is mounted at /opt/mount2, resizes to 50 GiB.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a disk device with swap
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: swap_fs
           type: disk
           disks:
             - /dev/sdb
           size: 15 GiB
           fs_type: swap

   The volume name (swap_fs in the example) is currently arbitrary. The storage role identifies the volume by the disk device listed under the disks: attribute.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a RAID on sdd, sde, sdf, and sdg
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_safe_mode: false
           storage_volumes:
             - name: data
               type: raid
               disks: [sdd, sde, sdf, sdg]
               raid_level: raid0
               raid_chunk_size: 32 KiB
               mount_point: /mnt/data
               state: present

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure LVM pool with RAID
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_safe_mode: false
       storage_pools:
         - name: my_pool
           type: lvm
           disks: [sdh, sdi]
           raid_level: raid1
           volumes:
             - name: my_volume
               size: "1 GiB"
               mount_point: "/mnt/app/shared"
               fs_type: xfs
               state: present

   To create an LVM pool with RAID, you must specify the RAID type by using the raid_level parameter.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure stripe size for RAID LVM volumes
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_safe_mode: false
       storage_pools:
         - name: my_pool
           type: lvm
           disks: [sdh, sdi]
           volumes:
             - name: my_volume
               size: "1 GiB"
               mount_point: "/mnt/app/shared"
               fs_type: xfs
               raid_level: raid1
               raid_stripe_size: "256 KiB"
               state: present

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   - name: Create LVM VDO volume under volume group 'myvg'
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_pools:
         - name: myvg
           disks:
             - /dev/sdb
           volumes:
             - name: mylv1
               compression: true
               deduplication: true
               vdo_pool_size: 10 GiB
               size: 30 GiB
               mount_point: /mnt/app/shared

   In this example, the compression and deduplication pools are set to true, which specifies that the VDO is used. The following describes the usage of these parameters:

   • The deduplication is used to deduplicate the duplicated data stored on the storage volume.
   • The compression is used to compress the data stored on the storage volume, which results in more storage capacity.
   • The vdo_pool_size specifies the actual size the volume takes on the device. The virtual size of VDO volume is set by the size parameter.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create and configure a volume encrypted with LUKS
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: <password>

   You can also add other encryption parameters, such as encryption_key, encryption_cipher, encryption_key_size, and encryption_luks, to the playbook file.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. View the encryption status:

   # cryptsetup status sdb
   
   /dev/mapper/sdb is active and is in use.
   type: LUKS2
   cipher: aes-xts-plain64
   keysize: 512 bits
   key location: keyring
   device: /dev/sdb
   ...

2. Verify the created LUKS encrypted volume:

   # cryptsetup luksDump /dev/sdb
   
   Version:        2
   Epoch:          6
   Metadata area:  16384 [bytes]
   Keyslots area:  33521664 [bytes]
   UUID:           a4c6be82-7347-4a91-a8ad-9479b72c9426
   Label:          (no label)
   Subsystem:      (no subsystem)
   Flags:          allow-discards
   
   Data segments:
     0: crypt
           offset: 33554432 [bytes]
           length: (whole device)
           cipher: aes-xts-plain64
           sector: 4096 [bytes]
   ...

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Express volume sizes as a percentage of the pool's total size
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_pools:
         - name: myvg
           disks:
             - /dev/sdb
           volumes:
             - name: data
               size: 60%
               mount_point: /opt/mount/data
             - name: web
               size: 30%
               mount_point: /opt/mount/web
             - name: cache
               size: 10%
               mount_point: /opt/cache/mount

   This example specifies the size of LVM volumes as a percentage of the pool size, for example: 60%. Alternatively, you can also specify the size of LVM volumes as a percentage of the pool size in a human-readable size of the file system, for example, 10g or 50 GiB.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click the Storage tab.

   In the Storage table, you can see all available partitions formatted with file systems, their ID, types, locations, sizes, and how much space is available on each partition.

   

   You can also use the drop-down menu in the top-right corner to create new local or networked storage.

   

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click the Storage tab.
3. In the Storage table, click the device which you want to partition to open the page and options for that device.
4. On the device page, click the menu button, ⋮, and select Create partition table.

5. In the Initialize disk dialog box, select the following:

   1. Partitioning:

      • Compatible with all systems and devices (MBR)
      • Compatible with modern system and hard disks > 2TB (GPT)
      • No partitioning

   2. Overwrite:

      • Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you need to overwrite it.

        If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

6. Click Initialize.
7. Click the menu button, ⋮, next to the partition table you created. It is named Free space by default.
8. Click Create partition.
9. In the Create partition dialog box, enter a Name for the file system.
10. Add a Mount point.

11. In the Type drop-down menu, select a file system:

    • XFS file system supports large logical volumes, switching physical drives online without outage, and growing an existing file system. Leave this file system selected if you do not have a different strong preference.

    • ext4 file system supports:

      • Logical volumes
      • Switching physical drives online without outage
      • Growing a file system
      • Shrinking a file system

    Additional option is to enable encryption of partition done by LUKS (Linux Unified Key Setup), which allows you to encrypt the volume with a passphrase.

12. Enter the Size of the volume you want to create.

13. Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you need to overwrite it.

    If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

14. If you want to encrypt the volume, select the type of encryption in the Encryption drop-down menu.

    If you do not want to encrypt the volume, select No encryption.

15. In the At boot drop-down menu, select when you want to mount the volume.

16. In Mount options section:

    1. Select the Mount read only checkbox if you want the to mount the volume as a read-only logical volume.
    2. Select the Custom mount options checkbox and add the mount options if you want to change the default mount option.

17. Create the partition:

    • If you want to create and mount the partition, click the Create and mount button.

    • If you want to only create the partition, click the Create only button.

      Formatting can take several minutes depending on the volume size and which formatting options are selected.

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click the Storage tab.
3. Click the device from which you want to delete a partition.
4. On the device page and in the GPT partitions section, click the menu button, ⋮ next to the partition you want to delete.

5. From the drop-down menu, select Delete.

   The RHEL web console terminates all processes that are currently using the partition and unmount the partition before deleting it.

Procedure

1. By default, NFSv3 RPC services use random ports. To enable a firewall configuration, configure fixed port numbers in the /etc/nfs.conf file:

   1. In the [lockd] section, set a fixed port number for the nlockmgr RPC service, for example:

      port=5555

      With this setting, the service automatically uses this port number for both the UDP and TCP protocol.

   2. In the [statd] section, set a fixed port number for the rpc.statd service, for example:

      port=6666

      With this setting, the service automatically uses this port number for both the UDP and TCP protocol.

2. Open the relevant ports in firewalld:

   # firewall-cmd --permanent --add-service=rpc-bind
   # firewall-cmd --permanent --add-port={5555/tcp,5555/udp,6666/tcp,6666/udp}
   # firewall-cmd --reload

3. Restart the rpc-statd service:

   # systemctl restart rpc-statd nfs-server

Procedure

1. Edit the /etc/fstab file and add a line for the share that you want to mount:

   <nfs_server_ip_or_hostname>:/<exported_share> <mount point> nfs default 0 0

   For example, to mount the /nfs/home share from the server.example.com NFS server to /home, enter:

   server.example.com:/nfs/projects    	/home        nfs 	defaults    	0 0

2. Mount the share:

   # mount /home

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button.

4. From the drop-down menu, select New NFS mount.

   

5. In the New NFS Mount dialog box, enter the server or IP address of the remote server.
6. In the Path on Server field, enter the path to the directory that you want to mount.
7. In the Local Mount Point field, enter the path to the directory on your local system where you want to mount the NFS.

8. In the Mount options check box list, select how you want to mount the NFS. You can select multiple options depending on your requirements.

   • Check the Mount at boot box if you want the directory to be reachable even after you restart the local system.
   • Check the Mount read only box if you do not want to change the content of the NFS.

   • Check the Custom mount options box and add the mount options if you want to change the default mount option.

     

9. Click Add.

Procedure

1. Log in to the RHEL 8 web console. For details, see Logging in to the web console.
2. Click Storage.
3. In the Storage table, click the NFS mount you want to adjust.

4. If the remote directory is mounted, click Unmount.

   You must unmount the directory during the custom mount options configuration. Otherwise, the web console does not save the configuration and this causes an error.

5. Click Edit.
6. In the NFS Mount dialog box, select Custom mount option.

7. Enter mount options separated by a comma. For example:

   • nfsvers=4: The NFS protocol version number
   • soft: The type of recovery after an NFS request times out
   • sec=krb5: The files on the NFS server can be secured by Kerberos authentication. Both the NFS client and server have to support Kerberos authentication.

   For a complete list of the NFS mount options, enter man nfs in the command line.

8. Click Apply.
9. Click Mount.

Procedure

1. Obtain a kerberos ticket as an IdM administrator:

   # kinit admin

2. Retrieve the host principal, and store it in the /etc/krb5.keytab file:

   # ipa-getkeytab -s idm_server.idm.example.com -p host/nfs_client.idm.example.com -k /etc/krb5.keytab

   IdM automatically created the host principal when you joined the host to the IdM domain.

3. Optional: Display the principals in the /etc/krb5.keytab file:

   # klist -k /etc/krb5.keytab
   Keytab name: FILE:/etc/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM
      6 host/nfs_client.idm.example.com@IDM.EXAMPLE.COM

4. Use the ipa-client-automount utility to configure mapping of IdM IDs:

   # ipa-client-automount
   Searching for IPA server...
   IPA server: DNS discovery
   Location: default
   Continue to configure the system with these values? [no]: yes
   Configured /etc/idmapd.conf
   Restarting sssd, waiting for it to become available.
   Started autofs

5. Mount an exported NFS share, for example:

   # mount -o sec=krb5i server.idm.example.com:/nfs/projects/ /mnt/

   The -o sec option specifies the Kerberos security method.

Verification

1. Log in as an IdM user who has permissions to write on the mounted share.

2. Obtain a Kerberos ticket:

   $ kinit

3. Create a file on the share, for example:

   $ touch /mnt/test.txt

4. List the directory to verify that the file was created:

   $ ls -l /mnt/test.txt
   -rw-r--r--. 1 admin users 0 Feb 15 11:54 /mnt/test.txt

Procedure

1. Create the /etc/dconf/profile/user file and add the following to it:

   service-db:keyfile/user

   With this setting, dconf polls the keyfile back end to determine whether updates have been made, so settings might not be updated immediately.

2. The changes take effect when the users logs out and in.

Procedure

1. Set the server min protocol parameter in the [global] section in the /etc/samba/smb.conf file to NT1.

2. Mount the share using the SMB 1 protocol by providing the -o vers=1.0 option to the mount command. For example:

   # mount -t cifs -o vers=1.0,username=<user_name> //<server_name>/<share_name> /mnt/

   By default, the kernel module uses SMB 2 or the highest later protocol version supported by the server. Passing the -o vers=1.0 option to the mount command forces that the kernel module uses the SMB 1 protocol that is required for using UNIX extensions.

Procedure

1. Add an entry for the share to the /etc/fstab file. For example:

   //<server_name>/<share_name>  /mnt  cifs  credentials=/root/smb.cred  0 0

   Important

   To enable the system to mount a share automatically, you must store the user name, password, and domain name in a credentials file. For details, see Creating a credentials file to authenticate to an SMB share

   In the fourth field of the row in the /etc/fstab, specify mount options, such as the path to the credentials file. For details, see the OPTIONS section in the mount.cifs(8) man page and Frequently used mount options.

Procedure

1. Create a file, such as /root/smb.cred, and specify the user name, password, and domain name that file:

   username=user_name
   password=password
   domain=domain_name

2. Set the permissions to only allow the owner to access the file:

   # chown user_name /root/smb.cred
   # chmod 600 /root/smb.cred

Procedure

1. Start the parted utility. For example, the following output lists the device /dev/sda:

   # parted /dev/sda

2. View the partition table:

   # (parted) print
   
   Model: ATA SAMSUNG MZNLN256 (scsi)
   Disk /dev/sda: 256GB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   Disk Flags:
   
   Number  Start   End     Size    Type      File system  Flags
    1      1049kB  269MB   268MB   primary   xfs          boot
    2      269MB   34.6GB  34.4GB  primary
    3      34.6GB  45.4GB  10.7GB  primary
    4      45.4GB  256GB   211GB   extended
    5      45.4GB  256GB   211GB   logical

3. Optional: Switch to the device you want to examine next:

   # (parted) select block-device

Procedure

1. Start the interactive parted shell:

   # parted block-device

2. Determine if there already is a partition table on the device:

   # (parted) print

   If the device already contains partitions, they will be deleted in the following steps.

3. Create the new partition table:

   # (parted) mklabel table-type

   • Replace table-type with with the intended partition table type:

     • msdos for MBR
     • gpt for GPT

   Example 7.1. Creating a GUID Partition Table (GPT) table

   To create a GPT table on the disk, use:

   # (parted) mklabel gpt

   The changes start applying after you enter this command.

4. View the partition table to confirm that it is created:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

Procedure

1. Start the parted utility:

   # parted block-device

2. View the current partition table to determine if there is enough free space:

   # (parted) print

   • Resize the partition in case there is not enough free space.

   • From the partition table, determine:

     • The start and end points of the new partition.
     • On MBR, what partition type it should be.

3. Create the new partition:

   # (parted) mkpart part-type name fs-type start end

   • Replace part-type with with primary, logical, or extended. This applies only to the MBR partition table.
   • Replace name with an arbitrary partition name. This is required for GPT partition tables.
   • Replace fs-type with xfs, ext2, ext3, ext4, fat16, fat32, hfs, hfs+, linux-swap, ntfs, or reiserfs. The fs-type parameter is optional. Note that the parted utility does not create the file system on the partition.
   • Replace start and end with the sizes that determine the starting and ending points of the partition, counting from the beginning of the disk. You can use size suffixes, such as 512MiB, 20GiB, or 1.5TiB. The default size is in megabytes.

   Example 7.2. Creating a small primary partition

   To create a primary partition from 1024MiB until 2048MiB on an MBR table, use:

   # (parted) mkpart primary 1024MiB 2048MiB

   The changes start applying after you enter the command.

4. View the partition table to confirm that the created partition is in the partition table with the correct partition type, file system type, and size:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

6. Register the new device node:

   # udevadm settle

7. Verify that the kernel recognizes the new partition:

   # cat /proc/partitions

Procedure

1. Start the interactive parted shell:

   # parted block-device

   • Replace block-device with the path to the device where you want to remove a partition: for example, /dev/sda.

2. View the current partition table to determine the minor number of the partition to remove:

   (parted) print

3. Remove the partition:

   (parted) rm minor-number

   • Replace minor-number with the minor number of the partition you want to remove.

   The changes start applying as soon as you enter this command.

4. Verify that you have removed the partition from the partition table:

   (parted) print

5. Exit the parted shell:

   (parted) quit

6. Verify that the kernel registers that the partition is removed:

   # cat /proc/partitions

7. Remove the partition from the /etc/fstab file, if it is present. Find the line that declares the removed partition, and remove it from the file.

8. Regenerate mount units so that your system registers the new /etc/fstab configuration:

   # systemctl daemon-reload

9. If you have deleted a swap partition or removed pieces of LVM, remove all references to the partition from the kernel command line:

   1. List active kernel options and see if any option references the removed partition:

      # grubby --info=ALL

   2. Remove the kernel options that reference the removed partition:

      # grubby --update-kernel=ALL --remove-args="option"

10. To register the changes in the early boot system, rebuild the initramfs file system:

    # dracut --force --verbose

Procedure

1. Start the parted utility:

   # parted block-device

2. View the current partition table:

   # (parted) print

   From the partition table, determine:

   • The minor number of the partition.
   • The location of the existing partition and its new ending point after resizing.

3. Resize the partition:

   # (parted) resizepart 1 2GiB

   • Replace 1 with the minor number of the partition that you are resizing.
   • Replace 2 with the size that determines the new ending point of the resized partition, counting from the beginning of the disk. You can use size suffixes, such as 512MiB, 20GiB, or 1.5TiB. The default size is in megabytes.

4. View the partition table to confirm that the resized partition is in the partition table with the correct size:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

6. Verify that the kernel registers the new partition:

   # cat /proc/partitions

7. Optional: If you extended the partition, extend the file system on it as well.

Procedure

1. To create the file system:

   • If the device is a regular partition, an LVM volume, an MD volume, a disk, or a similar device, use the following command:

     # mkfs.xfs block-device

     • Replace block-device with the path to the block device. For example, /dev/sdb1, /dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a, or /dev/my-volgroup/my-lv.
     • In general, the default options are optimal for common use.
     • When using mkfs.xfs on a block device containing an existing file system, add the -f option to overwrite that file system.

   • To create the file system on a hardware RAID device, check if the system correctly detects the stripe geometry of the device:

     • If the stripe geometry information is correct, no additional options are needed. Create the file system:

       # mkfs.xfs block-device

     • If the information is incorrect, specify stripe geometry manually with the su and sw parameters of the -d option. The su parameter specifies the RAID chunk size, and the sw parameter specifies the number of data disks in the RAID device.

       For example:

       # mkfs.xfs -d su=64k,sw=4 /dev/sda3

2. Use the following command to wait for the system to register the new device node:

   # udevadm settle

Procedure

1. Replay the log by mounting and unmounting the file system:

   # mount file-system
   # umount file-system

   Note

   If the mount fails with a structure needs cleaning error, the log is corrupted and cannot be replayed. The dry run should discover and report more on-disk corruption as a result.

2. Use the xfs_repair utility to perform a dry run to check the file system. Any errors are printed and an indication of the actions that would be taken, without modifying the file system.

   # xfs_repair -n block-device

3. Mount the file system:

   # mount file-system

Procedure

1. Create a metadata image prior to repair for diagnostic or testing purposes using the xfs_metadump utility. A pre-repair file system metadata image can be useful for support investigations if the corruption is due to a software bug. Patterns of corruption present in the pre-repair image can aid in root-cause analysis.

   • Use the xfs_metadump debugging tool to copy the metadata from an XFS file system to a file. The resulting metadump file can be compressed using standard compression utilities to reduce the file size if large metadump files need to be sent to support.

     # xfs_metadump block-device metadump-file

2. Replay the log by remounting the file system:

   # mount file-system
   # umount file-system

3. Use the xfs_repair utility to repair the unmounted file system:

   • If the mount succeeded, no additional options are required:

     # xfs_repair block-device

   • If the mount failed with the Structure needs cleaning error, the log is corrupted and cannot be replayed. Use the -L option (force log zeroing) to clear the log:

     Warning

     This command causes all metadata updates in progress at the time of the crash to be lost, which might cause significant file system damage and data loss. This should be used only as a last resort if the log cannot be replayed.

     # xfs_repair -L block-device

4. Mount the file system:

   # mount file-system

Procedure

1. Replay the log by remounting the file system:

   # mount file-system
   # umount file-system

2. Perform a dry run to check the file system.

   # e2fsck -n block-device

   Note

   Any errors are printed and an indication of the actions that would be taken, without modifying the file system. Later phases of consistency checking may print extra errors as it discovers inconsistencies which would have been fixed in early phases if it were running in repair mode.

Procedure

1. Save a file system image for support investigations. A pre-repair file system metadata image can be useful for support investigations if the corruption is due to a software bug. Patterns of corruption present in the pre-repair image can aid in root-cause analysis.

   Note

   Severely damaged file systems may cause problems with metadata image creation.

   • If you are creating the image for testing purposes, use the -r option to create a sparse file of the same size as the file system itself. e2fsck can then operate directly on the resulting file.

     # e2image -r block-device image-file

   • If you are creating the image to be archived or provided for diagnostic, use the -Q option, which creates a more compact file format suitable for transfer.

     # e2image -Q block-device image-file

2. Replay the log by remounting the file system:

   # mount file-system
   # umount file-system

3. Automatically repair the file system. If user intervention is required, e2fsck indicates the unfixed problem in its output and reflects this status in the exit code.

   # e2fsck -p block-device

   Additional resources

   • e2image(8) man page on your system
   • e2fsck(8) man page on your system

Procedure

1. To attach a certain file system, use the mount utility:

   # mount device mount-point

   Example 16.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

2. If mount cannot recognize the file system type automatically, specify it using the --types option:

   # mount --types type device mount-point

   Example 16.3. Mounting an NFS file system

   For example, to mount a remote NFS file system:

   # mount --types nfs4 host:/remote-export /mnt/nfs

Procedure

1. To change the directory in which a file system is mounted:

   # mount --move old-directory new-directory

   Example 16.4. Moving a home file system

   For example, to move the file system mounted in the /mnt/userdirs/ directory to the /home/ mount point:

   # mount --move /mnt/userdirs /home

2. Verify that the file system has been moved as expected:

   $ findmnt
   $ ls old-directory
   $ ls new-directory

Procedure

1. Try unmounting the file system using either of the following commands:

   • By mount point:

     # umount mount-point

   • By device:

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

2. If the file system is in use, use the fuser utility to determine which processes are accessing it. For example:

   $ fuser --mount /run/media/user/FlashDrive
   
   /run/media/user/FlashDrive: 18351

   Afterwards, stop the processes using the file system and try unmounting it again.

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click the Storage tab.
3. In the Storage table, select a volume from which you want to delete the partition.
4. In the GPT partitions section, click the menu button, ⋮ next to the partition whose file system you want to mount or unmount.
5. Click Mount or Unmount.

Procedure

1. Create a virtual file system (VFS) node from the original mount point:

   # mount --bind original-dir original-dir

2. Mark the original mount point as private:

   # mount --make-private original-dir

   Alternatively, to change the mount type for the selected mount point and all mount points under it, use the --make-rprivate option instead of --make-private.

3. Create the duplicate:

   # mount --bind original-dir duplicate-dir

Procedure

1. Create a virtual file system (VFS) node from the original mount point:

   # mount --bind original-dir original-dir

2. Mark the original mount point as shared:

   # mount --make-shared original-dir

   Alternatively, to change the mount type for the selected mount point and all mount points under it, use the --make-rshared option instead of --make-shared.

3. Create the duplicate:

   # mount --bind original-dir duplicate-dir

Procedure

1. Create a virtual file system (VFS) node from the original mount point:

   # mount --bind original-dir original-dir

2. Mark the original mount point as shared:

   # mount --make-shared original-dir

   Alternatively, to change the mount type for the selected mount point and all mount points under it, use the --make-rshared option instead of --make-shared.

3. Create the duplicate and mark it as the slave type:

   # mount --bind original-dir duplicate-dir
   # mount --make-slave duplicate-dir

1. The block device identified by a persistent attribute or a path in the /dev directory.
2. The directory where the device will be mounted.
3. The file system on the device.
4. Mount options for the file system, which includes the defaults option to mount the partition at boot time with default options. The mount option field also recognizes the systemd mount unit options in the x-systemd.option format.
5. Backup option for the dump utility.
6. Check order for the fsck utility.

Procedure

1. Find out the UUID attribute of the file system:

   $ lsblk --fs storage-device

   For example:

   Example 18.2. Viewing the UUID of a partition

   $ lsblk --fs /dev/sda1
   
   NAME FSTYPE LABEL UUID                                 MOUNTPOINT
   sda1 xfs    Boot  ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot

2. If the mount point directory does not exist, create it:

   # mkdir --parents mount-point

3. As root, edit the /etc/fstab file and add a line for the file system, identified by the UUID.

   For example:

   Example 18.3. The /boot mount point in /etc/fstab

   UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0

4. Regenerate mount units so that your system registers the new configuration:

   # systemctl daemon-reload

5. Try mounting the file system to verify that the configuration works:

   # mount mount-point

Procedure

1. 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.
2. In the map file, enter the mount point, options, and location fields as described in The autofs configuration files section.
3. Register the map file in the master map file, as described in The autofs configuration files section.

4. Allow the service to re-read the configuration, so it can manage the newly configured autofs mount:

   # systemctl reload autofs.service

5. Try accessing content in the on-demand directory:

   # ls automounted-directory

Procedure

1. Specify the mount point and location of the map file by editing the /etc/auto.master file on a server on which you need to mount user home directories. To do so, add the following line into the /etc/auto.master file:

   /home /etc/auto.home

2. Create a map file with the name of /etc/auto.home on 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/&

   You can skip fstype parameter, as it is nfs by default. For more information, see autofs(5) man page on your system.

3. Reload the autofs service:

   # systemctl reload autofs

Procedure

1. To configure LDAP access, modify the /etc/openldap/ldap.conf file. Ensure that the BASE, URI, and schema options are set appropriately for your site.

2. The most recently established schema for storing automount maps in LDAP is described by the rfc2307bis draft. To use this schema, set it in the /etc/autofs.conf configuration file by removing the comment characters from the schema definition. For example:

   Example 19.6. 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"

3. Ensure that all other schema entries are commented in the configuration. The automountKey attribute of the rfc2307bis schema replaces the cn attribute of the rfc2307 schema. Following is an example of an LDAP Data Interchange Format (LDIF) configuration:

   Example 19.7. LDIF Configuration

   # auto.master, example.com
   dn: automountMapName=auto.master,dc=example,dc=com
   objectClass: top
   objectClass: automountMap
   automountMapName: auto.master
   
   # /home, auto.master, example.com
   dn: automountMapName=auto.master,dc=example,dc=com
   objectClass: automount
   automountKey: /home
   automountInformation: auto.home
   
   # auto.home, example.com
   dn: automountMapName=auto.home,dc=example,dc=com
   objectClass: automountMap
   automountMapName: auto.home
   
   # 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/&

Procedure

1. Add desired fstab entry as documented in Persistently mounting file systems. For example:

   /dev/disk/by-id/da875760-edb9-4b82-99dc-5f4b1ff2e5f4  /mount/point  xfs  defaults  0 0

2. Add x-systemd.automount to the options field of entry created in the previous step.

3. Load newly created units so that your system registers the new configuration:

   # systemctl daemon-reload

4. Start the automount unit:

   # systemctl start mount-point.automount

Verification

1. Check that mount-point.automount is running:

   # systemctl status mount-point.automount

2. Check that automounted directory has desired content:

   # ls /mount/point

Procedure

1. Create a mount unit. For example:

   mount-point.mount
   [Mount]
   What=/dev/disk/by-uuid/f5755511-a714-44c1-a123-cfde0e4ac688
   Where=/mount/point
   Type=xfs

2. Create a unit file with the same name as the mount unit, but with extension .automount.

3. Open the file and create an [Automount] section. Set the Where= option to the mount path:

   [Automount]
   Where=/mount/point
   [Install]
   WantedBy=multi-user.target

4. Load newly created units so that your system registers the new configuration:

   # systemctl daemon-reload

5. Enable and start the automount unit instead:

   # systemctl enable --now mount-point.automount

Verification

1. Check that mount-point.automount is running:

   # systemctl status mount-point.automount

2. Check that automounted directory has desired content:

   # ls /mount/point

Procedure

1. Edit the /etc/autofs.conf file to specify the schema attributes that autofs searches for:

   #
   # Other common LDAP naming
   #
   map_object_class = "automountMap"
   entry_object_class = "automount"
   map_attribute = "automountMapName"
   entry_attribute = "automountKey"
   value_attribute = "automountInformation"

   Note

   User can write the attributes in both lower and upper cases in the /etc/autofs.conf file.

2. Optional: Specify the LDAP configuration. There are two ways to do this. The simplest is to let the automount service discover the LDAP server and locations on its own:

   ldap_uri = "ldap:///dc=example,dc=com"

   This option requires DNS to contain SRV records for the discoverable servers.

   Alternatively, explicitly set which LDAP server to use and the base DN for LDAP searches:

   ldap_uri = "ldap://ipa.example.com"
   search_base = "cn=location,cn=automount,dc=example,dc=com"

3. Edit the /etc/autofs_ldap_auth.conf file so that autofs allows client authentication with the IdM LDAP server.

   • Change authrequired to yes.

   • Set the principal to the Kerberos host principal for the IdM LDAP server, host/FQDN@REALM. The principal name is used to connect to the IdM directory as part of GSS client authentication.

     <autofs_ldap_sasl_conf
          usetls="no"
          tlsrequired="no"
          authrequired="yes"
          authtype="GSSAPI"
          clientprinc="host/server.example.com@EXAMPLE.COM"
          />

     For more information about host principal, see Using canonicalized DNS host names in IdM.

     If necessary, run klist -k to get the exact host principal information.

Procedure

1. Open the SSSD configuration file:

   # vim /etc/sssd/sssd.conf

2. Add the autofs service to the list of services handled by SSSD.

   [sssd]
   domains = ldap
   services = nss,pam,autofs

3. Create a new [autofs] section. You can leave this blank, because the default settings for an autofs service work with most infrastructures.

   [nss]
   
   [pam]
   
   [sudo]
   
   [autofs]
   
   [ssh]
   
   [pac]

   For more information, see the sssd.conf man page on your system.

4. Optional: Set a search base for the autofs entries. By default, this is the LDAP search base, but a subtree can be specified in the ldap_autofs_search_base parameter.

   [domain/EXAMPLE]
   
   ldap_search_base = "dc=example,dc=com"
   ldap_autofs_search_base = "ou=automount,dc=example,dc=com"

5. Restart SSSD service:

   # systemctl restart sssd.service

6. Check the /etc/nsswitch.conf file, so that SSSD is listed as a source for automount configuration:

   automount: sss files

7. Restart autofs service:

   # systemctl restart autofs.service

8. Test the configuration by listing a user’s /home directory, assuming there is a master map entry for /home:

   # ls /home/userName

   If this does not mount the remote file system, check the /var/log/messages file for errors. If necessary, increase the debug level in the /etc/sysconfig/autofs file by setting the logging parameter to debug.

Procedure

1. In the /etc/sysconfig/readonly-root file, set the READONLY option to yes to mount the file systems as read-only:

   READONLY=yes

2. Add the ro option in the root entry (/) in the /etc/fstab file:

   /dev/mapper/luks-c376919e...  /  xfs  x-systemd.device-timeout=0,ro  1  1

3. Enable the ro kernel option:

   # grubby --update-kernel=ALL --args="ro"

4. Ensure that the rw kernel option is disabled:

   # grubby --update-kernel=ALL --remove-args="rw"

5. If you need to add files and directories to be mounted with write permissions in the tmpfs file system, create a text file in the /etc/rwtab.d/ directory and put the configuration there.

   For example, to mount the /etc/example/file file with write permissions, add this line to the /etc/rwtab.d/example file:

   files /etc/example/file

   Important

   Changes made to files and directories in tmpfs do not persist across boots.

6. Reboot the system to apply the changes.

Procedure

1. Enable quotas for users:

   # mount -o uquota /dev/xvdb1 /xfs

   Replace uquota with uqnoenforce to allow usage reporting without enforcing any limits.

2. Enable quotas for groups:

   # mount -o gquota /dev/xvdb1 /xfs

   Replace gquota with gqnoenforce to allow usage reporting without enforcing any limits.

3. Enable quotas for projects:

   # mount -o pquota /dev/xvdb1 /xfs

   Replace pquota with pqnoenforce to allow usage reporting without enforcing any limits.

4. Alternatively, include the quota mount options in the /etc/fstab file. The following example shows entries in the /etc/fstab file to enable quotas for users, groups, and projects, respectively, on an XFS file system. These examples also mount the file system with read/write permissions:

   # vim /etc/fstab
   /dev/xvdb1    /xfs    xfs    rw,quota       0  0
   /dev/xvdb1    /xfs    xfs    rw,gquota      0  0
   /dev/xvdb1    /xfs    xfs    rw,prjquota    0  0

Procedure

1. Start the xfs_quota shell:

   # xfs_quota

2. Show usage and limits for the given user:

   # xfs_quota> quota username

3. Show free and used counts for blocks and inodes:

   # xfs_quota> df

4. Run the help command to display the basic commands available with xfs_quota.

   # xfs_quota> help

5. Specify q to exit xfs_quota.

   # xfs_quota> q

Procedure

1. Start the xfs_quota shell with the -x option to enable expert mode:

   # xfs_quota -x

2. Report quota information for a specific file system:

   # xfs_quota> report /path

   For example, to display a sample quota report for /home (on /dev/blockdevice), use the command report -h /home. This displays output similar to the following:

   User quota on /home (/dev/blockdevice)
   Blocks
   User ID      Used   Soft   Hard Warn/Grace
   ---------- ---------------------------------
   root            0      0      0  00 [------]
   testuser   103.4G      0      0  00 [------]

3. Modify quota limits:

   # xfs_quota> limit isoft=500m ihard=700m user /path

   For example, to set a soft and hard inode count limit of 500 and 700 respectively for user john, whose home directory is /home/john, use the following command:

   # xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/

   In this case, pass mount_point which is the mounted xfs file system.

4. Run the help command to display the expert commands available with xfs_quota -x:

   # xfs_quota> help

Procedure

1. Add the project-controlled directories to /etc/projects. For example, the following adds the /var/log path with a unique ID of 11 to /etc/projects. Your project ID can be any numerical value mapped to your project.

   # echo 11:/var/log >> /etc/projects

2. Add project names to /etc/projid to map project IDs to project names. For example, the following associates a project called logfiles with the project ID of 11 as defined in the previous step.

   # echo logfiles:11 >> /etc/projid

3. Initialize the project directory. For example, the following initializes the project directory /var:

   # xfs_quota -x -c 'project -s logfiles' /var

4. Configure quotas for projects with initialized directories:

   # xfs_quota -x -c 'limit -p bhard=1g logfiles' /var

Procedure

1. Enable quotas on file system creation:

   # mkfs.ext4 -O quota /dev/sda

   Note

   Only user and group quotas are enabled and initialized by default.

2. Change the defaults on file system creation:

   # mkfs.ext4 -O quota -E quotatype=usrquota:grpquota:prjquota /dev/sda

3. Mount the file system:

   # mount /dev/sda

Procedure

1. Unmount the file system:

   # umount /dev/sda

2. Enable quotas on existing file system:

   # tune2fs -O quota /dev/sda

   Note

   Only user and group quotas are initialized by default.

3. Change the defaults:

   # tune2fs -Q usrquota,grpquota,prjquota /dev/sda

4. Mount the file system:

   # mount /dev/sda

Procedure

1. Assign the quota for a user:

   # edquota username

   Replace username with the user to which you want to assign the quotas.

   For example, if you enable a quota for the /dev/sda partition and execute the command edquota testuser, the following is displayed in the default editor configured on the system:

   Disk quotas for user testuser (uid 501):
   Filesystem   blocks   soft   hard   inodes   soft   hard
   /dev/sda      44043      0      0    37418      0      0

2. Change the desired limits.

   If any of the values are set to 0, limit is not set. Change them in the text editor.

   For example, the following shows the soft and hard block limits for the testuser have been set to 50000 and 55000 respectively.

   Disk quotas for user testuser (uid 501):
   Filesystem   blocks   soft   hard   inodes   soft   hard
   /dev/sda      44043  50000  55000    37418      0      0

   • The first column is the name of the file system that has a quota enabled for it.
   • The second column shows how many blocks the user is currently using.
   • The next two columns are used to set soft and hard block limits for the user on the file system.
   • The inodes column shows how many inodes the user is currently using.

   • The last two columns are used to set the soft and hard inode limits for the user on the file system.

     • The hard block limit is the absolute maximum amount of disk space that a user or group can use. Once this limit is reached, no further disk space can be used.
     • The soft block limit defines the maximum amount of disk space that can be used. However, unlike the hard limit, the soft limit can be exceeded for a certain amount of time. That time is known as the grace period. The grace period can be expressed in seconds, minutes, hours, days, weeks, or months.

Procedure

1. Set a group quota:

   # edquota -g groupname

   For example, to set a group quota for the devel group:

   # edquota -g devel

   This command displays the existing quota for the group in the text editor:

   Disk quotas for group devel (gid 505):
   Filesystem   blocks  soft  hard  inodes  soft  hard
   /dev/sda     440400     0     0   37418     0     0

2. Modify the limits and save the file.

Procedure

1. Add the project-controlled directories to /etc/projects. For example, the following adds the /var/log path with a unique ID of 11 to /etc/projects. Your project ID can be any numerical value mapped to your project.

   # echo 11:/var/log >> /etc/projects

2. Add project names to /etc/projid to map project IDs to project names. For example, the following associates a project called Logs with the project ID of 11 as defined in the previous step.

   # echo Logs:11 >> /etc/projid

3. Set the desired limits:

   # edquota -P 11

   Note

   You can choose the project either by its project ID (11 in this case), or by its name (Logs in this case).

4. Using quotaon, enable quota enforcement:

   See Enabling quota enforcement.

Procedure

1. Run the repquota command:

   # repquota

   For example, the command repquota /dev/sda produces this output:

   *** Report for user quotas on device /dev/sda
   Block grace time: 7days; Inode grace time: 7days
   			Block limits			File limits
   User		used	soft	hard	grace	used	soft	hard	grace
   ----------------------------------------------------------------------
   root      --      36       0       0              4     0     0
   kristin   --     540       0       0            125     0     0
   testuser  --  440400  500000  550000          37418     0     0

2. View the disk usage report for all quota-enabled file systems:

   # repquota -augP

Procedure

1. Install packages that provide the Stratis service and command-line utilities:

   # yum install stratisd stratis-cli

2. Verify that the stratisd service is enabled:

   # systemctl enable --now stratisd

Procedure

1. Erase any file system, partition table, or RAID signatures that exist on each block device that you want to use in the Stratis pool:

   # wipefs --all block-device

   where block-device is the path to the block device; for example, /dev/sdb.

2. Create the new unencrypted Stratis pool on the selected block device:

   # stratis pool create my-pool block-device

   where block-device is the path to an empty or wiped block device.

   Note

   Specify multiple block devices on a single line:

   # stratis pool create my-pool block-device-1 block-device-2

3. Verify that the new Stratis pool was created:

   # stratis pool list

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button.

4. From the drop-down menu, select Create Stratis pool.

   

5. In the Create Stratis pool dialog box, enter a name for the Stratis pool.

   

6. Select the Block devices from which you want to create the Stratis pool.
7. Optional: If you want to specify the maximum size for each file system that is created in pool, select Manage filesystem sizes.
8. Click Create.

Procedure

1. Erase any file system, partition table, or RAID signatures that exist on each block device that you want to use in the Stratis pool:

   # wipefs --all block-device

   where block-device is the path to the block device; for example, /dev/sdb.

2. If you have not created a key set already, run the following command and follow the prompts to create a key set to use for the encryption.

   # stratis key set --capture-key key-description

   where key-description is a reference to the key that gets created in the kernel keyring.

3. Create the encrypted Stratis pool and specify the key description to use for the encryption. You can also specify the key path using the --keyfile-path option instead of using the key-description option.

   # stratis pool create --key-desc key-description my-pool block-device

   where

   key-description

   References the key that exists in the kernel keyring, which you created in the previous step.

   my-pool

   Specifies the name of the new Stratis pool.

   block-device

   Specifies the path to an empty or wiped block device.

   Note

   Specify multiple block devices on a single line:

   # stratis pool create --key-desc key-description my-pool block-device-1 block-device-2

4. Verify that the new Stratis pool was created:

   # stratis pool list

Procedure

1. Log in to the RHEL 8 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button.
4. From the drop-down menu, select Create Stratis pool.

5. In the Create Stratis pool dialog box, enter a name for the Stratis pool.

   

6. Select the Block devices from which you want to create the Stratis pool.

7. Select the type of encryption, you can use a passphrase, a Tang keyserver, or both:

   • Passphrase:

     1. Enter a passphrase.
     2. Confirm the passphrase

   • Tang keyserver:

     1. Enter the keyserver address. For more information, see Deploying a Tang server with SELinux in enforcing mode.
8. Optional: If you want to specify the maximum size for each file system that is created in pool, select Manage filesystem sizes.
9. Click Create.

Procedure

1. Log in to the RHEL 8 web console.
2. Click Storage.
3. In the Storage table, click the Stratis pool you want to rename.

4. On the Stratis pool page, click edit next to the Name field.

   

5. In the Rename Stratis pool dialog box, enter a new name.
6. Click Rename.

1. Create a pool from one or more block devices:

   # stratis pool create pool-name /dev/sdb

2. Set overprovisioning mode in the existing pool:

   # stratis pool overprovision pool-name <yes|no>

   • If set to "yes", you enable overprovisioning to the pool. This means that the sum of the logical sizes of the Stratis filesystems, supported by the pool, can exceed the amount of available data space.

Verification

1. Run the following to view the full list of Stratis pools:

   # stratis pool list
   
   Name          Total Physical                    Properties     UUID                                   Alerts
   pool-name     1.42 TiB / 23.96 MiB / 1.42 TiB   ~Ca,~Cr,~Op    cb7cb4d8-9322-4ac4-a6fd-eb7ae9e1e540

2. Check if there is an indication of the pool overprovisioning mode flag in the stratis pool list output. The " ~ " is a math symbol for "NOT", so ~Op means no-overprovisioning.

3. Optional: Run the following to check overprovisioning on a specific pool:

   # stratis pool overprovision pool-name yes
   
   # stratis pool list
   
   Name          Total Physical                    Properties     UUID                                   Alerts
   pool-name     1.42 TiB / 23.96 MiB / 1.42 TiB   ~Ca,~Cr,~Op    cb7cb4d8-9322-4ac4-a6fd-eb7ae9e1e540

Procedure

1. Re-create the key set using the same key description that was used previously:

   # stratis key set --capture-key key-description

   where key-description references the key that exists in the kernel keyring, which was generated when you created the encrypted Stratis pool.

2. Verify that the Stratis pool is visible:

   # stratis pool list