How to Write or Edit /etc/fstab Like a Pro

The /etc/fstab file is one of the most important configuration files in a Linux system. It defines how filesystems, partitions, and storage devices will mount on your system at boot time or when manually mounted. As a Linux system administrator or power user, knowing how to properly edit this file is an essential skill.

In this comprehensive guide, I‘ll walk you through everything you need to know about the fstab file, including:

• What is fstab and why it‘s important
• Anatomy of an fstab entry
• All fstab fields explained
• Common mount options
• When to use UUID vs device labels
• Best practices for editing fstab
• Troubleshooting mount issues
• Tips for automating mounts of remote filesystems
• Advanced usage examples

So if you‘re ready to become an expert at managing mounts in Linux, read on!

What is Fstab and Why It Matters

The /etc/fstab file (for "file systems table") is a plaintext configuration file that tells the Linux system how to treat partitions, drives, network shares and other block devices. It instructs the mount command on how to mount everything automatically at boot time, as well as defining filesystem mount points and options.

Without the fstab file, Linux would have no information about available drives, partitions and file systems at boot up. The system would be unusable until storage devices were manually mounted by the administrator.

So in summary, here‘s why /etc/fstab is so important:

• It auto-mounts partitions, drives and other mountable file systems at boot time
• It defines mount points, modes (read-write, read-only etc) and other options
• It saves administrators from having to manually mount everything themselves
• Critical for system reliability and usage at boot up time

On most Linux distributions, the fstab file is pre-configured with mount information for the OS root partition, swap space and other core file systems. But administrators may need to edit fstab later to add new partitions, network storage volumes etc.

Now let‘s take a look at what makes up an fstab entry…

Anatomy of an Fstab Entry

Here is an example fstab entry for mounting an ext4 file system partition:

UUID=32bc1237 /home ext4 defaults 0 2

As you can see, each fstab entry is defined on a single line, with columns representing different configuration items:

Column	Description
1	UUID or device identifier
2	Mount point
3	File system type
4	Mount options
5	Dump settings
6	File system check order

The columns must appear in that specific order, or errors can occur. Now let‘s take a deeper look at what each column is used for…

Column 1: UUID or Device Identifier

In the first column, you must specify a "device identifier" – either the device‘s UUID or traditional label. This tells Linux exactly which drive, partition or network share to apply the mount settings to.

For example a hard drive partition /dev/sda1, or a CIFS network share using //fileserver/sharename.

You can use an auto-generated UUID for most unique identification (more later), but device labels work too. Just avoid ambiguity.

Column 2: The Mount Point

The second column defines the mount point – an empty directory where the device/file system will be mounted.

For example /home, /mnt/users, /media/disk1 or any unused directory where you want the partition/disk/share to appear in the system.

This mount point directory must exist before fstab will mount to it.

Column 3: File System Type

Next we specify the file system format present on the partition or storage device: ext4, xfs, btrfs, vfat, cifs etc.

Or auto can be used if you want the system to auto-detect what is there.

This is used to determine the correct driver/options for mounting said filesystem.

Column 4: Mount Options

The fourth column contains a comma-separated list of mount options that define additional behaviors for this mount:

• rw = Read/write access
• ro = Read only
• auto = Mounted at boot automatically
• noauto = Must mount manually
• user = Allow ordinary users to mount this

We will cover mount options in more detail soon.

Column 5 and 6: Dump and Check Options

The fifth and sixth columns generally contain integer digits that control:

• Dump settings: Whether and how backups are done by the dump utility
• Check order: In what order filesystem checks should be done at boot time

Most installs have 0 and 2 respectively, but these are reserved for specialized use cases.

And that covers a basic rundown of the six fstab fields and what they do! Now let‘s move on to some working examples…

Common Mount Options Explained

The fourth column in each fstab entry defines mount options that change the behavior of the mount point at boot/runtime.

Here are some commonly used options and what they enable you to do:

defaults – Just use default settings for that file system type. This covers rw, suid, dev, exec, auto, nouser, async.

auto – Mounted automatically at boot up. Use this if you want mounts without intervention.

noauto– File system will NOT mount automatically at bootup. It will require a manual mount command.

exec – Allow binaries/programs on this file system to be executed. Typically enabled by default.

noexec – Block executing binaries on this file system. Often used for mount points like /tmp and non-root volumes for security purposes. Prevents running programs or scripts.

rw – File system mounted with read/write access for all users. This is the typical default for writable mounts.

