The course is part of this learning path
This course - Linux partitions and filesystems - concludes the first half of our Linux certification series and, not coincidentally, covers the last topics you'll need to know for the LPIC-1 101 exam. The final six courses will get you up to speed on the 102 exam.
Besides getting to know the Linux Filesystem Hierarchy Standard, we'll learn how to:
- Create and maintain secure and reliable partitions and filesystems
- Mount and unmount filesystems
- Limit access to only authorized users.
- Create and manage hard and symbolic linked files.
- Control the disk space allocation.
The previous course covered the Linux command line.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Many years ago when I was just getting started with Linux, one of the things that really gave me headaches was figuring out how to find and access attached peripheral devices. I would plug in a USB device or, if I remember correctly, throw a CD-ROM into the drive, and sit waiting for something, anything to show up on my desktop. I now know that my problem was that I simply didn't understand how to properly mount a device. Thanks to Linux's well-managed libraries of kernel modules and a far more responsive user interface, that automatically mounts and displays a staggering range of devices, casual Linux users will seldom have trouble with this anymore. But because system administration often involves working with unusual combinations of hardware and software or pushing the envelope with very new devices, a Linux admin definitely does still need to understand mounting and unmounting. So let's dive in.
Identifying and mounting partitions in Linux
You should remember that we briefly discussed mounting devices in the first video, in the installation and packaged management course. Now we'll start at the beginning. Even if a hardware device is attached to a computer, even if the system has already loaded working drivers, it won't become available to software packages unless it's somehow part of the file system. That means it's got to have an address where software can reliably find it. That address is called a mount point. You can create your own mount points pretty much anywhere you like, but by convention, they're usually located in either the /mnt, spelled MNT, or \media directories.
Let's create a new directory and mount that will serve as a new mount point. We'll CD into it to confirm that it's empty, and CD back to mount again. Now, since even Linux can't read my mind to figure out what I want, although I'm half convinced that Google can, we'll have to tell the system what we'd like to use this mount point for. I've got a USB drive that's designated as /dev/sdc, with a partition on sdc1. If you're not sure of your drive designation, you can often find it from among the attached block devices displayed by lsblock.
Even though sdc1 is already mounted to a different location, we'll mount it to our USB drive directory as well. Now we'll cd into the USB drive, and it's now filled with files, the files from my USB drive.
So that obviously worked. We now know how to locate a device, create a mount point, then mount the device to the mount point.
Now, how do you unmount the device? When you no longer the need the mount, or if you'd like to be sure that you can remove the drive without damaging any files that may be in use, you can easily unmount it using umount, that's UMount, not unmount. cd-ing back into sdc shows us that there's now nothing there.
Sometimes if the mount program can't identify it on its own, you'll need to specify which file system type the drive is using. You do that by adding a value for the -t argument like this. If you're not sure which file system type to specify, you can try using -A, which will try all the types currently mentioned in the fstab file. And speaking of the fstab file, we can't go away without talking at least a little bit about what that's all about. The fstab file, found in the /etc directory, is read by the system while it's booting up, and again, if the Mount -a command is run. The file contains a list of all the file systems that should be mounted automatically. You might think that it does nothing more than what we did when we mounted our USB drive, but there is one big difference. The USB mount we created earlier will disappear when we shut the computer down. The entries in fstab, on the other hand, will come back to life each time the computer is booted.
If you wanted our USB drive, or an extra hard drive for example, to mount to with every boot, we'd have to add an entry for it to the fstab. Let's take a look at my fstab to see what an entry should contain. Lines starting with a hash character are not read by the system, but contain clarifying comments. By default, comment lines above an entry will tell you a device's /dev designation. The items beginning with UUID are a device's identifying name. The next field contains the device's mount point. This first entry has a simple slash, which represents my computer's root directory. The second entry's mount point is boot/efi, telling me that this is the boot partition. The only other field we'll worry about now is the file system type. My root partition is formatted as ext4, while my boot partition is formatted as VFAT.
How does this work on the Amazon cloud? It is certainly true that much of cloud computing is virtual, meaning that a virtual machine often isn't really a standalone computer on a rack somewhere, and a disk volume often isn't really a full physical disk. They're more likely to be virtual slices, carved out of much larger devices. Nevertheless, while working on AWS, you will often have to attach EBS, elastic block store disk volumes, which for all intents and purposes, appear like physical disks, to instances. And that will require mounting.
Device mounting on a Linux based AWS instance works pretty much the same way it would work in any Linux machine, with a caveat that as AWS itself notes during the process, the device naming scheme can sometimes be a bit different. As long as you keep your eyes open for those changes, you'll be fine.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.