Linux Disks, Storage and Mounts for Windows Users

Linux storage is mounted into one directory tree

Windows commonly presents volumes as C:, D: and other drive letters. Linux instead attaches filesystems at mount points inside the directory tree rooted at /. A separate disk can therefore appear at a path such as /mnt/archive or another location chosen by the system.

The physical device, partition, filesystem and mount point are separate concepts. Troubleshooting becomes much easier when you identify which layer you are looking at.

lsblk answers “what block devices exist?”

lsblk displays disks, partitions and relationships between them. It is a good first step before any storage operation because it helps distinguish the system disk from removable or secondary media.

Device names such as /dev/sda, /dev/nvme0n1 or /dev/mmcblk0 can vary with hardware and boot order. Never copy a destructive command with a device name from another computer and assume it identifies the same disk on yours.

findmnt answers “what is mounted where?”

findmnt shows the relationship between a mounted filesystem and its target path. This is useful when a path is unexpectedly read-only, when a removable drive is mounted somewhere unfamiliar, or when you need to confirm which filesystem backs a directory.

Mount information also explains why two directories can have different capacity or filesystem behavior even though they are part of the same visible directory tree.

df and du answer different space questions

df reports filesystem-level space usage. du totals the space used by files and directories it can see. Those numbers can differ because deleted-but-open files, snapshots, reserved blocks and permission boundaries affect what each tool can account for.

Use df to ask “which filesystem is full?” and du to ask “which visible directory tree is consuming space?” That distinction prevents unnecessary deletion in the wrong location.

Persistent mounts should use stable identifiers

Linux can identify filesystems by UUID or labels rather than relying only on a device name that may change. Persistent mounts are commonly described in /etc/fstab or by systemd mount units. A mistake in persistent mount configuration can affect boot, so make one change at a time and validate it before restarting.

When adding a filesystem, confirm its type, UUID, intended mount point and required options. Avoid using permissive options merely to silence a permissions problem.

Formatting and filesystem repair require extra care

Formatting creates a filesystem and destroys the previous filesystem structures on the selected target. Filesystem repair tools can also be unsafe when used against a mounted filesystem, depending on the filesystem and operation. Verify the exact device and read the relevant filesystem documentation before making changes.

If the data matters, create or verify a backup before repair or partition work. A backup is cheaper than learning recovery procedures after a mistaken device selection.

Permissions can be part of a storage problem

A mounted filesystem can be healthy while a user still cannot create files in the mount point. Ownership, permissions, filesystem type and mount options all affect access. Network filesystems add another layer because server-side identity and permissions may also matter.

Diagnose the access model rather than applying broad write permissions to the entire mount.

A safe storage checklist

• Use lsblk to identify devices before changing anything.
• Use findmnt to confirm the current mount source and target.
• Use df for filesystem capacity and du for directory usage.
• Prefer stable identifiers such as UUIDs for persistent mounts.
• Validate persistent mount configuration before rebooting.
• Unmount or follow filesystem-specific guidance before repair operations.
• Verify backups before partitioning, formatting or repair work.