ro – Read only. The file system is mounted in a read-only state, with no write ability allowed for users. Useful for static data volumes.

user – Allow any local user to mount/unmount this file system as needed. File system can be manipulated by non root users.

users – Same as user – allow any user to mount the file system via mount/umount commands.

uid=, gid= – Force all files on this file system to assume the given Linux user/group ID. Helpful when mounting external devices with different permission schemas.

As you can see, combining certain mount options can customize the exact access rules and security properties for any mounted file system on your Linux server!

Next let‘s look at device identifiers…

To Use UUIDs or Device Labels

In the first column of fstab entries, you need to specify a "device identifier" so the system knows which disk, partition or network share to apply the mount point to.

You have two main choices:

1. Traditional Device Labels

Such as:

• /dev/sda1 for a physical disk partition
• //myserver/share for a Windows CIFS network share

2. UUIDs

A special alphanumeric code uniquely generated for each device and partition. For example:

UUID=32bc1237-087b-4d97-9a29-9c8d148157d1

Using the traditional device name (eg /dev/sda1) can sometimes cause issues when hardware changes occur across reboots. If your physical disk ports move around, a /dev/sda1 device could map to something unpredictable across reboots.

Whereas UUIDs stay fixed to a device forever – ensuring your mount points always apply to the right hardware disk or partition every single time. Even if hardware moves around.

That‘s why most Linux pros recommend using UUIDs in your fstab entries instead of old-school device labels like /dev/sda1.

Finding a Device‘s UUID

Want to find the UUID for one of your existing block devices or partitions? It‘s very easy to locate from the CLI:

Use the lsblk command to list all storage partitions, along with their UUID values:

sudo lsblk -o name,uuid
NAME   UUID                                
sda    32bc1237-087b-4d97-9a29-9c8d148157d1
├─sda1 417c6e60-1237-abdc-15c1-cdef0123b1a1    
├─sda2 213b5d56-e3cb-453b-b2fb-ac123bc45e1b
└─sda3 bc78a9de-c5e0-48da-9421-a123edf6d213

Or if you already know the partition, get just that UUID:

sudo blkid /dev/sda1
/dev/sda1: UUID="417c6e60-1237-abdc-15c1-cdef0123b1a" 

With those handy UUIDs, your mounts will keep working even if you move those physical disks to new ports or a new server entirely!

Now let‘s dive into…

Best Practices When Editing Fstab

Modifying the fstab file is easy enough in theory… Just edit the file and reboot, right?

What could go wrong?

Actually…a lot potentially! Bad fstab entries could make your server unbootable.

That‘s why following these best practices whenever modifying fstab is highly advised:

1. Always Back Up the Current fstab

Before making permanent changes, backup the current working version so you can restore if needed:

sudo cp /etc/fstab /etc/fstab_backup

This gives a safety net if mistakes are made.

2. Spot Test New Entries Before Reboot

When adding new mounts to fstab, manually test those entries FIRST with a simple mount -a command before actually rebooting the server and relying on them to work automatically.

For example, this will mount all entries in fstab that are defined as auto:

sudo mount -a 

By spot testing now, we can catch any potential errors with our new mounts first. Saving headaches later!

3. Use Comments Liberally

Especially for more complex custom fstab files, add comments explaining what mounts are for what purpose, like this:

# Application data partition
UUID=239948 /var/myapp ext4 defaults 0 0

Comments help remind all admins what is mounted where.

4. Test Mount Options in /etc/mtab First

Unsure about how certain mount options actually function? Want to test their impact first?

A handy trick is to manually mount the file system first using your desired options, then look in /etc/mtab to see their real effect:

sudo mount -o rw,users /dev/sda1 /mountpoint
cat /etc/mtab

This lets you validate options before adding them to fstab long term. Saving trial and error reboots!

5. Reboot and Validate After Changes

Finally, once you‘ve made additions or edits to /etc/fstab and spot tested them… conduct a full reboot to engage the new mount behavior automatically.

Then confirm everything mounted as expected:

$ df -h   #list all mounts
$ ls -l /mount1 #check contents as expected 

Skipping validation here means you risk surprise errors down the road with production mounts!

Okay now that we‘ve covered best practices – let‘s tackle some common admin tasks…

Automounting Remote File Systems with CIFS/NFS

A very common task is making networked file shares automatically mount on your servers or PCs via the fstab file.

For example, you may want a NAS storage device with media files to always mount to /media/mynas on boot.

Or have a fileserver‘s user home directories available locally via CIFS or NFS automatically.

