fstab, the File Systems Table

Although adding a new hard drive to a Linux computer isn’t too complicated, it can be a little confusing the first time you try. You connect up the hardware, power on the computer, and log in to the operating system. But you cannot see your new drive anywhere. Why doesn’t it show up? How do you get Linux to “see” the drive so you can start to configure it?

Actually, Linux has seen your hardware, but it doesn’t readily announce it. Or even give you a hint that it has found your new hardware. You have to interrogate Linux to obtain the information you’re going to need to put into your fstab file.

Here’s how to set up your new hard drive so that Linux—and you—can see it and use it. There are two parts to the process. The first part is doing some reconnaissance to identify the hard drive and to gather some information on it. The second part is editing the fstab file, using the information we’ve gathered in the reconnaissance phase.

Finding Your New Drive

We’re adding two new drives to this system. One is a 32 GB mechanical hard drive (HD), and the other is a 16 GB solid-state drive (SSD).

We need to know that Linux can see them, and what block devices Linux is using for them. In Linux and Unix-like operating systems, a block device is a special file that acts as an interface to a device that data can be read from and written to (unless it is read-only). Block devices often represent a mass-storage unit of some kind (for example, a partition on a hard disk or a CD-ROM. They are created in the /dev directory.

We can use the lsblk command to list the block devices connected to your Linux computer.

The output from lsblk is in columns.

The columns are:

Name: This is the device name. Devices names that start “sd” and are followed by a letter represent SCSI hard disks. The letter identifies individual hard disks, with “a” being the first, “b”. being the second and so on. If there is a number appended, it indicates a partition. For example, “sdb2” would be partition 2 on the second SCSI hard drive. Maj:Min: This column holds the major and minor numbers of the device. The major number indicates the type of the device (or, more precisely, the type of driver used to talk to that device). The minor number is a count of the number of devices of that type. Rm: This column shows whether the device is removable or not. Note that device sr0 has a value of 1, indicating it is removable. This is a CD-ROM drive. Size: This is the amount of data that can be stored in the device. Ro: This column will show 1 for read-only devices and 0 for read-write devices. The loop devices are all read-only. Type: This identifies the type of device. The “disk” entry means a disk drive, the “part” entry stands for partition, and “rom” means Read-Only Memory (CD-ROM). Mountpoint: This shows the point in the file system at which this device is mounted. If this is blank, the device is not mounted.

In the screenshot above, you can see that the loop devices are all given a major number of 7 (meaning a loopback, or loop, device), and the minor numbers simply increment by 1 each time. loop devices are used with the squashfs file system. A squashfs file system is created each time an application is installed using the snappy package management system.

The SCSI hard drives are given names like sda, sdb, and sdc, and all have a major number of 8 (SCSI hard drive). The minor numbers are grouped in 16’s. The minor numbers for the first drive, sda , run from 0 to 15. The 0 represents the physical drive, and the minor number of 1 represents the first partition on that drive. For the second drive, sdb , the minor numbers run from 16 to 31. 16 represents the physical drive, and 17 represents the first partition on that drive. The next 16 numbers, 32 to 47, are used for the minor numbers of sdc , and so on.

Other common major numbers are 3 (for a IDE hard drive) and 11 for CD-ROMS.

Actually, the /dev/sr0 style for SDCSI CD-ROM drives is deprecated. The approved format is /dev/scd0. Despite that, the /dev/sr0 format was still in use on all of the machines used to research this article.

The kernel documentation contains a long listing of all values that the major and minor numbers can take. It’s a surprisingly long list.

To de-clutter the output from lsblk we can use grep to select only the items of interest to us. We know we’ve not added a loop device, so let’s select all of the SCSI hard drives. we know these will have “sd” in their names.

This command will cause grep to print only lines that have “sd” in the. On our test machine, we see:

So, we have three SCSI drives. The first one, /dev/sda , is mounted at the root of the file system, /. The other two are not mounted at all, which is to be expected for brand new drives. We can see that drive /dev/sdb is 32 GB in size, which means it is our traditional mechanical drive. Drive /dev/sdc is 16 GB in size, and this is our SSD drive.

Actually, as this is a virtual computer, these are also virtual disks. So the SSD is showing up just like a SCSI mechanical drive. On my regular desktop my NVMe SSD shows up as /dev/nvme0n1, and the first partition on it is /dev/nvme0n1p1. Its major number is 259. Those differences don’t change what we’ve got to do in the fstab file, but be aware if you have an SSD, it isn’t going to show up as a physical drive.

Also, your drives probably won’t have a partition on them if they are brand new. You can use fdisk to create a partition if required.

RELATED: How to Use Fdisk to Manage Partitions on Linux

Identifying Rotating and Non-rotating Drives

If we use the -o (output) option with lsblk and add the ROTA (rotating) column to the display, lsblk will use a 1 to indicate a rotating storage device (mechanical drive) and a 0 to indicate a non-rotating storage device (solid-state drive).

We get an extra column on the right of the display, which is the ROTA (rotating) column. As you can see, the “SSD” has a 0 for the device and partition. That makes sense because an SSD is a non-rotating storage device.

Mounting The File Systems

Before we start thinking about the fstab file, let’s check that we can mount the drives by hand. This way, if something doesn’t work when we use the fstab file, we’ll know the problem must be our syntax and not a problem with the drive itself.

We’ll create some temporary mount points in the /mnt directory. You’ll need to use sudo , and you’ll be prompted for your password.

Now let’s mount the SCSI drive on the new mount point. We’ll use the mount command in its simplest form. We’ll tell it the name of the partition we want to mount, and the mount point we want it mounted on. mount will mount the file system on that partition at the mount point we specify.

We’re specifying the partition that holds the file system, not the drive, so be sure to include the digit for the partition, in this case, “1”.

If all goes well, there’ll be no response from mount. You’re silently returned to the command prompt.

Mounting the SSD is just as simple. We tell mount which partition on which device to mount, and the mount point to mount it on.

Again, silence is golden.

RELATED: How to Mount and Unmount Storage Devices from the Linux Terminal

Checking the Mounts

To verify that the mounts have taken place, we’ll use lsblk again. We’ll pipe its output through grep and select the “sda1”, “sdb2”, and “sdc1” entries.

mount shows us the three mounted partitions. That’s the two we’ve just mounted and the original partition mounted on /.

The partition /dev/sdb1 is mounted on /mnt/scsi, and is on a rotating storage device. The partition /dev/sdc1 is mounted on /mnt/ssd and is on a non-rotating storage device. All seems well.

Now we need to configure the fstab file so that these devices are mounted each time the computer is started up.

The fstab File

The fstab file contains an entry for each file system that is mounted when your computer is restarted. Each entry is made up of six fields. The fields are:

File system: Not, as its name would suggest, the type of file system on the partition (that’s what the type field is for). This is the identifier for the partition that should be mounted. Mount point: The location in the filesystem at which you wish to have the partition mounted. Type: The type of file system on the partition. Options: Each file system can have options specified to turn on or off functionality. Dump: A reference to an all-but obsolete means of backing up file systems, where the entire file system was “dumped” to tape. Pass: This is the “passing” flag. It tells Linux which partitions should be checked for errors using fsck , and in which order. Your main boot and operating system partition should be 1, and the rest can be set to 2. If the flag is set to zero, it means “don’t check at all. ” If your file system isn’t a journaling file system (such as ext2 or FAT16/32, for example), it is best to turn this off by setting it to 0.

These fields must be specified in this order, and they must have a space or a tab between them. Finding the values for these fields can be daunting, particularly the values for the “options” field. The “options” field options must be in a comma-separated list with no spaces between them.

The man page for each file system will list the options that can be used. ext4 has about 40 options.  Here are some of the more common options:

Auto: The file system will be mounted at boot time, automatically. Noauto: The file system is only mounted when you enter the mount -a command. Exec: The execution of binaries is allowed on this file system. Noexec: The execution of binaries is not allowed on this file system. Ro: The file system should be mounted as read-only. Rw: The file system should be mounted as read-write. Sync: File writes should be conducted immediately and not buffered. Best reserved for floppy disks, if anyone is still using them. Incurs a performance penalty. Async: File writes should be buffered and optimized. User: Any user is allowed to mount the file system. Nouser: The root user is the only user who can mount this file system. Defaults: This is a shorthand way of specifying a set of common settings: rw, suid, dev, exec, auto, nouser, and async). Suid: Allows the operation of the suid and sgid bits. The suid bit is used to allow a file to be executed as root, by a normal user, without giving the user full root privileges. When the sgid bit is set on a directory, files and directories created within that directory have their group ownership set to that of the directory, not to the group of the user who created them. Nosuid: Do not permit the use of the suid and sgid bits. Noatime: – Do not update the file access times on the file system. This can help performance on old hardware. Nodiratime: Do not update the directory access times on the file system. Relatime: Update file access times relative to the file modified time.

