Linux: Mounting Filesystems

scottalanmiller

Common to all operating systems is the need to mount a filesystem. In Linux this is no different. This is a very common task and should be understood. We will explore the mount and umount manual commands and the /etc/fstab or "filesystem table" configuration file that manages our system mount points.

In the Windows world, standard mount points go to drive letters like the or E: drives. Not so in Linux. All Linux mount points exist within the filesystem hierarchy. So we need a blank folder location in which to mount a new filesystem.

From our previous example, we will assume that we have already formatted the /dev/sdb1 block device with our filesystem and we now want to mount this to our existing system. We will make a new folder at /data to mount this new filesystem to:

mount /dev/sdb1 /data

Now we can check this in a few ways, but the easiest is to use df. Once we have mounted a filesystem, it will be dispayed by the df command. Any time we can also cd into /data and run df . to ask it to tell us the status of the current filesystem which is handy as well.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        20G  3.8G   15G  21% /
/dev/sdb1        42G  0G     42G   0% /data

If we need to remove this mount point, we can do so without rebooting. All we need to do is to use the umount command, like this:

umount /data

If you get an error that /data is in use, check your working location with pwd. If you mount /data and cd into it, it will not allow you to unmount it with umount since you are actively using it. Once you cd to a location on another filesystem it should be clear to unmount.

This process works well for one time mounts or testing but generally we are going to want our filesystems to mount automatically when the system boots up and not require manual intervention. For this we turn to the /etc/fstab file, probably the configuration file most commonly interacted with on Linux.

The /etc/fstab file is not a complex one and most of what we do with it will be pretty simple. Let's start by looking at one and seeing what is there by default in a lot of cases. This file tends to vary a bit from situation to situation, we we will look at several:

Default /etc/fstab from Linux Mint 17.3 based on Ubuntu 14.04.3

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=16eb7ff8-cc1f-4cf2-89ea-b844bf25aafa /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=7587e6e9-0dfe-4a37-b5ff-fcf1bdbb2e23 none            swap    sw              0       0

Default /etc/fstab from CentOS 7 on Digital Ocean

# /etc/fstab
# Created by anaconda on Tue Jul  8 23:01:42 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
LABEL=DOROOT /                       ext4    defaults        1 1
/swapfile1 none swap sw 0 0

Default /etc/fstab from FreePBX 10

# /etc/fstab
# Created by anaconda on Wed May 18 11:58:19 2016
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=866724b6-d718-4ba6-8ca0-de2fa0e8b010 /                       ext4    defaults        1 1
UUID=66aac715-92c8-43b9-b507-77cf609899a8 /boot                   ext4    defaults        1 2
UUID=f44ee77f-7ac2-4277-991e-756c6556ca8e swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

As you can see, a lot can change from one fstab to another. But the basics are the same. The table is based on columns, so we will examine the layout column by column. Note that any line starting with # is just a comment and not part of the configuration.

Filesystem: The first column in fstab is the identifier for the filesystem. This can take a lot of different forms and creates some confusion. The traditional item to put here is a direct reference to the block device such as /dev/sdb1. If LVM is used, the LVM reference would be the block device instead. (The block device would be the device specified by the mkfs command.) In more recent years it has become common to use a label in this field (visible by the syntax Label=) which is what it sounds like, a label or alias to a block device that is more flexible. Labels often describe what the purpose of the filesystem is which is handy for flexibility and standardization in the face of potentially variable underlying block devices. And finally UUID, a universally unique ID field is common and uses the block devices natural UUID as a means of reference. Labels are the most commonly used tool in the RHEL/CentOS world, UUIDs in the Ubuntu world. Labels often make the most sense for servers, UUIDs often the most for desktops.

Mount Point: The next column is the mount point location - the place in the filesystem hierarchy where this filesystem will be joined. This can be a common one like /opt or /var or can be any arbitrary location where you want to have an independent file system such as /data, /opt/application/log or whatever.

Type: This is the type of filesystem that is to be mounted. Most commonly here you will see ext4, ext3, xfs, jfs, ext2 or even ntfs. This has to match the format of the filesystem in question. You may also see types like nfs, but we will address that later, but do not be surprised to see that here as well. Most systems have swap space, which we will talk more about when we discuss system memory, and this will be listed as swap here.

Options: This column contains optional flags that determine how the filesystem will be mounted. Options include rw/ro (read write or read only), exec/noexec (allow binary execution or deny binary execution), auto/noauto (automatically mount at boot time or do not automatically mount at boot time), user/nouser (allow normal users to mount the filesystem or require root to mount filesystem), sync/async (writes are synchronous and safe or writes are asynchronous and risky in case of power loss.) Most commonly this field is filled with the world defaults which is the equivalent of setting: rw, suid, dev, exec, auto, nouser, async. This is not an exhaustive list of options, see the Wikipedia article for more info.

