Now,
let's explore how to mount file systems both
manually but also automatically at boot time.
In a previous lesson, we explored how to create file systems.
But you might have noticed there's still no way for us to access those file systems.
How do we create files and directories on them?
Well, to make a file system accessible, we first must mount it.
Mounting.
Basically means attaching or plugging in a file system to one of our directories
and here's how it works.
First,
we can take a look at a directory often
used for temporarily mounting a random file system.
Now this is currently empty.
But let's say we want to mount the XFS
file system created in one of our previous lessons.
This is stored on the partition at slash dev slash B db one
to mount it. We use this command
now with the file system mounted at
M and T, we can now easily create a file on it.
And we can see that our previously empty file system now has one file inside.
And we can use the LSBLK method to confirm that our
file system is indeed mounted to unmount a file system.
We use the U
mount command.
Now, we'd expect it to be unmount with an N but it is U
mount without the N letter
to
unmount. We specify the directory where our file system is mounted.
Now, LSBLK confirms that this is unmounted
and we can see that slash M and T is
once again an empty directory with no contents inside.
We noticed that in the lsblk command
that some file systems on some partitions are already mounted,
for instance slash D
slash BD A two is mounted in the boot directory.
When a Linux operating system boots up, it automatically mounts some file systems.
It does this according to instructions in a file.
Let's see how we can make it mount our
XFS file system at slash DEV slash VDB one.
Now, first, we'll create a directory that we intend to use as our mounting point.
Etsy F stab is the file where we can define
what should be mounted automatically when the system boots up,
let's edit it
now, align and FS tab has six fields.
Let's take a look at what each one represents.
The first.
Usually points to the block device file that
represents a partition or some kind of storage space
in the line. We will add, this will be the block device file slash DEV slash V db.
One representing the first partition of our second virtual disk
to be specific by writing slash DEV slash B db.
One in our first field, we're telling Linux mount the file system contained
at the partition at slash DEV slash B db one.
The second field specifies the mount point
in our case,
this will be the directory where we want to mount our file system to slash backups.
In the third field, we specify the file system type.
This is XFS in our case.
But if we'd want to automount slash DEV slash B
db two instead of slash DEV slash B db one,
we'd type ext four.
Since we have an ext four file system on the other partition,
the fourth field will contain the mount options.
We'll type defaults here to use default mounting options.
But we'll take a brief look at custom mount options in one of our next lessons.
The fifth field determines if a utility called dump should back up this file system.
Zero means backup disabled. One means backup enabled
dump is rarely used these days. So we can just set this to zero.
File systems can sometimes get corrupted.
And the last field decides what happens when errors are detected.
We can have three values here 01 or two
zero means the file system should never be scanned for errors.
One means this file system should be scanned first for errors before the other ones.
Two means this file system should be scanned after the
ones with a value of one have been scanned.
In practice,
we should often write one here for the root file system where the operating
system is installed and we should write two for all the other operating systems.
Now,
if we would have wanted to mount our
other file systems stored on the second partition,
we would have used a line like this,
but we won't use this here since it would interfere with
our previous line that also automounts in the my backups directory.
Let's save this file.
If we edit F stab and don't intend to reboot the system system D the daemon that
takes care of important things in the operating system
won't know about our changes with this command.
We can force it to pick up any changes
we made to important configuration files including F stab.
If we reboot, it will pick up these changes automatically.
Now, if we look at this directory, LS my backups, we'll see it's empty as expected.
Also, lsblk will show that nothing is mounted in my backups. But if we reboot
and then SSH back in
and enter this command,
we'll see the file we created on our XFS file system at the beginning of this lesson.
Also,
LSBLK will confirm that everything worked as expected.
Our file system was automatically mounted to the my backups directory.
When our operating system booted up,
we can usually figure out what we need to write
in Etsy FSTAB just by looking at existing entries.
But if you ever forget what each field represents, remember the man
FSTAB command can be very helpful.
In a previous lesson, we created a swap partition at slash DEV slash B db three.
It would be useful if this would be mounted automatically at boot time.
So let's edit FSTAB again.
And we'll add this line.
We see that this line is similar to the line we created for our XFS file system.
There are only two notable differences in the 2nd and 3rd field.
The second field should normally contain the mount point,
the directory in a file system, it should be mounted in
but we specify none here. Since swap is not meant to be mounted in any directory.
In the third field, the file system type,
we specify this as swap.
And finally,
we use 00 in the last two fields because swap is
not meant to be backed up or scanned for errors.
If we reboot and then use this command,
we would see that our swap partition was automatically mounted at boot time
in the Etsy F stab file. We can also notice lines like these,
note the comment above the slash DEV slash disc line.
These lines can be equivalent to something like slash DEV
slash VD A two mounted in the boot directory.
So the lines above could have also been written this way.
So why was a UUID a universally unique identifier used instead
of a block device like slash DEV slash VD A two?
Imagine a real server with two S sds connected to some S
ata ports on the motherboard.
The first SSD could be found at slash DEV slash SD. A
second SSD at slash DEV slash SS db.
But if we remove the static cables and
connect them in reverse order on the motherboard,
the first SSD could be found at slash DEV slash S db
instead of slash DEV slash SD A the next time we boot.
So Linux assigns these slash DEV slash VD A or slash DEV slash
V db device names in order that they're connected to the motherboard,
mounting the wrong thing in the wrong place because the
device name is changed can lead to bad results.
Therefore, UUID S can be used. Instead,
these remain the same.
Even if we connect our storage devices in a different order on the motherboard
to check the UUD of a block device, we can use this command.
Also, if we want to use a device name in the form of slash DEV slash disk by UUD,
we can just explore the directory with an LS dash L command
and we'd see the unique identifiers and what block devices they actually point to
next.
We could pick up what we need from here and use the slash DEV slash disk by UUD format,
followed by the unique identifier in the first field of one of our F stab lines.