The “defaults” option is a good opening gambit. You can add or remove further options if some fine-tuning is required. If only there was a neat way to get the settings you need, in the order you need to enter them into the fstab file.

Enter the mtab file.

The mtab File

The mtab file is the list of currently mounted file systems. This is in contrast to the fstab file which lists the file systems that should be mounted at boot time. The mtab file includes manually mounted file systems. We’ve already mounted our new drives, so they should show up in the mtab file.

We can see the contents of the mtab file using cat. We’ll restrict the output by piping it through grep and looking at /dev/sdb1 and /dev/sdc1 only.

The output shows the mtab entries for these two partitions.

We could lift those values and drop them straight into the fstab file, making sure there was a space or a tab between each field. And that would be that. The drives would be mounted when we rebooted.

There are two caveats to that. One is the mount point. We created temporary mount points just to prove we could mount the new partitions on the new drives. We’d need to enter the real mount points instead of our temporary ones—if they were different.

The second caveat is, if we use the settings from the mtab file, we’ll be using the block device file as the identifier for each partition. That would work, but the values /dev/sda and /dev/sdb and so on are at risk of changing if new mass storage hardware is added to the computer. That would mean the settings in the fstab file would be incorrect.

Each partition has a Universally Unique Identifier (UUID), which we can use to identify the partition. This will never change. If we use the UUID to identify the partitions in the fstab file, the settings will always remain accurate and true.

