Chapter #9: File System Formats, and Installing & Mounting Network Shares

In the last chapter, we started explaining how to set up and configure local system storage using parted and ssm. We also discussed how to create and mount encrypted volumes with a password during system boot.

In addition, we warned you to avoid performing critical storage management operations on mounted filesystems. With that in mind, we will now review the most used file system formats in Red Hat Enterprise Linux and then proceed to cover the topics of mounting, using, and unmounting - both manually and automatically - network filesystems (CIFS and NFS), along with the implementation of access control lists for your system.

First, let’s discuss File system formats and learn about access control lists for your system.

File System Formats

XFS has been introduced as the default file system for all architectures due to its high performance and scalability. It currently supports a maximum filesystem size of 500 TB as per the latest tests performed by Red Hat and its partners for mainstream hardware.

Also, XFS enables user_xattr (extended user attributes) and acl (POSIX access control lists) as default mount options, unlike ext3 or ext4 (ext2 is considered deprecated as of RHEL), which means that you don’t need to specify those options explicitly either on the command line or in /etc/fstab when mounting an XFS filesystem (if you want to disable such options in this last case, you have to explicitly use no_acl and no_user_xattr).

Keep in mind that the extended user attributes can be assigned to files and directories for storing arbitrary additional information, such as the mime type, character set, or encoding of a file, whereas the access permissions for user attributes are defined by the regular file permission bits.

mkfs.xfs /dev/sdX1

Access Control Lists

As every system administrator, either beginner or expert, is well acquainted with regular access permissions on files and directories, which specify certain privileges (read, write, and execute) for the owner, the group, and “the world” (all others), feel free to refer to Chapter 4 if you need to refresh your memory a little bit.

However, since the standard ugo/rwx set does not allow configuring different permissions for different users. ACLs (Access Control Lists) were introduced to define more detailed access rights for files and directories than those specified by regular permissions.

In fact, ACL-defined permissions are a superset of the permissions specified by the file permission bits. Let’s see how all of this translates into real-world usage.

There are two types of ACLs:

• Access ACLs, which can be applied to a specific file or directory.
• Default ACLs, which can only be applied to a directory. If files contained within do not have an ACL set, they inherit the default ACL of their parent directory.

To begin, ACLs can be configured:

• Per user
• Per group
• Or for a user who is not in the owning group of the file.

ACLs are set (and removed) using the setfacl command, with either the -m (modify) or -x (remove) options, respectively.

For example, let us create a group named tecmint and add users johndoe and davenull to it:

groupadd tecmint
useradd johndoe
useradd davenull
usermod -a -G tecmint johndoe
usermod -a -G tecmint davenull

And let’s verify (see Fig. 1) that both users belong to the supplementary group tecmint:

id johndoe
id davenull

Let’s now create a directory called playground within /mnt, and a file named testfile.txt inside. We will set the group owner to tecmint and change its default ugo/rwx permissions to 770 (read, write, and execute permissions granted to both the owner and the group owner of the file):

mkdir /mnt/playground
touch /mnt/playground/testfile.txt
chown :tecmint /mnt/playground/testfile.txt
chmod 770 /mnt/playground/testfile.txt

Then switch user to johndoe and davenull, in that order, and write to the file:

echo "My name is John Doe" > /mnt/playground/testfile.txt
echo "My name is Dave Null" >> /mnt/playground/testfile.txt

So far, so good. Now let's have user ravisaive write to the file, and the write operation will fail, which was to be expected.

But what if we actually need user ravisaive (who is not a member of the group tecmint) to have write permissions on /mnt/playground/testfile.txt? The first thing that may come to your mind is adding that user account to the group tecmint.

But that will give him write permissions on ALL files where the write bit is set for the group, and we don't want that (see Fig. 2). We only want him to be able to write to /mnt/playground/testfile.txt.

su ravisaive
echo "My name is Ravi Saive" >> /mnt/playground/testfile.txt