Right, let’s talk about getting your filesystems to actually show up. You’ve got this block device—a hard drive partition, a USB stick, a network share, a DVD (bless you, retro enthusiast). It’s just a bucket of ones and zeros to the kernel right now. The mount command is how you tell the system, “Hey, take that bucket, decode it using this specific set of rules (the filesystem type), and slap its contents onto this directory so we can get to it.” The umount command (yes, it’s umount, not ‘unmount’, a petty hill I will die on) is how you politely ask the system to stop doing that so you can, say, yank the USB drive without corrupting everything.

Think of a mount point—that empty directory you use—as a magical doorway. When it’s empty, it’s just a directory. The moment you mount a filesystem to it, that directory becomes a portal to another storage dimension. umounting it closes the portal, and it goes back to being a boring, empty directory. This is why you should always use an empty directory as a mount point; putting a filesystem on top of a directory that already has stuff in it doesn’t delete the old stuff, it just hides it until you unmount the new filesystem. It’s a classic “now you see it, now you don’t” parlor trick that’s more annoying than impressive.

The Basic Incantation

The classic, manual way to mount something looks like this. You need to know what you’re mounting, where you’re mounting it, and what kind of beast it is.

# Mounting a garden-variety ext4 partition
sudo mount -t ext4 /dev/sdb1 /mnt/mydrive

# Mounting a NTFS USB drive (you'll likely need the `ntfs-3g` package)
sudo mount -t ntfs-3g /dev/sdc1 /media/backup

# Mounting an ISO file without burning it to a disc (because it's the 21st century)
sudo mount -t iso9660 -o loop ubuntu-22.04.iso /mnt/iso

The -t flag specifies the filesystem type. The kernel and its helpers are pretty good at detecting this automatically nowadays, so you can often omit it and just run sudo mount /dev/sdb1 /mnt/mydrive. I still like to specify it when I’m writing scripts or doing something unusual—it’s a good habit that avoids weird, silent failures.

Options Are Where the Fun Begins

This is where mount gets its real power. The -o flag lets you pass a comma-separated list of options that drastically change behavior. Forget to use these and you’ll be back here wondering why things are slow or broken.

# Mount a network share (NFS) but don't let the system hang forever if the server dies
sudo mount -t nfs -o hard,intr nfs-server:/exported/share /mnt/share

# Mount a USB drive for a user, giving them full read-write access
sudo mount -o uid=1000,gid=1000 /dev/sdd1 /mnt/usb

# Mount a filesystem as read-only because you're paranoid (a good kind of paranoid)
sudo mount -t ext4 -o ro /dev/sdb2 /mnt/investigate

# Remount a filesystem with new options on the fly (e.g., making it read-write)
sudo mount -t ext4 -o remount,rw /dev/sdb2 /mnt/investigate

Some lifesavers: nofail tells the system to boot happily even if this disk isn’t present (crucial for external drives in /etc/fstab). nodev prevents device files from being interpreted, a good security practice for untrusted filesystems. noexec prevents binaries from being run directly from the filesystem, another good paranoia setting.

The Fatal umount Error: Device is Busy

You’ve all been here. You type umount /mnt/drive and it spits back umount: /mnt/drive: target is busy. This is the kernel’s incredibly useful but frustrating way of saying, “Nope, someone or something is still using a file on that filesystem.” You are the someone. Your shell is probably sitting in that directory. Or maybe you have a file open in vim, or a process is running from that location.

The fix is almost always simple: leave the mount point directory. cd ~ and try again. If that doesn’t work, the lsof and fuser commands are your detectives to find the offending process.

# See which processes are keeping files open on a mount point
sudo lsof +f -- /mnt/mydrive

# Or use fuser to show the PIDs
sudo fuser -v /mnt/mydrive

# And if you're feeling particularly direct, use fuser to kill them all
sudo fuser -km /mnt/mydrive

The nuclear option (-km) sends a SIGKILL to every process using that filesystem. It’s effective, but it’s the equivalent of solving a doorjamb problem with a sledgehammer. Your unsaved work in that terminal will vanish. Use it as a last resort.

Permanent Mounts with /etc/fstab

Manually mounting things every boot is for masochists. The /etc/fstab file is your friend. It’s a table of filesystems to be mounted at boot. The syntax is a beautiful, space-or-tab-separated work of art that everyone gets wrong on the first try.

Here’s a typical entry for a partition:

# <file system>             <mount point>  <type>    <options>         <dump>  <pass>
UUID=a1b2c3d4...            /mnt/data      ext4      defaults,nofail  0       2

A few pro tips: Use the UUID= instead of /dev/sdX because device names can change between boots; find it with blkid. The nofail option I mentioned earlier is critical for non-essential drives—it prevents your entire system from hanging on boot if the drive has died. The <pass> column (the last number) controls fsck order: use 0 for don’t check, 1 for the root filesystem, and 2 for everything else.

The Dangers of Lazy Unmount

When you’re truly, utterly stuck and umount -l (lazy unmount) starts looking real good, know what you’re doing. A lazy unmount detaches the filesystem from the directory tree now, but it only actually cleans up once the device is no longer busy. This means any processes still using it can continue to read/write, but no new processes can access it. It’s a way to get your terminal prompt back so you can cd somewhere else. It’s not a safe way to remove a device. The kernel will finish the unmount when all processes close their files. It’s better than yanking the cable, but it’s not a substitute for a clean unmount. Consider it a last resort that’s slightly less destructive than a reboot.