Demystifying Mounted vs Unmounted Drives in Linux

As a developer or IT pro, understanding mounted and unmounted drives in Linux is essential. Whether you are trying to access an old project off a USB stick, recover data from a dying hard drive, deploy code to prod servers, or just tidying up the cables under your desk, mounting drives properly in Linux should be second nature.

Let‘s first understand what mounting and unmounting means, then dive into the key commands to manage storage drives from a Linux terminal.

Breaking Down Mounted vs Unmounted Drives

Mounting a disk or drive in Linux refers to connecting it logically into the filesystem so it can be interacted with. Think of it like introducing a new shelf in your garage to park your bike. You mounted a storage spot on the wall to neatly access the bike when needed.

For a drive to mounted, it needs:

• An empty mount point directory like /mnt/usbstick
• The right Linux filesystem driver to read the format (EXT4, NTFS, XFS etc)
• Valid partitions defined for the data regions
• Approval from the Linux kernel to attach at the defined mountpoint

Once successfully mounted by the OS, the files and folders stored in partitions on the drive become available through normal file input/output operations.

Conversely, unmounted drives are detached from the filesystem tree. Like taking down that bike shelf, the data is still physically connected by a SATA/USB cable, but logically the OS cannot access it anymore. The filesystem drivers and mount point linkages are destroyed.

Common examples of unmounted drives:

• A secondary internal HDD used occasionally for backups
• An encrypted external drive for sensitive financial docs
• A shared department NAS drive that gets manually mounted on demand

There are very good reasons to leave drives unmounted in Linux, rather than automounting everything on boot. But how do you reveal these disconnected disks?

5 Essential Commands to View Unmounted Drives

Let‘s explore the key commands for displaying unmounted disks and partitions in Linux, critical knowledge for any developer or sysadmin.

1. List All Drives with lsblk

The lsblk utility lists all block devices visibile to the system in a handy tree format showing the connections between physical, virtual, partitioned, and mounted drives.

Run a simple lsblk to display the breakdown:

With no mount point defined, we can tell /dev/sdb and /dev/sdc are unmounted drives attached to this system. Powerful!

lsblk has many useful options:

• -n only shows unmounted devices
• -o NAME,SIZE,TYPE,MOUNTPOINT customizes columns
• -e 7 excludes certain devices by major ID
• -l adds driver info for deeper debugging
• -f outputs info in code-friendly JSON format

For in-depth storage analysis, lsblk is my go-to tool. The frontend to the more complex sysfs subsystem.

2. Identify Drives with blkid

The blkid utility scans all block devices and extracts useful idenfitiers like the UUID, LABEL, and device type. Ever wanted to quick grab the UUID of a drive to fstab mount it on every boot? blkid does that.

Run it solo to dump all connected drive details:

sudo blkid
/dev/sda1: UUID="ea307b0f-cf1d-4039-b856-9a229ed22fac" TYPE="ext4" PARTUUID="ea29f2df-01"
/dev/sda2: UUID="CloudBackup" LABEL="CloudBackup" TYPE="ext4" PARTUUID="ea29f2df-02" 
/dev/sdb: LABEL="4TB HDD" TYPE="ext4" 
/dev/sdc: UUID="2022-01-03-Ancient-Files" TYPE="ext4"

Notice no mountpoints are shown, but we can still ID the unmounted sdb and /dev/sdc backups drives based on UUID or labels.

For crashes or unexpected drive swapping scenarios, blkid is indispensible to match data partitions to volumes. All from a simple command!

3. See All Partitions with fdisk

The fdisk utility reports partition tables on all connected block devices. This shows your physically connected drives and how the raw space is split, even unmountable partitions.

Give it a spin:

sudo fdisk -l

Example showing my 1TB SSD system drive with Linux partitions alongside a 16GB USB stick:

Disk /dev/sda: 931.5 GiB ...... 
Disk model: Samsung SSD 970  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes


Disk /dev/sdb: 15.9 GiB, 16110895104 bytes, 3145728 sectors
Disk model: Cruzer Force   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

The output gives you the whole landscape of mount candidates across physical and logical volumes. Great for triple checking your partitioning before a resize operation.

4. Disk Usage via df and du

The classic df and du commands report filesystem utilization on mounted volumes. But add a -a flag to show all devices with the potential free space, including unmounts.

Call df with human-readable output:

df -h -a

And similarly for du recursive usage estimates:

du -h -a /

This supplements fdisk nicely to map the filesystem types onto the raw partitions across drives, revealing unmounted volumes.

Here‘s a snippet of df -h -a showing a drive not mounted, but formatted and ready with free space:

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda2      ext4       97G   63G   31G  67% /
/dev/sda1      ext4      512M  9.6M  503M   2% /boot
/dev/sdb1      ext4       15G   55M   14G   1% 

5. Summarize All Partition Tables with parted

The parted utility allows directly editing disk partition tables. Run parted -l to print out a summary of all currently defined partitions across devices along with size info.

Here‘s some sample output:

$ parted -l
Model: ATA Samsung SSD 860 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  538MB   537MB   primary  ext4         boot
 2      538MB   1000GB  1000GB  primary  ext4

Model: General UDisk (scsi)                                     
Disk /dev/sdb: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type     File system  Flags
 1      1049kB  16.0GB  16.0GB  primary               lba

