The /etc/fstab file is a very critical file on your Linux system. As I mentioned in the last section, you can edit this file to call out additional volumes you would like to automatically mount at boot time. However, the main purpose of this file is to also mount your main filesystem as well, so if you make a mistake while editing it, your server will not boot. Definitely be careful.

When your system boots, it looks at this file to determine where the root filesystem is. In addition, the location of your swap area is also read from this file and mounted at boot time as well. Your system will also read any other mount points listed in this file, one per line, and mounts them. Basically, just about any kind of storage you can think of can be added to this file and automatically mounted. Even network shares from Windows servers can be added here. It won't judge you (unless you make a typo).

For an example, here is the content of /etc/fstab on one of my machines:

When you install Ubuntu Server, the /etc/fstab file is created for you and populated with a line for each of the partitions you created during installation. On the server I used to grab the example fstab content, I have a single partition for the root filesystem, and I'm also mounting a swap file (we'll discuss swap later).

Each volume is designated with a Universally Unique Identifier (UUID) instead of the normal /dev/sdaX naming convention you are more than likely used to. In my output, you can see that some comments (lines beginning with #) were created by the installer to let me know which volume refers to which device. For example, UUID 8d9756d9-c6f5-4efe-9d41-2d5e43c060c2 refers to my root filesystem, and you can also see that I have a swap file located at /swapfile.

The concept of a UUID has been around for a while, but there's nothing stopping you from replacing the UUID with the actual device names (/dev/sda1 and /dev/sda5 in my case). If you were to do that, the server would still boot and you probably wouldn't notice a difference (assuming you didn't make a typo).

Nowadays, UUIDs are preferred over common device names due to the fact that the names of devices can change depending on where you place them physically (which SATA port, USB port, and so on) or how you order them (in the case of virtual disks). Add to this the fact that removable media can be inserted or removed at any time and you have a situation where you don't really know what name each device is going to receive. For example, your external hard drive may be named /dev/sdb1 on your system now, but it may not be the next time you mount it if something else you connect claims the name of /dev/sdb1. This is where the concept of UUIDs comes in handy. A UUID of a device will not change if you reorder your disks (but it will change if you reformat the volume). You can easily list the UUIDs of your volumes with the blkid command:

blkid

The output will show you the UUID of each device attached to your system, and you can use this command any time you add new volumes to your server to list your UUIDs. This is also the first step in adding a new volume to your /etc/fstab file. While I did say that using UUIDs is not required, it's definitely recommended and can save you from trouble later on.

Each line of an fstab entry is broken down into several columns, each separated by spaces or tabs. There isn't a set number of spaces necessary to separate each column; in most cases, spaces are only used to line up each column to make them easier to read. However, at least one space is required.

In the first column of the example fstab file, we have the device identifier, which can be the UUID or label of each device that differentiates it from the others. In the second column, we have the location we want the device to be mounted to. In the case of the root filesystem, this is /, which (as you know) is the beginning of the Linux filesystem. The second entry (for swap) has a mount point of none, which means that a mount point is not necessary for this device. In the third column, we have the filesystem type, the first being ext4, and the second being swap.

In the fourth column, we have a list of options for each mount separated by a comma. In this case, we only have one option for each of the example lines. With the root filesystem, we have an option of errors=remount-ro, which tells the system to remount the filesystem as read-only if an error occurs. Such an issue is rare, but will keep your system running in read-only mode if something goes wrong. The swap partition has a single option of sw. There are many other options that can be used here, so feel free to consult the man pages for a list. We will go over some of these options in this section.

The fifth and sixth columns refer to dump and pass respectively, which are 0 and 0 in the first line. The dump partition is almost always 0 and can be used with a backup utility to determine whether the filesystem should be backed up (0 for no, 1 for yes). In most cases, just leave this at 0 since this is rarely ever used by anything nowadays. The pass field refers to the order in which fsck will check the filesystems. The fsck utility scans hard disks for filesystem errors in the case of a system failure or a scheduled scan. The possible options for pass are 0, 1, or 2. With 0, the partition is never checked with fsck. If set to 1, the partition is checked first. Partitions with a pass of 2 are considered second priority and checked last. As a general rule of thumb, use 1 for your main filesystem and 2 for all others. It's not uncommon for cloud server providers to use 0 for both fields. This may be because if a disk does undergo a routine check, it would take considerably longer to boot up. In a cloud environment, you can't always wait very long to get a server up and running.

Now that we understand all the columns of a typical fstab entry, we can work through adding another volume to the fstab file. First, we need to know the UUID of the volume we would like to add (assuming it's a hard disk or virtual disk). Again, we do that with the blkid command:

blkid

The output of that command will give us the UUID. Copy that down in a text editor. Next, we need to know where we want to mount the volume. Go ahead and create the directory now, or use an existing directory if you wish. For example, you could create the directory /mnt/extra_storage for this purpose:

sudo mkdir /mnt/extra_storage

At this point, we should have all we need in order to add a new entry to fstab. To do so, we'll need to open the file in a text editor and then create a new line after all the others. If you don't have a preferred editor, you can use the nano editor:

sudo nano /etc/fstab

For example, adding an entry for /dev/sdb would look similar to the following:

In my example, I created a comment line with a little note about what the extra volume will be used for. It's always a good idea to leave comments, so other administrators will have a clue regarding the purpose of the extra storage. Then, I created a new line with the UUID of the volume, the mount-point for the volume, the filesystem type, defaults option, and a dump/pass of 0 and 2.

The defaults option I've not mentioned before. By using defaults as your mount option in fstab, your mount will be given several useful options in one shot, without having to list them individually. Among the options included with
defaults are the following, which are worth an explanation:

• rw: Device will be mounted read/write
• exec: Allow files within this volume to be executed as programs
• auto: Automatically mount the device at boot time
• nouser: Only root is able to mount the filesystem
• async: Output to the device should be asynchronous

Depending on your needs, the options included with defaults may or may not be ideal. Instead, you can call the options out individually, separated by commas, choosing only the ones you need. For example, with regards to rw, you may not want users to be allowed to change content. In fact, I strongly recommend that you use ro (read-only) instead, unless your users have a very strong use case for needing to make changes to files. I've actually learned this the hard way, where I've experienced an entire volume getting completely wiped out (and no one admitted to clearing the contents). This volume included some very important company data. From that point on, I mandated ro being used for everything, with a separate rw mount created, with only a select few (very responsible) people having access to it.

The exec option may also not be ideal. For example, if your volume is intended for storing files and backups, you may not want scripts to be run from that location. By using the inverse of exec (noexec), you can prevent scripts from running to create a situation where users are able to store files on the volume but not execute programs that are stored there.

Another option worth explanation is auto. The auto option basically tells your system to automatically mount that volume whenever the system boots or when you enter the following command:

sudo mount -a

When executed, sudo mount -a will mount any entry in your /etc/fstab file that has the auto option set. If you've used defaults as an option for the mount, those will be mounted as well since defaults implies auto. This way, you can mount all filesystems that are supposed to be mounted without rebooting your server (this command is safe to run whenever, as it will not disrupt anything that is already mounted).

The opposite of the auto option is noauto, which can be used instead. As you can probably guess by the name, an entry in fstab with the noauto option will not be automatically mounted and will not be mounted when you run mount -a. Instead, entries with this option will need to be mounted manually.

You may be wondering, then, what the point is of including an entry in fstab just to use noauto. To explain this better, here is an example fstab entry with noauto being used:

UUID=e51bcc9e-45dd-45c7 /mnt/ext_disk  ext4  rw,noauto 0 0

Here, let's say that I have an external disk that I only mount when I'm performing a backup. I wouldn't want this device mounted automatically at boot time (I may not always have it connected to the server), so I use the noauto option. But since I do have an entry for it in /etc/fstab, I can easily mount it any time with the following command:

sudo mount /mnt/ext_disk

Notice that I didn't have to include the device name or options; only where I want the device mounted. The mount command knows what device I'm referring to, since I have an entry in the /etc/fstab file for a device to be mounted at /mnt/ext_disk. This saves me from having to type the device name and options each time I want to mount the device. So, in addition to mounting devices at boot time, the /etc/fstab file also becomes a convenient place to declare devices that may be used on an on-demand basis but aren't always attached.

One final option I would like to cover before we move on is users. When used with a mount in /etc/fstab, this allows regular users (users other than root) to mount and unmount the filesystem. This way, root or sudo will not be necessary at all for a mount used with this option. Use this with care, but it can be useful if you have a device with non-critical data you don't mind your users having full control over when mounting and unmounting.

While the concept of a text file controlling which devices are mounted on the system may seem odd at first, I think you'll appreciate being able to view a single file in order to find out everything that should be mounted and where it should be mounted. As long as administrators add all on-demand devices to this file, it can be a convenient place to get an overview of the filesystems that are in use on the server. As a bonus, you can also use the mount command (with no options) to have the system provide you a list of everything that's mounted. Go ahead and try that, and I'll meet you in the next section.