If you are using your new partitions as part of a Redundant Array of Inexpensive Disks (RAID) system, check with the documentation for that system. It might specify that you must use the block device identifier instead of the UUID.

Finding a Partition’s UUID

To find the UUID of a partition, we can use blkid to print the attributes of the block devices. We’ll limit the output to our two new partitions on our new drives:

The output includes the UUID for each partition.

The PARTUUID is a form of UUID that can be used with the GUID Partition Tables (GPT) partitioning method (if you’re not using the Master Boot Record (MBR) partitioning method).

Editing the fstab File

Open the fstab file in an editor. We’re using gedit, an easy to use editor found in most Linux distributions.

The editor appears with your fstab file loaded in it.

This fstab file has two entries already in it. They are the partition on the existing hard drive /dev/sda1, and the swap file system. Be careful not to alter these entries.

We need to add two new entries to the fstab file. One for the partition on the SCSI drive and one for the partition on the SSD drive. We’ll add the SCSI partition first. Note that lines that start with a hash # are comments.

In the “file system” field, we’ll use the UUID that blkid retrieved for us earlier. Start the line with “UUID=” and then paste the UUID. Press space or tab. For the “mount point” field, we’re going to use the mount point we created earlier, /mnt/scsi. You’d use the appropriate mount point from your system. Press space or tab. For “type” we’re going to enter ext4 , which is the type of file system on our partition. Press space or tab. In the “options” field we’ll use the options that we retrieved using cat /etc/mtab. These are “rw,relatime”. Press space or tab. The “dump” field is set to zero. Press space or tab. The “pass” field is set to zero.

Now we’ll add the fstab entry partition on the SSD drive on a separate line.

In the “file system” field, we’ll enter the UUID that blkid retrieved for the partition on the SSD drive. Start the line with “UUID=” and then paste the UUID. Press space or tab. For the “mount point” field, we’re going to use the mount point we created earlier, /mnt/ssd. Press space or tab. For “type” we’re going to enter ext4 , which is the type of file system on our partition. Press space or tab. In the “options” field—just to make the two new entries different in our example—we’ll use the “defaults” option. Press space or tab. The “dump” field is set to zero. Press space or tab. The “pass” field is set to zero.

Save the file and close the editor.

RELATED: How to Edit Text Files Graphically on Linux With gedit

Testing fstab Without Rebooting

We can unmount our new drives and then force a refresh on the fstab file. The successful mounting of our new partitions will verify that the settings and parameters we’ve entered are syntactically correct. That means our fstab file should be processed correctly during a reboot or power-up sequence.

To unmount the SCSI drive, use this command. Note that there is only one “n” in “umount”:

To unmount the SSD drive, use this command:

Now we’ll use lsblk to check whether these block devices are mounted.

And we see that the block devices are present in the computer, but not mounted anywhere.

We can use the mount command with the -a (all) option to remount all the file systems in  fstab.

And we can check once more with lsblk to see if our new partitions are now mounted:

Everything is mounted where it should be.  All we have to do now is change the ownership of the mount points, otherwise root will be the only one who can access the new storage devices.

We can do this easily using chown . This is the command for the SCSI mount point:

And this is the command for the SSD mount point:

We can now reboot our computer with confidence, knowing that the partitions we’ve added will be mounted for us, and we have access to them.

Not That Scary After All

All the hard work is in the reconnaissance phase—and that wasn’t hard either. Editing the fstab file once you’ve gathered the information you need is a breeze. Preparation is everything.