We can quickly identify the unformatted 16GB /dev/sdb thumb drive, while also confirming the mountpoint locations and space on the mounted root SSD.

This overview helps catch configuration issues before attempting any storage operations.

Comparing Mounting Drives: Windows vs Linux

Since most developers are familiar with Windows first, it‘s worth contrasting how Windows automatically mounts drives on boot vs the Linux approach requiring manual mount commands.

In Windows, virtually all connected drives are immediately assigned a drive letter (C:\, D:\, etc) and mounted into the filesystem automatically without user intervention. External USB sticks, internal SATA drives,CD/DVD ROMs, SD cards, the lot. This allows plug-and-play access to data volumes by default.

The downside is no control over which drives map where, the formatting, or restrictions on access. If you want to isolate a partition or restrict I/O through encryption, extra steps are needed in Windows to override the aggressive automounting.

In Linux, drives connected are detected but not automatically mounted by default. The user has to manually run mount commands to graft external storage into folders like /mnt/usbstick explicitly. This gives complete control over partitioning schemes, filesystem choice per drive, mount locations, user permissions, and encryption options. But extra effort is required to initially mount disks.

Linux never assumes how you want drives exposed to users and apps. The distro leaves that mapping fully in your hands, which suits servers and shared workstations well.

Unmounting Drives Properly

Just as essential as mounting drives is unmounting them properly in Linux. Similar to ejecting a CD tray or USB stick in Windows, this logically disconnects the volume from the host filesystem to allow safe removal.

Why Unmount Drives?

Unmounting is critical before:

• Physically disconnecting an external portable drive
• Moving an internal drive between SATA ports or machines
• Creating or resizing disk partitions
• Enabling encryption on an existing filesystem

Unmounting flushes any cached writes and notifies applications to close handles to the files. Otherwise, yanking out a live drive risks data corruption if writes are interrupted mid-transfer.

The classic method is the terminal command:

sudo umount /dev/sdc1

But most Linux GUIs also provide right-click Safely Remove Drive options that handle unmounting volumes properly before disconnecting.

Underlying most removals is udisks, a daemon that auto-mounts & unmounts removable devices as needed based on GUI eject events or systemd power events.

There‘s also tools like udiskie and udevil that gives advanced automounting control.

For networked filesystem administration, the autofs service mounts on access and unmounts after idle timeouts. This avoids keeping rarely used partitions mounted indefinitely.

Under the Hood: Mounts and Linux Filesystems

While the mount command seems simple on the surface, a lot happens under the hood in the Linux kernel whenever you graft storage onto the virtual unified filesystem. Let‘s peek behind the curtain!

There‘s two key concepts that glue unmounted devices into the running OS dynamically:

Virtual Filesystems: Present a common interface layered over disparate physical filesystems like hard drives, SSDs, CDROMs and even remote SMB network shares.

The Mount Namespace: Maps the relationship between mounted directories backed by block devices, controlled by the mount syscall between user and kernel space.

Here‘s a simplified play-by-play of mounting a USB stick on /mnt/disk via the terminal:

1. The mount command makes a syscall to the kernel requesting to graft the unmounted /dev/sdb1 partition onto the unused mountpoint directory /mnt/disk
2. The kernel checks that /dev/sdb1 is a valid block device and /mnt/disk is an empty dir with permissions to mount filesystems
3. The appropriate low-level filesystem driver registers to handle communication – likely EXT4 or FAT32 for a USB device
4. The virtual filesystem layer interfaces with the drives‘ software driver and surfaces content transparent through standard POSIX file ops
5. Applications can now access files by path as if part of the same local directory tree, unaware of the underlying storage magic

When unmouted later, the kernel carefully flushes cache buffers and disconnects the interfaced filesystem drivers from the partition. Rinse and repeat next time the drive is connected.

Real-World Usage: Developers & Sysadmins

Hopefully the above gives you new insight into what‘s happening behind the mount command and how Linux gains its flexible storage composability.

Let‘s call out some practical examples of how mounted/unmounted drives apply to developers and sysadmin workflows:

• Data scientists mounting large research datasets on a home directory for number crunching then unmounting later. No need to waste SSD space.
• App developers testing builds restoring stateful container volumes backed by unmounted legacy DB partitions.
• ML engineers pulling prod analytics extracts from a NAS mount that IT admins manually connect on-demand due to sensitive PII data stored.
• Startup founders with a replicated NAS mirror in their garage backing up GitHub repositories via a nightly rsync cronjob to an intermittantly mounted drive whenever they WFH.
• Site reliability engineers attaching scratch EBS volumes to AWS instances to handle temporary batch jobs then destroying later to save cloud costs.

There‘s endless applications where controlling filesystem mounts explicitly is handy both locally and in production pipelines. Appreciate how Linux enables this portable storage composability yet leaves you fully in charge.

Conclusion: Take Control of Mounted Drives

I hope this article has demystified the concept of mounted vs unmounted drives in Linux for curious developers. Mount namespaces, virtual filesystems, and flexible storage drivers underpin a incredibly modular approach to attaching removable media.

Now that you understand the tools available to show connected disks, try manually mounting some drives yourself! Get familiar with carving up partitions, formatting filesystems, tuning mount options, and scripting disk backups via cronjobs.

Linux really opens up the entire stack to tinker with. Have fun and let me know what cool storage projects you build on social media!