Linux does not have drive letters. Every filesystem is grafted onto a single tree at a mount point — a directory that becomes the doorway to that storage. Once that idea lands, the rest of this page is mechanics.
physical disk → partition → filesystem → mount point
/dev/sda /dev/sda2 ext4 /homeSeeing what you have
lsblk # the block device tree — start here
lsblk -f # with filesystem type, label and UUID
sudo blkid # UUIDs and types, one line per device
findmnt # everything currently mounted, as a tree
findmnt /home # what is mounted here, and how
df -hT # mounted filesystems with type and free space
sudo fdisk -l # partition tables$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINTS
sda
├─sda1 vfat EFI A1B2-C3D4 /boot/efi
├─sda2 ext4 root 8f3c1e77-4b2a-4f1e-9c0d-2a7b5e9f1c33 /
└─sda3 swap 1c9d2b44-7e33-4a55-b1f2-6d8c3a0e7b91 [SWAP]
sdb
└─sdb1 ext4 backup 3e7a9c12-8d64-4b7f-a2e5-9f0b1d4c6a28lsblk -f is the single most useful command here: devices, filesystems, labels, UUIDs and where each is mounted, in one screen. An empty MOUNTPOINTS column means the filesystem exists but is not currently attached anywhere — sdb1 above.
Mounting by hand
sudo mkdir -p /mnt/backup
sudo mount /dev/sdb1 /mnt/backup # mount it
sudo mount -o ro /dev/sdb1 /mnt/backup # read-only
sudo mount UUID=3e7a9c12-... /mnt/backup # by UUID rather than device name
sudo umount /mnt/backup # unmount (note: no 'n')
sudo mount -a # mount everything in fstabThe mount point directory must exist first. Anything mounted this way disappears at reboot — for permanence you need fstab, below.
“target is busy”
Something has a file open, or a shell is sitting in the directory. Find out what:
lsof +f -- /mnt/backup # which processes are using it
fuser -vm /mnt/backup # the same question, shorter output
cd ~ # very often it is your own shellumount -l (lazy) detaches it from the tree immediately and cleans up when the last user finishes. It gets you out of a bind, but it does not flush anything those processes are still writing, so it is not a safe substitute for closing them properly. See processes for tracking the offender down.
fstab: mounting at boot
/etc/fstab lists what should be mounted at startup. Six fields per line:
UUID=3e7a9c12-8d64-4b7f-a2e5-9f0b1d4c6a28 /mnt/backup ext4 defaults,nofail 0 2
│ │ │ │ │ │
│ │ │ │ │ └─ fsck order
│ │ │ │ └──── dump (leave 0)
│ │ │ └──────────────────── options
│ │ └───────────────────────── filesystem type
│ └───────────────────────────────── mount point
└─────────────────────────────────────────────────────────────── what to mountThe last field is the filesystem check order: 1 for root, 2 for other permanent filesystems, 0 to skip — which is what you want for removable and network mounts.
Always use UUIDs
Device names are not stable. /dev/sdb is assigned in the order the kernel finds disks, which can change when you add hardware, move a drive to a different port, or simply boot with a USB stick plugged in. An fstab entry naming /dev/sdb1 can silently point at a completely different disk after a reboot.
A UUID belongs to the filesystem itself and follows it anywhere — including into every copy of it. Get it from lsblk -f or blkid, and use UUID= in every fstab line. Be aware of what that does not buy you: cloning a VM, restoring a disk image, dd-ing a disk or attaching a snapshot beside its origin produces two filesystems with one UUID, and /dev/disk/by-uuid/ can only name one of them. LABEL= is easier to read and it is less safe rather than equally safe, because a label is a short word a person chose — two disks both labelled backup are a matter of time. The Life of a Block Device follows what happens next.
nofail is not optional
This is the one that turns a small mistake into a very bad afternoon. By default, a filesystem in fstab that cannot be mounted stops the boot and drops the machine into emergency mode asking for the root password. On a laptop that is annoying. On a headless server or a cloud VM with no console, it is an outage.
UUID=... /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2nofail lets the boot continue if the device is absent. The device timeout stops systemd waiting the default ninety seconds for hardware that is not there. Put both on every non-essential entry — external drives, USB disks, network shares.
Test before rebooting
sudo findmnt --verify --verbose # check fstab for errors
sudo systemctl daemon-reload # systemd re-reads fstab
sudo mount -a # try mounting everything now
findmnt /mnt/backup # confirm it workedNever reboot straight after editing fstab. mount -a exercises the same entries while you still have a working shell to fix them in. systemd generates mount units from fstab at boot, so daemon-reload is needed for it to notice your changes — the same pattern as editing unit files, covered in systemctl. Know what findmnt --verify checks and what it does not: it confirms the target exists, that the tag resolves to a device, that the device exists and that the type matches. It does not check that the tag resolves uniquely, and it does not look inside the mount point — it reports Success, no errors or warnings detected on an entry that will mount a duplicate and on one whose mount point already holds data. Add findmnt --fstab --evaluate, which prints the device each line will actually reach; the same device appearing on two lines is the collision --verify cannot see.
Options worth knowing
| Option | Effect |
|---|---|
defaults | rw, suid, dev, exec, auto, nouser, async |
nofail | Do not stop the boot if this cannot be mounted |
ro | Read-only |
noatime | Do not update access times — less write wear, slightly faster |
noexec | Refuse to execute binaries from here |
nosuid | Ignore setuid bits — sensible on removable media |
user | Allow a normal user to mount it |
noauto | Do not mount at boot, but allow mount /mnt/x |
x-systemd.automount | Mount lazily on first access — ideal for network shares |
noexec,nosuid,nodev on anything removable is a cheap and worthwhile precaution — see file permissions for why setuid on an untrusted disk is a bad idea.
Other filesystems
# Windows drives
sudo mount -t ntfs3 /dev/sdb1 /mnt/windows
sudo mount -t exfat /dev/sdc1 /mnt/usb
# FAT and exFAT have no Linux permissions — set them at mount time
sudo mount -o uid=1000,gid=1000,umask=022 /dev/sdc1 /mnt/usb
# Network shares
sudo mount -t nfs server:/export /mnt/nfs
sudo mount -t cifs //server/share /mnt/smb -o credentials=/root/.smbcreds
# An ISO, read-only
sudo mount -o loop image.iso /mnt/isoFAT and exFAT store no ownership information, so everything appears owned by whoever mounted it unless you pass uid and gid. That is why a USB stick sometimes shows every file as root-owned and unwritable.
For SMB shares, keep the credentials in a root-owned file with mode 600 rather than in fstab, where they would be world-readable.
Gotchas
Mounting over a directory hides what was there
If /mnt/data already contained files and you mount a disk on it, those files vanish from view — they are still on the underlying filesystem, still using space, just covered. This is a classic cause of a disk that is mysteriously full; see disk space. Unmount and look underneath to check.
Unmount before unplugging
Linux caches writes aggressively. A file copy that appears finished may still be in memory, and pulling the drive loses it. umount flushes and detaches properly. sync flushes without unmounting, which is the safety net when you are unsure.
The filesystem is smaller than the disk
After growing a virtual disk or a partition, the filesystem does not expand on its own. lsblk shows the new size while df shows the old one. Grow it explicitly with resize2fs for ext4 or xfs_growfs for XFS — after taking a backup, because partition work is the one place on this site where a mistake destroys data rather than inconveniencing you.
Read-only after a crash
A filesystem that hits errors remounts itself read-only to prevent further damage. That is protective, not the problem itself. Check dmesg and journalctl -k for I/O errors, then run fsck on the unmounted filesystem. Never fsck something that is mounted read-write.
Desktop auto-mounting is separate
Plugging in a USB stick on a desktop mounts it under /run/media/<user>/<label> via udisks, not through fstab. Adding an fstab entry for the same device can conflict with it, which is why removable drives usually belong in fstab only with noauto.
Quick reference
lsblk -f # devices, filesystems, UUIDs, mount points
blkid # UUIDs and types
findmnt # what is mounted, as a tree
df -hT # free space with filesystem types
sudo mount /dev/sdb1 /mnt/x # mount
sudo mount -o ro /dev/sdb1 /mnt/x
sudo umount /mnt/x # unmount
sudo umount -l /mnt/x # lazy — last resort
fuser -vm /mnt/x # what is holding it open
# fstab: device mountpoint type options dump pass
UUID=... /mnt/x ext4 defaults,nofail 0 2
sudo findmnt --verify # check fstab before rebooting
sudo systemctl daemon-reload
sudo mount -a # test every entry nowRelated
- The Life of a Block Device — the long one: the eight stages between the kernel registering a disk and the other copy of it somewhere else, why
mount UUID=reads a symlink rather than searching the disks, and why no name your disk has is both stable across a move and unique across a copy. - Disk space — which filesystem is full, and files hidden under a mount point.
- systemctl — systemd turns fstab into mount units, hence
daemon-reload. - File permissions — why
nosuidandnoexecmatter on removable media. - Processes — finding whatever is keeping a mount busy.
- rsync — moving data onto the disk once it is mounted.