Accomplishing these "auto mounts" over the network is very easy with some fstab magic!

Here‘s an overview of how automounting works with CIFS/SMB (Windows shares) and NFS (Linux shares) respectively…

Mounting Windows SMB Shares

To auto-mount a Windows SMB share from a file server or NAS device, your fstab entry will look similar to:

//winserver/sharename  /cifs_mnt  cifs   credentials=/home/user/.smbcred,uid=1000,gid=1000 0 0

Breaking this down:

• //winserver/sharename – The UNC path to the SMB network share
• /cifs_mnt – Where to mount locally
• cifs – The CIFS filesystem driver
• credentials – Path to a file storing username/password for authentication
• uid, gid – Ensure all file permissions align with given Linux user

By passing a *.smbcred file containing username and password, mounts can happen automatically without prompting for credentials manually.

Mounting NFS Network Shares

To natively mount remote NFS exports from a Linux server, edit fstab to resemble:

nfsserver:/export  /local/nfs  nfs  rw,hard,intr,rsize=8192,wsize=8192 0 0

Where:

• nfs_server: – Hostname and export path of NFS server
• /local/nfs – Where to mount the NFS locally
• nfs – The NFS filesystem type
• rw – Mount read/write
• hard – Reconnect NFS aggressively if connection drops
• intr – Allow NFS requests to interrupt on server if it hangs

After a reboot, the remote NFS share will mount automatically as if it were a local folder!

Troubleshooting Mount Issues

If you configure a new network filesystem mount in fstab but it fails to materialize after a reboot, there are some basic steps to troubleshoot…

1. Check /var/log/messages or other system logs for mount error messages
2. Try manually mounting just that fstab entry with mount -a to check for issues
3. Validate NFS server exports or SMB share access from client first
4. Adjust mount options, credentials or host server details
5. Start mount attempts from scratch after fixing potential problems

Getting trickier automounts working can require some tinkering, but the flexibility of /etc/fstab makes it possible with some trial and error!

Advanced Examples and Usage Tips

While I‘ve covered the basics of fstab – including for automounts over the network – there is a huge range of more advanced configuration possible depending on your needs…

Here are just a few examples of clever customizations:

Overlay Mount Points

You can "stack" mount points on the same directory to overlay one file system on top of another. For example:

/dev/sda1  /myapp ext4 rw 0 0
/dev/sdb1  /myapp ext4 rw 0 0

This mounts both partitions onto /myapp…but with the second one overlaying and obscuring the first. Only the second FS is exposed at that path.

Bind Mounts

You can also "bind mount" filesystems to specific paths they don‘t initially belong to.

For example, this would mirror the root FS onto /backuproot :

/   /backuproot none bind,rw 0 0

This gives users access to an alternate path mirroring root, without root FS space actually being consumed.

Automounting Optical Media

You can configure automounting of DVDs, CD-ROMs and other optical media using custom options in /etc/fstab.

For example:

/dev/cdrom  /mnt/cdrom auto ro,noauto,user  0 0

This would auto mount CDs inserted by a user to /mnt/cdrom.

Versioned Mount Points

sysadmins running multiple versions of app code sometimes need to mount filesystem "branches" onto versioned directories, like:

/dev/versions/app-v1  /opt/myapp/v1  xfs  rw,auto 0 0  
/dev/versions/app-v2  /opt/myapp/v2 xfs rw,auto 0 0

This lets you expose separate revisions of code unraveled onto their own mount points.

As you can see – there are tons of possibilities once you master /etc/fstab syntax and mount options! You‘re only limited by your sysadmin imagination 🙂

Conclusion: Now You‘re a Linux Mount Expert!

And with that – you now have comprehensive knowledge for directly managing the heart of Linux mounts – the almighty /etc/fstab configuration file!

You learned how fundamental fstab is for mounting partitions, drives and remote shares during system boots. How to define mount points, locking down permissions/access, and getting creative with overlaid file systems or versioned branches.

We covered best practices for editing safely, troubleshooting issues with automounts failing unexpectedly…

And finally some advanced examples to spark your creative sysadmin mind!

You should now feel empowered to directly fine tune any Linux server‘s mounts to suit your environment‘s needs. No GUI crutches required!

So try out your newfound mount mastery skills on test servers, edit some fstabs with precision, reboot confidently, and smoothly mount shares from other operating systems automatically so users can access networked storage easily.

The filesystem management possibilities are now endless for you. Have fun!