Dump: A specific flag for the dump backup program. As this program is almost never used today, this field is almost always a zero to indicate that dump is not to interact with this filesystem. If the number is greater than a zero, and dump is run, dump will read this value to determine a backup frequency.

Pass: This field, often just left as a zero, tells the fsck utility whether the filesystem should be checked at boot time. A zero means to not check, a number greater than zero determines the order in which the filesystems will be checked.

For more information on the fstab file, Wikipedia has an excellent entry that includes a great example of most common entry types.

Once we have updated our fstab configuration file with the details for mounting our new filesystem we can simply run mount to mount all available filesystems or we can mount a specific one by specifying it with the command. If we have put the details for /data into /etc/fstab then we can mount it by hand like this:

mount /data

Part of a series on Linux Systems Administration by Scott Alan Miller

EddieJennings

I might need the explain-it-to-me-like-I'm-a-five-year-old answer, but let me know if my understanding is correct.

I'm running a Hyper-V VM of CentOS with two VHDs attached. /dev/sdb is the extra drive. I've used it to practice creating a partition, formatting it, and mounting it to /data.

Is this correct? Any data that is stored within the /data file system is physically stored on /dev/sdb. Even though /data is a subdirectory of /. All other data within / is physically stored on the other drive.

EddieJennings

Edited for terminology: Partition is created, then file system is made (formatting), then mounting happens.

scottalanmiller

@EddieJennings said in Linux: Mounting Filesystems:

Is this correct? Any data that is stored within the /data file system is physically stored on /dev/sdb. Even though /data is a subdirectory of /. All other data within / is physically stored on the other drive.

That is correct. In your example, /data is a filesystem existing directly on top of the /dev/sdb physical device (the second VHD file.)

scottalanmiller

@EddieJennings said in Linux: Mounting Filesystems:

Edited for terminology: Partition is created, then file system is made (formatting), then mounting happens.

Correct.

EddieJennings

@scottalanmiller Excellent! For some reason, I was having a hard time wrapping my head around the fact that /data is it's own filesystem within /.

As a test, I tried this. I unmounted /data, and mounted my VHD onto /home (which contains ./eddie/testFile). I figured this would happen: ./eddie/testFile would vanish, because /home is now representing a completely different physical data location.
Turns out that indeed happened. When I unmounted /home, ./eddie/testFile reappeared, which I expected.

Let's say, I'm in a situation where /home to be a mount point for another disk, and the current data within /home need to be moved to the other disk (for whatever reason). Would this be the likely process?

Copy /home to a /tmp or some other holding place.
Partition and format the new disk.
Mount it on /home.
Copy the data from /tmp (keeping the directory structure, so the end result is /home/subdirectories/foo
If you wanted to reclaim space on the original drive (since files were initially copied rather than moved), unmount /home, remove /home (since the resultant /home is the directory from the original drive), create a new /home, remount the second disk to this newly created /home.

scottalanmiller

@EddieJennings said in Linux: Mounting Filesystems:

@scottalanmiller Excellent! For some reason, I was having a hard time wrapping my head around the fact that /data is it's own filesystem within /.

As a test, I tried this. I unmounted /data, and mounted my VHD onto /home (which contains ./eddie/testFile). I figured this would happen: ./eddie/testFile would vanish, because /home is now representing a completely different physical data location.
Turns out that indeed happened. When I unmounted /home, ./eddie/testFile reappeared, which I expected.

Let's say, I'm in a situation where /home to be a mount point for another disk, and the current data within /home need to be moved to the other disk (for whatever reason). Would this be the likely process?

Copy /home to a /tmp or some other holding place.

Partition and format the new disk.

Mount it on /home.

Copy the data from /tmp (keeping the directory structure, so the end result is /home/subdirectories/foo

If you wanted to reclaim space on the original drive (since files were initially copied rather than moved), unmount /home, remove /home (since the resultant /home is the directory from the original drive), create a new /home, remount the second disk to this newly created /home.

So that would work, but far more likely, you would rename /home instead of moving the data. Like this mv /home /home-old, then mount the new device to /home (after you make a new, empty /home directory as you renamed the old one) and copy the files over. That way you only do a copy operation once, not twice.

EddieJennings

@scottalanmiller Ah, yes. That would be a more efficient way of doing it. I was too excited from finally gaining some understanding of mount point concepts, I didn't think though the best way to move the data.