On Linux and Unix based systems everything is made up of files and folders. To visualize this you can think of it as a directory tree where the further go down the tree the more things branch out. This file hierarchy starts at / which is also refereed to as the root directory and spreads out from there. This means that disks and filesystems are mounted to sub-directories somewhere on this tree.
The Mount command is used to mount filesystems located locally and remotely to a location within this tree so it can be used for storage.
Be aware that mounting a file system is an administrator task so there are points that will require the ability to login as the root user or sudo privileges. If you are unable to directly login as root try using sudo -i before any file system mounting.
Listing Mounted File Systems
Lets start by look at the currently mounted file systems as it is always good to verify what disks/storage is mounted before attempting to make any changes.
Using the mount command itself we can use the mount command with the -l flag:
mount -l
That said it is likely depending on the OS/Distribution you happen to run the command on, the output may be a bit hard to understand due to extraneous information. If that ends up being the case my recommendation is to use the lsblk command as it list the file systems that are on block devices, in other words physical disks. That would look like the command below:
lsblk
Some other commands besides the two already discussed that can be used to list mounted file systems have been included below:
cat /proc/mounts
findmnt
df -h
Mounting Local File Systems
To mount a file system using the mount command we need to first have an empty folder where we can mount to the given file system in to.
It is generally recommended to keep mount points in /mnt or /media though there are exceptions for example were a user mounts something inside of there home directory.
For this example I will use /mnt/point
To create the mount point the command would be as follows
mkdir /mnt/point
Once this is done we need a way to refer to the block device containing containing the file system and data we want to be able to access. We can again use the output from the lsblk command to determine the device names.
For this example lets say the disk we want to mount is located at /dev/sdb and already has a ext4 file system on the block device.
If the disk isn’t using ext4 but make sure to change what is after -t to specify the correct filesystem type.
mount -t ext4 /dev/sdb /mnt/point
To verify the disk has been mounted you will want to run your choice of command from the section above.
Also be aware that at this point the mount will will not persist across reboots.
When Working With Remote File Systems
The first thing to be aware of when mounting a remote file system is that we need to ensure the software package is installed so the system can communicate over the remote protocol used on the end serving up the storage.
For example when using NFS (network file system) that would be the NFS client package. And the filesystem type is nfs.
Common Mount Flags
-o : Used for specify mount options
-t : Used to specify the file system type
-r : Used to mount as read only
-w : Used to specify read-write which is defaulted to unless otherwise specified
-a : Tells the system to try and mount all the file systems listed in /etc/fstab
Mounting A File System On Boot
To mount a file system at boot we need to add the entry to the /etc/fstab file.
Though before we get started we want the Universally unique identifier (UUID) for the disk as we want to reference this disk in place of the device name /dev/sdb.
To do that we want to use the blkid command followed by the device name.
blkid /dev/sdb
With that we want to copy what is in between the parentheses after UUID=. With that in hand we can get started on creating the fstab configuration entry
Paste the UUID after UUID= and you have a basis fstab entry and if you happen to be using something other than ext4 please make sure to modify that as well.
UUID= /mnt/point ext4 defaults 0 0
For more info on what configuration options you can use in fstab you there is a man page entry for fstab.
Once the necessary changes have been made append to the /etc/fstab configuration file using a text editor.
Now we will want to test to make sure the disk mounts.
If the disk has already been mounted first you will want to umnount it see that section below.
Once the disk has been unmounted it is recommend testing with mount -a or mount /mnt/point if this works you will see the disk mounted automatically.
If the this worked the last test is to do a reboot to make sure that the disk gets mounted.
When Working With Remote File Systems
You will want to use different fstab configuration options as the defaults could cause issues when trying to boot of the system.
For example when using NFS try starting with the following and modify as needed.
//<remote-server>/<remote-share> /mnt/remote nfs defaults,nofail 0 0
How To Unmount A File System
To unmounting a file system you simply run the umount command and append the path to the mount point.
To umnount a disk mounted at /mnt/point for example this is the command
umount /mnt/point
Some other common flags for the umount command you may want/need have been included below.
-f : Force unmounting, even if there are processes using the file system.
-v : Be verbose and print out information about each file system being unmounted.
-t : Specify the file system type.
-l : detach the filesystem now, clean up things later also known as lazy unmount
-h : Print help information.
Additional Information
As with almost anything Linux related there is quite a few ways to accomplish the same thing. That said I recommend using caution if you haven’t tested or know for certain before running commands in production.
In addition to online resources some additional resources that you can be found on a Linux System have been listed below if you need help verifying what a command line command or flag does:
- The commands –help flag
- The man page `man command` or info page `info command`
Embracing a lifelong passion for technology since childhood, CJ delved into the intricate workings of systems, captivated by the desire to understand the unknown. This innate curiosity led to his discovery of Linux, a revelation that resonated deeply. With more than 7 years of on the job experience, he’s honed his technical skills as a Geek and Senior Linux Systems Administrator.
Leave a Reply