Storage · 65-guide series
Storage — Disks That Won't Mount, Errors, Slow Drives and File System Trouble
A working series for Linux, Windows and macOS · 65 distinct guides in 12 categories
Most storage problems fall into a handful of shapes: the machine can't see the disk, it sees it but can't mount it, it mounts but behaves slowly or read-only, or the data on it is in danger. This series walks through each shape separately, so you can go straight to the guide that matches what you're actually seeing instead of wading through generic advice.
Every guide follows the same discipline the rest of the site uses: establish what is really happening, gather evidence, make one safe change, and verify before moving on. Where a command could touch a disk, the guide says so up front and tells you when to image or back up first. Storage is the one area of computing where a wrong step can be permanent, so "safe" is treated as a feature, not a footnote.
Use the search and filters to jump to a guide, or work through the categories in order if you're starting from scratch. Each guide is self-contained and labelled by difficulty and platform, so you can tell at a glance whether it's a quick check or a deeper, higher-risk procedure.
The path every storage diagnosis follows: controller → drive → filesystem, and the stage that fails is usually your bottleneck.
Read this before you run anything. Storage is the one place where a wrong command can destroy data that cannot be recovered. The guides in this series mark safe, read-only checks and higher-risk operations separately. If the data on a drive matters, make an image or backup first — before any repair, reformat, or re-partition. When in doubt, stop and read when to call a professional.
Start here
If you're not sure where to begin, this is the order a technician would use. Each step links to the guide that covers it.
- Confirm the machine actually sees the disk. Can't see a drive at all · Seen in BIOS, not in the OS
- Identify it correctly. Read the device names · Find the UUID
- Check its health before you touch it. Read SMART · Warning signs of a failing drive
- Read the logs. Kernel messages · I/O errors
- Only then, mount or repair. Detected but won't mount · When a repair makes things worse
- Protect the data. First 10 minutes · A real backup strategy
No guides match that combination. Try a shorter word, or .
Disk detection and identification
6 guidesBefore you can fix a storage problem, you have to be certain which physical object you're actually looking at. "The drive" is rarely a single thing — it's a disk, one or more partitions on it, a volume with a filesystem, and a mount point, and each can fail independently. This category gets you fluent in the difference, because almost every later step depends on naming the right one.
The symptoms here are usually blunt: a drive that simply isn't listed, one that appears in firmware but not in the operating system, or one that comes and goes. The common mistake that makes things worse is reacting to "not seeing it" by formatting a device — including the wrong one. The guides in this category are deliberately read-only: they teach you to look, name, and confirm before any action, and they explain how a drive's identity changes (and doesn't) between reboots.
If a guide in this category shows your drive is present and healthy, the problem almost certainly lives in one of the next two categories (mounting or filesystems), so you'll save time by not repeating hardware checks.
Why the computer can't see a drive at all — first steps
"Not seeing a drive" is the most common storage complaint, and the cause is usually somewhere between the cable and the operating system rather than the drive dying. The goal of this first step is to separate physically present from enumerated by the OS, because the fix is completely different for each.
Work from the outside in. Confirm the drive has power and the cable is fully seated, try a different port and a different cable, and — if it's external — try a second computer. Then check whether the firmware sees it: on most machines you can look in BIOS/UEFI or use the OS device list. If firmware sees it but the OS doesn't, that's a controller/driver problem, not a dead disk.
Diagnose: power → cable → port → another computer → firmware → OS list. Stop at the layer where it stops appearing.
# Linux
lsblk
# Windows: run "diskmgmt.msc" · macOS: Disk UtilityDon't format a device "to make it appear." If it isn't listed yet, there's nothing to format — and the wrong device name is the classic way to erase the wrong disk.
Verify: the disk appears in lsblk / Disk Management / Disk Utility. Prevent: keep a known-good cable and use rear ports on desktops.
Reading device names: /dev/sd*, /dev/nvme*, and drive letters
Device names tell you the interface and the layout. /dev/sda, sdb… are SATA/USB-attached disks; sda1 and sda2 are partitions on the first disk. NVMe drives use a different scheme — /dev/nvme0n1 is the first NVMe namespace, and its partitions are nvme0n1p1 (note the p before the number, which separates the "nvme0n1" base from the partition). Windows uses letters (C:, D:) and macOS uses /dev/disk0 with /dev/disk0s1 for slices.
The reason this matters is that every later command needs the exact device, and the difference between a whole disk and one of its partitions is the difference between "inspect" and "wipe everything." Always check the type before acting.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MODEL,SERIAL| Pattern | Means |
|---|---|
/dev/sda | A whole SATA/USB disk |
/dev/sda1 | Partition 1 on that disk |
/dev/nvme0n1 | First NVMe namespace (whole disk) |
/dev/nvme0n1p1 | Partition 1 on that NVMe disk |
Prevent: treat the base device (sda, nvme0n1) as dangerous and the numbered ones as the safe, specific targets. See using UUIDs for a name that won't change.
Finding a drive's UUID and serial number
Device names like sda can change between boots and when you add hardware, which is why anything permanent (like an auto-mount) should reference a UUID instead. A UUID is a filesystem-level identifier that stays put even if the disk moves to a different port or sda becomes sdb. The serial is a hardware identifier from the drive itself.
Grab both and keep them handy — you'll use the UUID in /etc/fstab and the serial to match a disk in logs and SMART output.
blkid
lsblk -f -o NAME,UUID,SERIAL,FSTYPEVerify: the output shows a UUID=… for each mounted or formatted partition. Prevent: use the UUID, not the /dev/sdX name, in any persistent configuration.
Disk vs partition vs volume: the difference that prevents mistakes
These three are often used interchangeably but they're nested, not identical. A disk is the physical device. A partition is a slice of that disk defined in the partition table — a disk can hold several. A volume (or filesystem) is the formatted, usable storage inside a partition. You mount a volume at a mount point (a folder) so files can be reached.
Confusing these is how data gets destroyed: a command aimed at "the disk" that was really meant for "one partition" touches everything on it. If you can say clearly which of the four you mean, almost every storage command becomes safer to reason about.
| Term | What it is | Example |
|---|---|---|
| Disk | Physical device | /dev/sda |
| Partition | A slice of the disk | /dev/sda1 |
| Volume / filesystem | Formatted storage in a partition | ext4 on sda1 |
| Mount point | The folder it appears at | /mnt/data |
Prevent: name the level you mean out loud before running a command. See partition tables and mounting.
A drive that shows in BIOS/UEFI but not in the OS
When firmware lists the drive but the operating system doesn't, the disk is electrically present — the failure is in the software path between the controller and the OS. The usual suspects are a missing or faulty storage controller driver, a cabling fault that passes firmware's simpler check but fails the OS's, a SATA mode mismatch (IDE/legacy vs AHCI/NVMe), or a disk using a layout the OS can't parse.
This is a good state to be in: the drive is almost certainly not dead. On Linux, the kernel log will usually name the controller or the port; on Windows, Device Manager shows whether the controller or the disk has a warning.
dmesg | grep -iE "ata|nvme|scsi|sata"
lspci | grep -iE "sata|nvm|mass"Diagnose: read the log lines around the port, check the SATA/NVMe mode in firmware, and confirm the controller driver is loaded. Verify: the disk appears in lsblk after the fix.
A drive that disappears from the list while running
A drive that drops out and reappears is telling you the connection or the drive is unstable — and it's a warning to protect the data on it, because the same instability that drops it can corrupt a write. The pattern matters: a USB drive that drops under load points to power; a drive that drops with a burst of controller errors points to the cable or controller; a drive that drops as its SMART degrades is failing.
Capture the moment it happens. The kernel log records the reset or offline event with the device, which is the fastest way to tell whether it's the port, the cable, or the disk.
dmesg -w # watch live, then reproduce the problem
# afterwards:
dmesg | grep -iE "reset|offline|error|link|sd|nvme|usb"If this drive holds important data, treat it as at-risk now: stop writing to it and image it before you chase the cause.
Mounting and mount-point problems
6 guidesDetection and mounting are two different gates. A disk can be perfectly healthy and fully detected and still be impossible to open, because mounting is the step where the operating system says "yes, I can read the filesystem on this." Most "my drive won't open" problems live here, and the error message at this step is usually specific enough to point straight at the cause.
The recurring mistake is treating a mount failure as a reason to format or to run a repair tool immediately. In reality a drive that won't mount is frequently read-only, mislabelled, full, or simply mounted at the wrong place — none of which need a reformat. These guides decode the actual mount errors, cover mount-point confusion, explain what a read-only mount is really warning you about, and then move on to making mounts automatic and safe at boot.
A drive that is detected but won't mount
When lsblk lists the partition but you can't open it, the question is "what filesystem is on it, and what does the kernel say when I try?" Start by reading the filesystem type — a blank type often means the OS can't identify a valid filesystem at all — then attempt a mount and read the exact error. That error is your diagnosis.
Try it read-only first. Mounting with -o ro lets you inspect (and, critically, back up) without risking further damage if the filesystem is already unhappy. If it mounts read-only fine but not read-write, that's a filesystem integrity signal, not a hardware one.
blkid /dev/sdX1
sudo mkdir -p /mnt/inspect
sudo mount -o ro /dev/sdX1 /mnt/inspect
cat /proc/mounts | grep /mnt/inspectDon't run a repair or a format just because mounting fails. Read the error first — see decoding mount errors.
Verify: ls /mnt/inspect lists your files. Prevent: always unmount cleanly so the next mount is a clean one.
Decoding common mount errors
Mount errors are surprisingly literal. Learning to read the six you'll meet constantly removes most of the guesswork from a drive that won't open, and each one points to a different fix — so acting on the wrong one (like reformatting for a "device busy" error) wastes time or causes harm.
| Error | Usually means | First move |
|---|---|---|
wrong fs type | The OS guessed the wrong filesystem | Mount with an explicit -t type |
no filesystem could be found | No valid filesystem signature (fresh/blank or damaged) | Check blkid; don't format yet |
permission denied | Not running as root, or a permissions issue | Use sudo; check ownership |
device or resource busy | Already mounted or in use | lsof +D / findmnt |
read-only file system | Mounted ro, or the FS remounted itself ro after errors | Read the logs; see health |
Verify: after the matching fix, the mount succeeds and files are reachable. Prevent: note the real filesystem type so the OS doesn't have to guess.
Mount points: not found, already in use, or the wrong folder
A mount point is just a folder, and three folder-related problems cause most mount confusion: the folder doesn't exist yet, the folder is already a mount point for a different device, or something is using files inside it so the mount (or unmount) is blocked.
Create an empty, dedicated folder for the mount. To find out what's using a folder, list the open files in it. If a drive is "stuck mounted", it's usually because a process still has a file open inside it.
sudo mkdir -p /mnt/data
findmnt /mnt/data # is something already mounted here?
sudo lsof +D /mnt/data # what has files open in it?Verify: the mount lands at the folder you intended and nothing else is hidden behind it. Prevent: use one dedicated, empty folder per drive.
A drive that mounts read-only — and why that's a warning
A read-only mount can be intentional (you asked for -o ro) or it can be the filesystem remounting itself read-only after it detected errors — a self-preservation move. The dangerous habit is to notice "I can't save" and force it back to read-write, because that can turn contained damage into more of it.
Before changing anything, read the kernel log: if the filesystem remounted read-only on its own, it has already told you it found a problem. Copy your data off (read-only is exactly the safe mode to back up in), then investigate the cause rather than forcing writes.
findmnt -o TARGET,SOURCE,OPTIONS
dmesg | grep -iE "read-only|remount|error"
# only after you understand why:
sudo mount -o remount,rw /mnt/dataIf it went read-only by itself, back up first and check drive health before forcing read-write.
Making a drive mount automatically at boot with /etc/fstab
/etc/fstab is where you tell Linux to mount a drive every time the system starts. It's powerful and it's the one storage config where a typo has real consequences: a bad line pointing at a disk that isn't present can, on some systems, prevent a normal boot. So the rule is: use a UUID (not a /dev/sdX name), add the line, and test it with mount -a before you reboot.
A typical line names the UUID, the mount point, the filesystem type, and options. defaults is a safe start; nofail is worth adding for any removable or optional drive so a missing disk never blocks login.
sudo nano /etc/fstab
# UUID=xxxx-xxxx /mnt/data ext4 defaults,nofail 0 2
sudo mount -a # test without rebooting
findmnt /mnt/dataAlways run mount -a after editing. If it errors, fix the line while you can still get a shell — don't reboot into a broken config.
Verify: after reboot, the drive is mounted at the right place with no errors. Prevent: keep a comment copy of your original fstab.
Automounting removable media correctly
Removable drives have a different requirement than fixed ones: you don't want them mounted at boot (they might not be present), but you do want them to appear the moment you plug them in. That's "automount on connect", which is different from "mount at boot".
On systemd-based systems the clean way is an fstab entry with noauto (don't mount at boot) plus x-systemd.automount (mount on first access / when the device appears). Desktop environments often already automount USB media on their own, so first check whether you actually need to configure anything.
# UUID=xxxx /mnt/usb ext4 noauto,x-systemd.automount 0 2
sudo systemctl daemon-reload
sudo systemctl restart systemd-automountVerify: plug the drive in and it appears without a manual mount. Prevent: keep removable entries as noauto so a missing disk is never a problem.
File-system errors and corruption
6 guidesFilesystem corruption is what happens when the bookkeeping that maps your files to physical locations gets damaged — usually by a sudden power loss, an unclean unmount, a bad sector underneath, or a controller that drops a write. The symptoms range from a "filesystem needs checking" prompt at boot to a drive that will only mount read-only to files that appear to vanish.
This is the category where the "just run a repair" instinct is most dangerous. A filesystem check can fix genuine logical errors, but running the wrong check on the wrong device — or an aggressive auto-fix on a drive that is also physically failing — can make recovery harder, not easier. The guides here explain what corruption actually is, how to read the error signals, how to run the right check read-only first, and the specific cases where stopping is the correct move.
What file-system corruption actually is
A filesystem is a set of structures (superblocks, inodes, journal, directory trees) that record which file lives where. Corruption means one of those structures no longer agrees with the rest. The data may be perfectly intact on the platter — it's the map that's torn. That's why a "corrupted" drive can still hold fully recoverable files.
The common causes are all things that interrupt a write mid-flight: power loss, pulling a drive out without unmounting, a crash, a bad sector that silently corrupts a metadata block, or a failing controller. Recognising the cause matters because it changes whether a software check is safe or whether you should image the drive first.
Check first: did the last shutdown look clean? Was there a power event? Is the drive also showing hardware warning signs? If the corruption coincides with hardware trouble, treat the drive as at-risk before you run any repair.
I/O errors and the kernel messages that mean trouble
I/O (input/output) errors are the drive or the path telling you a read or write didn't complete. They're more serious than a filesystem error, because they often mean the problem is in the hardware underneath, not just the map on top. A single I/O error can be noise; a pattern of them is a signal to back up immediately.
These lines are your earliest warning system. Read them for the device and the action — a "sector read error" that retries and succeeds is different from one that keeps failing.
dmesg | grep -iE "I/O error|error|sector|ata|nvme"
journalctl -k -p warning --since "1 day ago" | grep -iE "sd|nvme|ata"| Message | Usually means |
|---|---|
I/O error, dev sdX, sector N | A read/write at that sector failed |
Buffer I/O error on dev … | Kernel couldn't complete a buffered read/write |
ataX.00: error, cmd … | The drive failed a command at the controller level |
nvme … I/O timeout | The NVMe drive stopped responding to a request |
Repeating I/O errors = back up / image now. Don't keep using the drive as normal while these appear.
"Filesystem needs to be checked" at boot
This prompt appears when a filesystem wasn't cleanly unmounted (a crash, a power loss, or a forced shutdown) or when its scheduled check interval has elapsed. It's normal maintenance, not automatically an emergency — but it is information. If it appears after every crash, the crashes are the thing to fix, not the prompt.
You can let it run (it will repair what it can) or, if you're in a hurry and the system is otherwise fine, let it skip and run the check later in a controlled way. Habitually skipping is how small problems grow into big ones.
sudo fsck.ext4 -n /dev/sdX1 # read-only check first
sudo tune2fs -c 3 -i 6m /dev/sdX1 # check every 3 mounts or 6 monthsVerify: the next boot is clean and no errors are reported. Prevent: shut down cleanly and fix whatever is causing unexpected power loss.
Repairing ext4 with fsck — safely
The one non-negotiable rule for fsck: it must run on a filesystem that is not mounted (or mounted read-only). Checking a filesystem that's live and being written to is how you create the very corruption you're trying to fix. So the sequence is: unmount, check read-only to see what it finds, then decide whether to repair.
Always run the read-only pass (-n) first. It reports what would be fixed without changing anything, so you can see the scale of the problem. Only then do you run a real repair — and only on a drive whose data you've backed up or that you've decided you can afford to risk.
sudo umount /dev/sdX1
sudo fsck.ext4 -n /dev/sdX1 # 1. read-only: see what's wrong
sudo fsck.ext4 -y /dev/sdX1 # 2. only if you accept the risk: auto-fix-y answers "yes" to every fix automatically. That's fast but it's also how an aggressive repair can discard data. If the data matters, image the drive before this step.
Verify: the read-only pass reports no further errors and the drive mounts read-write. Prevent: unmount cleanly and keep the drive's SMART healthy.
Repairing NTFS with chkdsk (and on Linux)
On Windows, chkdsk is the NTFS repair tool. /f fixes file-system errors and /r additionally locates bad sectors and recovers readable information — but /r includes a full surface scan and can take many hours on a large drive. The drive must be offline for the check, so Windows schedules it for the next restart. On Linux, full NTFS repair is more limited; ntfsfix can clear a "dirty" flag and some inconsistencies but is not a full check, so for serious NTFS problems the reliable path is to check it from Windows.
The same caution as with any repair applies: if this drive is also showing hardware signs, back it up before running /r, because a long surface scan on a failing drive is a lot of stress.
chkdsk D: /f # fix filesystem errors (reboots)
chkdsk D: /r # also scan for bad sectors (slow)
:: Linux (limited):
sudo ntfsfix /dev/sdX1Verify: chkdsk reports no remaining errors and the drive behaves normally. Prevent: eject/unmount NTFS drives cleanly on every OS you use them on.
When a repair might make things worse
Repair tools assume the disk underneath is trustworthy. When it isn't, that assumption is exactly what goes wrong: an aggressive auto-fix reads and rewrites metadata across a drive that has bad sectors, and every pass risks knocking out more. The result can be a drive that was 80% recoverable becoming 20%. This is the single most common way people make a bad storage situation irreversible.
So the decision rule is simple and worth memorising: if the data matters and the drive shows any hardware warning, you image it before you repair it. A repair on a clean copy of the data is always safe; a repair on the only copy of at-risk data is a gamble.
Stop and image first if: the drive has I/O errors, repeated SMART warnings, a failing self-test, or unusual noises. Safe to repair directly if: the drive is healthy, the corruption looks purely logical (a crash, an unclean unmount), and you have a backup.
The goal of repair is to make a drive usable again — not to gamble the only copy of your data to do it. See imaging a failing drive.
Partition and volume problems
5 guidesPartition problems sit one layer below filesystems. The partition table is the disk's table of contents — it says where each slice begins and ends — and when it's damaged or mismatched, you get strange results: a disk that's detected but shows no partitions, a partition that exists but refuses to mount, or a drive that reports less space than it should. These are often scaring people far more than they need to, because the data is frequently still there even when the table that describes it is gone.
The unifying theme is that partition work is where "I'll just fix it" becomes "I just erased everything", because the tools that fix partition tables can also obliterate them. The guides here explain the two table formats, walk through the specific failure modes, and are explicit about which steps are read-only and which are destructive — and why a damaged partition table is usually a "back up / recover" situation, not a "repartition" one.
Partition tables explained: MBR and GPT
Every disk uses one of two partition-table schemes. MBR (Master Boot Record) is the older one: it caps a disk at 2 TB and holds four primary partitions. GPT (GUID Partition Table) is the modern one: it handles huge disks, holds many partitions, and is what UEFI booting expects. The two are not interchangeable on the same disk, and mixing them up is a common source of "my partition won't be created" or "my big disk only shows 2 TB" problems.
Knowing which one a disk uses tells you what's possible and helps you read other guides. Converting between them is a real operation that wipes the disk, so it's not something to do casually — and it's a good reminder to back up first.
| MBR | GPT | |
|---|---|---|
| Max disk size | 2 TB | Very large |
| Partitions | 4 primary | Many |
| Boot style | Legacy BIOS | UEFI |
| Redundancy | Single copy | Backup copies |
Prevent: default to GPT for new installations and for any disk over 2 TB. See partition types.
A partition that exists but won't mount
If the partition shows up in the disk list but mounting fails, the problem is usually one of four things: the filesystem type is unknown or unsupported, the filesystem is damaged, the permissions/ownership are wrong, or there's simply no valid mount point. The partition existing is good news — it means the table is intact and the data region is addressable.
Read the filesystem type first. If the OS can't name a type, it can't mount it, and the answer is either the right driver/tool for that type or a damaged filesystem signature. Then attempt a read-only mount and read the exact error, which narrows it further.
lsblk -f /dev/sdX
sudo mount -o ro /dev/sdX1 /mnt/inspect
dmesg | tail -n 20Verify: a read-only mount lists your files. Prevent: keep the filesystem type known and the drive cleanly unmounted. See decode mount errors for the specific messages.
A lost or damaged partition table
Sometimes the disk is detected at full size but shows no partitions at all — the table of contents is gone even though the book (your data) is still on the shelf. This can happen from a failed repartitioning attempt, a bad write to the table area, or disk failure corrupting that specific region. Crucially, the data is very often still physically present; what's missing is the map.
Because the fix is to reconstruct the map, the golden rule is: do not write to the disk while you investigate. Any new partition, format, or "quick fix" can overwrite the very data you're trying to keep and destroy the clues recovery tools use. The safe order is: image the disk, then attempt recovery (with a partition-recovery tool) on the image, never on the original.
A lost partition table is a data-recovery situation, not a "create a new partition" one. Image first; if the data is critical and you're not experienced, a professional is the faster, safer route.
Verify: on the image, recovery finds the original partitions and files open. Prevent: back up before any repartitioning, and keep the disk's SMART healthy.
Drive capacity smaller than it should be
This one is usually not a fault at all. A "1 TB" drive is 1,000,000,000,000 bytes by the manufacturer (decimal), but the OS reports in 1,000,000,000-byte "gigabytes" (binary), so it shows roughly 931 GB. Add the space taken by the partition table, the filesystem metadata, and any reserved or hidden areas, and the "used but invisible" space is normal.
It only becomes a real problem if the number is wrong in a way the math doesn't explain — for example, a disk that reports a size far below its label, which can point to a partition that doesn't span the whole disk, an MBR 2 TB limit on a bigger drive, or a disk that's partially failed and reporting a reduced size.
Check first: compute the expected binary size for the label; if it's within a few percent, you're fine. If it's far off, check the partition layout and the drive's SMART health.
Partition types and when to change them
Each partition carries a type flag that tells the OS how to treat it: an EFI System Partition, a Linux filesystem, a swap partition, an LVM physical volume, and so on. The type is a hint, and a wrong or missing type is why a valid partition might be ignored or mis-handled. Changing a type is a small edit with a big blast radius: set it wrong and you can make a boot partition unbootable or mark data as something the OS won't touch.
Change a type only when you know exactly what the partition is for and what it should become. On a GPT disk this is a flag edit; the data on the partition isn't moved, but the operation is still best done with a backup present, and it's the kind of edit to do deliberately rather than experimentally.
Partition-table and type operations can make a system unbootable. Take a clone or backup before changing types, and know how you'd restore it.
Slow storage and performance problems
6 guides"Slow" is the least precise word in storage troubleshooting, because a drive can be slow for reasons that are completely unrelated to each other: it's genuinely degraded, it's simply full, it's an old HDD doing what old HDDs do, it's being throttled to save battery, or the slowness is in software (swap, an antivirus scanning every read, a bad driver) and the disk is fine. These guides exist to separate those, because the fix for each is different and only one of them is "replace the drive".
The recurring mistake is equating "disk usage at 100%" with "disk is dying". A busy disk and a slow disk are different measurements, and a healthy drive under heavy load will also peg its usage. The guides here teach you to measure properly, to tell read slowness from write slowness, to benchmark safely (including which write tests are destructive), and to recognise the cases where the real bottleneck is power, software, or heat rather than the storage itself.
High disk usage and what it really measures
"Disk at 100%" usually means utilization — the drive was busy the entire sampling period — not that it's failing or even slow in throughput. A healthy drive copying a large file, running a backup, indexing, or swapping will show 100% and be perfectly fine. So the number alone can't tell you health from load; you need to know what is using it and how fast it's actually moving data.
Look at who and how fast. A per-process view tells you the cause (a backup, an indexer, a sync client), and a throughput view tells you whether the speed is actually poor for the drive type. A spinning HDD doing 80–150 MB/s sequential is normal; the same number from an NVMe is suspicious.
iotop -oP # which processes are using I/O
iostat -xz 2 # per-device throughput and utilizationVerify: you can name the process and the speed is reasonable for the drive. Prevent: schedule heavy jobs (backups, updates) away from when you need the machine. See benchmarking for expected speeds.
Slow reads vs slow writes: the direction matters
Noticing whether the pain is on reads or on writes is a fast diagnostic, because the usual causes differ. Slow reads often point to the media or the path — bad sectors that force retries, a failing drive, a loose connection, or (on HDDs) fragmentation of the files being read. Slow writes more often point to the filesystem or capacity — a nearly full drive, write-caching disabled, a full journal, or a filesystem working hard to stay consistent.
Reproduce it deliberately: copy a large file to the drive and time it, then copy a large file from the drive and time it. Whichever direction is poor is the one to investigate, and it immediately halves the list of suspects.
If reads are slow: check health and the connection; on HDDs, consider the file layout. If writes are slow: check free space (df -h), inodes (df -i), and whether the drive is also showing errors. See safe benchmarks.
Measuring real disk speed, safely
Getting a real number beats guessing, but the tools split cleanly into safe and not. A read benchmark is always safe — it only reads. A write benchmark writes real data, so it must target a scratch file you don't mind destroying, never a partition with data on it. The classic dd read test is harmless; the classic dd write test to a device path is a formatting-grade operation in disguise.
For a proper, controllable test, a tool like fio lets you specify size, block size, and read/write mode without ambiguity. A quick dd read of a large existing file is a fine informal check.
# SAFE: read a large existing file
dd if=/bigfile of=/dev/null bs=1M count=1024
# SAFE: controlled test to a scratch file
fio --name=t --filename=/scratch.tmp --rw=read --bs=1M --size=512M
# RISKY: writing to a DEVICE erases it — never point this at real data
# dd if=/dev/zero of=/dev/sdX bs=1M # DO NOT RUN on a data diskThe write test at the bottom is shown so you recognise it and avoid it. Writing to /dev/sdX (the disk, not a file) destroys everything on it.
Verify: compare your number against the drive type's expectation. Prevent: always benchmark to a scratch file, never a mounted data partition.
Slow storage under battery power on a laptop
A drive that's slow on battery but fine when plugged in is usually power management, not a failing disk. Laptops actively save power when unplugged: they can reduce performance, and they may power down USB ports or put attached drives to sleep (selective suspend), which makes an external drive feel slow or unresponsive until it's woken.
The quick test is the most informative thing you can do: run the same task plugged in and on battery and compare. If it's dramatically faster plugged in, the "slowness" is by design. On macOS, check the battery/power settings and whether the drive keeps waking; on any laptop, a powered USB hub sidesteps the port-power-down behaviour for external drives.
Diagnose: compare plugged-in vs battery; check power settings; try a powered hub for external drives. Verify: speed matches when power isn't the constraint. Prevent: don't diagnose a "failing" drive while it's being throttled for battery life — see NVMe thermals for the heat angle.
A drive that's slow only for specific files or under load
When slowness is patchy — some files fine, some crawling — the cause is usually local to those files or to a resource that only runs out under certain conditions. On HDDs, fragmentation means a large or heavily-edited file is scattered across the platter and takes longer to gather. A drive low on inodes (the records that describe files, distinct from free space) can be "full" of files even with free bytes, and it will slow or fail in odd ways. An antivirus or indexer that scans specific file types can also make only those operations feel slow.
Check the things that only run out in specific situations: free inodes as well as free space, whether the slow files are large or many-small, and whether a scanner is attached to those paths.
df -h /mnt/data # free bytes
df -i /mnt/data # free inodes
du -sh /mnt/data/* # what is using the spaceVerify: you've found the specific constraint (fragmentation, inodes, a scanner). Prevent: monitor inodes on drives that hold many small files. See read vs write.
When slow storage is a software problem, not a hardware one
Before concluding a slow drive is failing, rule out the software layers that sit on top of it and can make a perfectly healthy disk feel terrible. The usual culprits: heavy swapping (the system is using the disk as overflow memory because RAM is exhausted), a real-time scanner intercepting every read/write, a search indexer running constantly, a faulty or mismatched storage driver, or thermal throttling of the whole platform capping the drive's controller.
The tell is that the drive's own health is clean. If SMART is passing, there are no I/O errors, and the drive is the same speed in a clean environment (a live USB install, or a minimal boot), the slowness is almost certainly one of the software layers — and the fix is to address that layer, not to replace hardware.
Diagnose in order: check memory/swap → check for scanners/indexers → test from a clean environment → check temperatures. Verify: the drive is fast with the suspect layer disabled. Prevent: keep an eye on swap and background services.
What SMART is and how to read it
SMART (Self-Monitoring, Analysis and Reporting Technology) is a suite of health sensors built into the drive itself. It continuously tracks things like how many sectors the drive has had to remap, how many are waiting to be remapped, spin-up retries, temperature, and — on SSDs — wear level and available spare. Reading it is the single most valuable thing you can do before touching a drive, because it separates "slow but healthy" from "slow and dying".
The headline is an overall status (passing/failing) plus a table of attributes. Don't try to memorise the attributes now; learn the overall status first, then look up the specific ones that matter (covered next). The command is read-only and completely safe.
sudo smartctl -a /dev/sdX
sudo smartctl -H /dev/sdX # just the overall health lineVerify: "SMART overall-health self-assessment test: PASSED" is the green light. Prevent: check SMART regularly (see a repeatable health check).
SMART, health and hardware diagnostics
6 guidesThis category is where you stop guessing and start reading the drive's own report card. A drive tells you a great deal about itself through SMART, and learning to read even a little of it changes how you handle every other problem in this series. A drive with clean SMART and a flaky cable is a different case from a drive with climbing remapped sectors — same symptoms, opposite fixes.
The goal is calibration, not alarm. SMART has a small number of attributes that genuinely predict failure, and a long tail of numbers that are just information. The guides here teach you the overall status, the handful of attributes worth acting on, how to run self-tests, how to tell a failing drive from a failing connection, and the specific warning signs that mean "stop and back up now". None of it is destructive — it's all read-only, which is exactly how you want health checks to be.
The SMART attributes that actually matter
Most SMART attributes are noise for troubleshooting; a few are signal. The ones worth learning are the ones that describe media degradation, because they're the ones that predict data loss. The rest (power-on hours, temperature history, etc.) help you understand the drive but rarely tell you it's about to fail.
| Attribute | What it means | Concern when… |
|---|---|---|
| Reallocated_Sector_Ct | Sectors remapped over bad ones | Non-zero and rising |
| Current_Pending_Sector | Sectors waiting to be remapped | Non-zero |
| Offline_Uncorrectable | Sectors that couldn't be read at all | Non-zero |
| Spin_Retry_Count | Times the platter needed a spin retry | Non-zero and rising |
| Wear_Leveling_Count / Available_Spare | SSD remaining endurance | Spare dropping toward threshold |
Verify: the "concern" attributes are all zero (or, for SSD spare, comfortably above threshold). Prevent: a non-zero pending/uncorrectable count is your cue to back up now.
"Warning" vs "failed": interpreting the SMART status
The overall status is the drive's own verdict, and it's worth trusting. "PASSED" means the drive sees no attribute that has crossed a failure threshold — it doesn't guarantee the drive is perfect, but it means nothing is (yet) at the danger line. "FAILED" means at least one pre-failure attribute has crossed that line and the drive is telling you it's going; back up and plan replacement. "UNKNOWN" usually means the drive doesn't support the self-assessment, so you fall back to reading the individual attributes yourself.
Also note the attribute type: attributes marked "Pre-fail" are the ones that predict failure and trigger the overall status; "Old age" attributes just describe wear over time. A climbing pre-fail attribute is the early warning you want to catch.
Verify: you can read the status line and the type of any concerning attribute. Prevent: treat any "FAILED" or climbing pre-fail attribute as a backup trigger immediately.
Running self-tests (short and extended)
A self-test is the drive testing its own media and mechanics on demand. The short test is a quick sample (minutes); the extended/long test is a thorough surface scan that can take hours on a large drive. They're read-only and safe, and they're the best way to actively probe a drive that's giving you vague unease but a clean at-a-glance SMART read.
Start with the short test; if you need confidence and have the time, run the extended one. Check the results in the self-test log afterwards — a completed "OK" is reassuring, and any logged failure is a concrete reason to back up and investigate.
sudo smartctl -t short /dev/sdX # quick
sudo smartctl -t long /dev/sdX # thorough, takes hours
sudo smartctl -l selftest /dev/sdX # read the resultsVerify: the log shows the test "completed without error". Prevent: run an extended test after any suspicious event. See failing vs flaky.
A failing drive vs a flaky connection
A drive that intermittently drops, errors, or slows can be dying — or it can be perfectly healthy behind a bad cable, a weak port, or a power-starved connection. The two look similar from the outside but have completely different fixes, so it's worth spending ten minutes telling them apart before you replace (or send off) a good drive.
The discriminators: a healthy SMART with a clean self-test argues against the drive; errors that follow the device at the controller/port level (link resets, the port complaining) argue for the connection. The cleanest test is physical: move the drive to a known-good port with a known-good cable and a known-good power source, and see whether the behaviour follows the drive or stays with the old location.
Diagnose: read SMART + self-test (drive health) and the controller/port lines in the log (connection health), then do the swap test. Verify: the problem either moves with the drive (drive) or stays with the location (connection). See isolating the three for the full method.
Warning signs of a drive that's about to fail
Drives rarely fail with no warning. The ones that are degrading usually announce it in one or more of these ways: SMART attributes climbing (reallocated/pending sectors), a "FAILED" overall status, I/O errors in the log, new slowness or stutters, a drive that drops offline, or — on HDDs — new sounds like clicking, grinding, or repeated spinning-up. Any one of these is worth taking seriously; several together is a "back up today" situation.
The single most important response to any of these is not a repair — it's a backup or image. A drive can be showing early warnings and still be perfectly usable for copying its data out. Once it's copied to safety, you can take your time diagnosing or replacing it. That order (protect first, diagnose second) is the whole game.
sudo smartctl -H /dev/sdX # overall status
sudo smartctl -a /dev/sdX | grep -iE "realloc|pending|uncorrect|spin"
dmesg | grep -iE "error|I/O|sector"If any of these are present, stop and back up / image now before doing anything else.
An external drive that is detected but not mounted
External drives add two failure layers on top of a normal drive: the enclosure/bridge (the USB-to-SATA or USB-to-NVMe converter inside the case) and power. So "detected but not mounted" on an external drive can mean the disk is fine but the bridge isn't presenting it properly, or the filesystem on it isn't supported by this OS, or it needs more power than the port is giving.
Work the layers: confirm the OS sees a disk device (not just a USB connection), check the filesystem type it's reporting, then try a manual read-only mount. If the OS sees the USB connection but no disk device, the bridge or power is the likely culprit rather than the drive.
lsblk -f # is there a /dev/sdX with a filesystem?
lsusb # is the USB device enumerated?
dmesg | tail -n 25 # what happened when you plugged it inVerify: a disk device appears and a read-only mount lists files. Prevent: use a powered hub for larger externals and keep the filesystem one this OS supports (see shared-drive formats).
An external drive that keeps disconnecting
Repeated disconnects on an external drive are almost always one of three things: not enough power, a marginal cable or port, or (less often) the drive or its bridge degrading. The pattern is your clue — drops under load or when the drive spins up point to power; drops that log USB reset/port errors point to the cable or port; drops that coincide with the drive's SMART worsening point to the drive.
Catch the events in the log at the moment they happen; the kernel records USB resets and disconnections with the device, which tells you whether the OS is seeing a connection problem (good — that's fixable) or a drive problem (back up).
dmesg -w # watch, then reproduce
dmesg | grep -iE "usb|reset|disconnect|sd"Diagnose: try a powered hub, a shorter/better cable, and a rear port; check the log for resets; check the drive's SMART. Verify: no more resets after the change. Prevent: power larger externals properly. See USB power.
External, USB and removable storage
6 guidesExternal and removable drives fail in ways internal ones don't, because they carry their own little system — a bridge, a cable, a power path, and often a filesystem chosen for compatibility rather than robustness. A lot of "my external drive is broken" turns out to be a power problem, a bridge problem, or a filesystem the current OS can't write to. The good news is that these are usually the cheapest things to fix and the least likely to have damaged your data.
The theme of this category is to stop blaming the disk before you've checked the path. External drives are where the "swap test" pays off most: the same drive in a different port, cable, or computer immediately tells you whether the problem travels with the drive or stays with the setup. These guides also cover the practical side of drives that move between Windows and Mac — because the filesystem you chose years ago is very often the reason a drive behaves differently today.
USB power problems
Not all USB ports deliver the same power, and a 3.5-inch drive (or a bus-powered 2.5-inch one under load) can simply not get enough through a weak source. The classic signs: a drive that works on one port but not another, that connects then drops, or that's fine on a desktop rear port but struggles on a laptop or a front panel. Front-panel ports and unpowered hubs are the usual weak points.
The fixes are physical and cheap: use a rear motherboard port, use a shorter and better cable, or — most reliably for larger drives — use a powered USB hub or the drive's own power adapter. If a drive is designed to take external power and you're running it without, that's your problem.
Diagnose: move the drive to a rear port; add a powered hub; use the included power brick. Verify: the drive stays connected under load. Prevent: power hungry externals properly from the start. See keeps disconnecting.
A drive that is fine on one computer but not another
If a drive works on machine A and not machine B, the drive is very probably fine — the difference is in the machines. The most common reasons are filesystem support (a drive formatted for one OS may be read-only or invisible to another), a missing driver on B, a power difference between the two setups, or a port/cable issue on B. This is one of the most reassuring diagnoses you can reach, because it points away from the disk.
Compare the two situations directly: what filesystem is on the drive, does B support it read and write, and does B give it enough power? A drive that's NTFS will often be read-only on a Linux box; a drive that's APFS won't be writable on Windows at all. That's the drive working as designed, not failing.
Diagnose: identify the filesystem, check B's support and power, try a different port/cable on B. Verify: the drive behaves the same on both once the difference is removed. See format choice.
Filesystem choice for drives shared between Windows and Mac
The filesystem on a shared drive determines which computers can read and write it, and it's the root of many "works on one, not the other" problems. The practical options: exFAT is the modern cross-platform choice (read/write on Windows and macOS, large files, no 4 GB limit). FAT32 is universally supported but caps files at 4 GB. NTFS is great on Windows but typically read-only on macOS without extra software. APFS and ext4 are single-ecosystem and won't be writable on the other OS.
So the "right" format depends on which machines the drive must move between. If it's Windows+Mac, exFAT is the low-drama default. If it's Mac-only, APFS. If it's a Linux backup target that never needs to be portable, ext4 (or Btrfs) with all the features you want. Picking deliberately now saves a lot of "why won't this mount" later.
| Filesystem | Windows | macOS | Notes |
|---|---|---|---|
| exFAT | R/W | R/W | Best general cross-platform; large files OK |
| FAT32 | R/W | R/W | Universal; 4 GB file limit |
| NTFS | R/W | R (W w/ extra) | Windows-native; limited on Mac |
| APFS | No | R/W | macOS-native |
| ext4 | R (w/ extra) | R (w/ extra) | Linux-native; feature-rich |
Prevent: choose the format for the machines the drive will actually visit. See works on one not the other.
When the card reader or USB hub is the real problem
Before you conclude a drive is bad, remember the drive is only one part of the chain: for an external it's also the bridge and the case, and for a card it's the reader. A failing or cheap reader, a worn USB hub, or a flaky adapter can produce exactly the symptoms of a failing drive — drops, errors, slowness — while the storage itself is completely healthy. This is the cheapest thing to rule out and the most commonly overlooked.
The test is the swap: put the drive (or card) in a different reader, a different hub, or directly into the computer, bypassing the middleman. If the problem disappears, you've found your culprit and it's not the drive. If the problem follows the drive to a known-good reader and port, then the drive is the one to investigate.
Diagnose: try the drive in a different reader/hub/port, and try a known-good drive in the same reader. Verify: the fault is isolated to one component. Prevent: use quality hubs and readers, and power them. See USB power and the full isolation method.
HDD-specific failure patterns
Hard drives fail mechanically, and the failure modes have character. A repeating click or tap (the so-called "click of death") usually means the read/write heads can't find their position — a serious heads-on-platter problem. Grinding or scraping suggests bearing wear. A drive that spins up, pauses, and retries points to the platter or the actuator struggling. Seek errors and rising remapped sectors in SMART are the software-visible shadow of these physical problems.
The critical rule with a making-noise drive is: power it off and stop spinning it. Every minute a clicking drive spins, the heads may be doing more damage to the platter, and you're burning the window in which the data is recoverable. A silent, powered-down drive holds its data far better than a clicking one does. From the powered-down state, the move is to image it (see next) or, if it's clicking, to a professional — not to keep rebooting it and hoping.
New, unusual noises + a drive with data = power down, then image or send to a professional. Don't run it "one more time".
SSD-specific problems
SSDs have no moving parts, so they fail in different ways and give different warnings. The common ones: a drive that slows dramatically when it gets full (there's less free space for the controller's wear-leveling and garbage collection to work with), a drive running out of write endurance (tracked in SMART as wear level / available spare), and controller or firmware issues that can make a healthy drive behave oddly or drop offline. Unlike an HDD, an SSD usually fails more abruptly — less "getting slower for a month" and more "works, then doesn't" — which makes the wear/spare numbers even more important to watch.
For the full-slowdown case the fix is often just free space: keep a healthy SSD from running at 100%. For the endurance case, the SMART spare/wear attributes tell you how much life is left. For controller issues, firmware updates from the manufacturer are the usual remedy, and a drop-offline with a clean SMART often points at the connection or power rather than the NAND.
sudo smartctl -a /dev/nvme0n1 | grep -iE "spare|wear|percentage"
df -h /mnt/ssd # how full is it?Prevent: don't run an SSD full, and keep an eye on the available-spare attribute. See matching the fix to the type.
NVMe problems: thermals and PCIe
NVMe drives are fast and they run hot, and heat is their most common performance problem. When an NVMe exceeds its thermal threshold it throttles — cutting speed to cool down — which looks exactly like "my fast drive is slow". The other NVMe-specific angle is the PCIe connection: a drive in a slot that's sharing lanes, a flaky M.2 contact, or a slot that's negotiating at a lower speed than it should will also cap performance or drop the drive offline.
The tool for both is the NVMe management interface, which reports temperature and health directly from the drive. A temperature consistently at or above the throttling point means the cooling (a heatsink, airflow, or a thermal pad) needs attention. A drive reporting a lower PCIe link than its rating points at the slot or the connection.
sudo nvme smart-log /dev/nvme0
sudo nvme list
sudo lspci -vv | grep -iE "nvme|link status" # negotiated PCIe speed/widthDiagnose: is it hot (cooling) or is the link slow/broken (slot/connection)? Verify: speed recovers once temperature or the link is addressed. Prevent: give NVMe drives a heatsink and good airflow. See slow but healthy.
A drive that fails only in an enclosure
If a drive misbehaves in its enclosure but you've never tested it out of the enclosure, the enclosure's bridge chip is a prime suspect. The little USB-to-SATA (or USB-to-NVMe) bridge is a real component with its own failure modes, and a failing bridge produces drive-like symptoms — no detection, disconnects, errors — while the disk inside is fine. Enclosures are also where power problems hide, since the bridge mediates how much power reaches the drive.
The clean test is to remove the drive from the enclosure and connect it directly (internally, or via a known-good adapter). If the drive is perfectly happy bare, the enclosure or its bridge is your problem, and the data is safe — you've just found a cheap fix. If the problems follow the bare drive, then the disk itself is what's wrong.
Diagnose: test the drive out of the enclosure on a known-good connection. Verify: the drive is stable bare (enclosure fault) or still faulty bare (drive fault). Prevent: keep a spare enclosure/adapter so you can always test bare. See isolation.
SSD, HDD and NVMe-specific problems
5 guidesThe previous category covered external/USB failure; this one is about the drive's own technology, because the three main types — spinning HDDs, SATA/NVMe SSDs, and the enclosures that wrap them — degrade and misbehave in distinct ways. The same symptom ("slow", "drops offline", "errors") means different things on each, and the correct response can be opposite: what's a "back it up, it's dying" sign on an HDD might be a "free up some space" fix on an SSD.
The point of the category is to stop applying one mental model to all storage. HDDs fail mechanically and announce it with sound and remapped sectors; SSDs fail by running out of endurance or via their controller and announce it with wear/spare numbers; NVMe adds thermals and PCIe on top. The guides here build the type-specific instincts, and the final guide pulls it together into a quick "given the type, where do I look first" reference.
Matching the fix to the drive type
This is the synthesis of the category: given the symptom and the drive type, where do you look first? The value is in avoiding the wrong reflex — reaching for "replace the drive" when it's an SSD that's just full, or "free up space" when it's an HDD that's mechanically failing. The table is a starting heuristic, not a rule, but it keeps you in the right neighbourhood fast.
| Type | Typical failure | Look here first |
|---|---|---|
| HDD | Mechanical wear, bad sectors | Noises + SMART realloc/pending → back up |
| SSD | Full-drive slowdown, endurance, controller | Free space + wear/spare + firmware |
| NVMe | Thermals, PCIe link | Temperature + negotiated PCIe speed |
| External (any) | Bridge, power, cable | Test bare; powered hub; known-good cable |
Verify: the type-appropriate check either explains the symptom or clears that type. Prevent: know which type you have before you start, so the right checks come first. See the individual guides: HDD · SSD · NVMe.
"Permission denied" when accessing a drive
"Permission denied" on a drive that's clearly there is almost never about the drive failing — it's about who's asking and what the mount allowed. The usual causes: you're not running as the user the mount expects, the filesystem was mounted with options that restrict your user, the files' ownership doesn't include you, or a mandatory-access system (SELinux/AppArmor) is blocking access. None of these are data-loss events; they're access-control events, and they're very fixable.
Read the situation before changing it: who are you (id), how is the drive mounted (its options), and who owns the files on it (ls -l). That trio tells you which of the four causes you're dealing with.
id
findmnt -o TARGET,SOURCE,OPTIONS /mnt/data
ls -ld /mnt/data
ls -l /mnt/data | headVerify: you can read the drive as the intended user. Prevent: mount with the ownership you expect (see mounting with permissions). See ownership after moving a drive.
Ownership and permissions after moving a drive
Move a drive from one Linux machine (or user) to another and the files often arrive owned by a numeric user ID that doesn't exist here — so they look owned by "uid 1001" and you can't touch them. This is normal: Unix permissions are stored as IDs, and a different machine has a different ID-to-name map. The same drive can look "locked" on the new machine even though nothing is wrong with it.
The temptation is a mass chown of the whole drive, which works but is heavy-handed and can be surprising (it rewrites ownership of everything, and on a large drive takes a long time). Often the cleaner fix is at the mount level — mounting with the right uid/gid — or adding an ACL for the specific folder you need, rather than re-owning the entire volume.
A whole-drive chown -R is slow and changes more than you might intend. Prefer mount options or a targeted ACL; if you do re-own, do it on a copy or a drive you fully understand first.
Permissions, ownership and access problems
5 guidesAccess problems are the storage issues that look alarming but almost never threaten the data. A drive you can't open because of permissions, ownership, or a mandatory-access policy is a door that's locked, not a house that's burned down. The data behind the door is typically intact; the problem is that the current user, mount, or policy isn't allowed through it.
This category matters because the wrong response to an access problem is often a destructive one — people who can't read a drive sometimes reformat it or "fix" it with a tool, destroying perfectly good data to solve a permissions question. The guides here walk through the specific access failure modes, how to read what's actually blocking you, how to mount with the ownership you want, and how permissions behave (and don't) when a drive crosses between systems with different models. The through-line: diagnose the lock before you break the door down.
Mounting a drive with the right permissions
Many filesystems (especially FAT/exFAT/NTFS as seen from Linux) don't store Unix ownership, so the mount is where you decide who the files appear as and how permissive they are. That's controlled by mount options: uid and gid set the apparent owner/group, and umask sets the default permissions. Getting these right at mount time is usually cleaner than re-owning files afterwards, because it's reversible and doesn't touch the data.
Start permissive enough to work, then tighten. A common default for a personal external drive is to assign it to your user and group with a sensible mask, so your files are yours without making the drive world-writable.
id -u; id -g # your uid and gid
sudo mount -o uid=1000,gid=1000,umask=022 /dev/sdX1 /mnt/data
findmnt -o TARGET,OPTIONS /mnt/dataVerify: files show your user as owner and you can create/delete as expected. Prevent: put these options in /etc/fstab so they survive reboots. See permission denied.
A drive that is visible but empty or inaccessible
"I can see the drive but it's empty" has a short list of real causes, and none of them usually mean the data is gone. The mount may be pointing at the wrong partition (the empty one) while your data is on a sibling partition; the files may be hidden (dotfiles on Unix, system/hidden attributes on Windows); the filesystem may have mounted but failed to expose its tree; or an exFAT/NTFS quirk may be hiding files from this OS. The data is very often one partition or one flag away.
Check the obvious before the scary: are you looking at the right partition, are hidden files shown, and does the filesystem report a sensible file count? If the "empty" partition is genuinely empty and there's a sibling partition with your data, you've just been looking at the wrong one.
lsblk -f /dev/sdX # which partitions exist?
findmnt /mnt/data # which partition is mounted here?
ls -la /mnt/data # show hidden files
ls /mnt/data | wc -l # how many entries are there?Verify: you're on the right partition and hidden files are visible. Prevent: confirm the mount source before assuming a drive is empty. See mount points.
Accessing a drive across different permission models
Unix permissions and NTFS access-control lists are fundamentally different models, and a drive that moves between them has to be translated — imperfectly. NTFS stores rich per-user ACLs; a Unix mount of NTFS has to flatten that into uid/gid/mode, and something is always lost in the mapping. The result is that a drive can be perfectly accessible on the machine that wrote it and oddly restricted (or oddly permissive) on the other. This is a modelling problem, not a failure.
The practical guidance: don't try to make one drive's permissions mean the same thing on both models, and be very wary of "just make it 777" as a fix — world-writable is a security hole, not a solution. Instead, decide which OS is the drive's "home" and optimise for that one, accepting that the other OS gets a reasonable but approximate view. For shared data, a cross-platform filesystem like exFAT sidesteps the model mismatch entirely (at the cost of advanced permission features).
Choosing exFAT for a drive that must move between Windows and Unix avoids most permission-model pain — see format choice.
Data recovery and safe repair
5 guidesThis is the category where the stakes are highest and the discipline matters most, because the actions here either preserve or permanently destroy your only copy of data. The single most important idea in the whole series lives here: when the data matters and the drive is at risk, you work on a copy, never on the original. Every other piece of recovery wisdom flows from that one rule.
The guides are ordered the way a real incident goes: what to do in the first ten minutes (stop, don't write, image), how to make that image safely — and why a naive copy tool can make a failing drive worse — how to use a recovery-oriented imager on a drive with bad areas, what file recovery can and can't realistically do, and the clear line for when the correct and often cheapest action is to stop and hand it to a professional. None of these guides ask you to gamble; several of them are mostly about telling you when not to act.
The first 10 minutes when data is at risk
When you realise a drive with important data is in trouble, the first ten minutes decide how much you can save later. The instincts that cause the most damage are the natural ones: rebooting to "fix" it, running a repair, installing recovery software onto the drive, or keeping using it "just to grab a few files". Each of those writes to the drive, and on a degrading drive every write risks overwriting data you haven't copied yet.
The correct first moves are all about stopping writes and preserving the state. Unmount the drive (or power it down if it's failing noisily). Do not run repairs, do not reformat, do not install anything on it, and do not keep saving to it. Then, if it will still spin and respond, your goal is a complete image or backup to a different disk before you do anything diagnostic. If it's clicking or not responding, power it off and treat it as a professional-recovery situation.
- Stop using the drive; unmount it (or power off if it's failing).
- No repairs, no reformat, no new installs onto it.
- If it still works: image or back it up to another disk first.
- If it's clicking/dead: power off, and consider a professional.
The rule that saves the most data: work on a copy, never the original. Everything else in this category assumes you've done this.
Cloning or imaging before you touch a failing drive
An image (or clone) is a complete copy of the drive you can then work on freely — repair, recover, experiment — without ever risking the original. On a failing drive it's not optional, it's the whole strategy. The catch is that the copying tool matters: a naive block copy that stops at the first unreadable sector will give you a truncated, useless image, and a copy that hammers a bad sector can worsen the damage.
For a healthy drive, a plain block copy is fine. For a failing drive, you want a tool that skips bad areas, records where they are, and retries them later at lower priority — that's the next guide. The point here is to establish the habit and the command shape, and to understand why "just run dd" is the wrong tool for a sick drive.
# Source is the READ (if=), destination is a DIFFERENT disk
sudo dd if=/dev/sdX of=/mnt/backup/disk.img bs=4M conv=noerror,sync status=progress
# For a FAILING drive, use ddrescue instead — see next guide.Double-check if= (source) and of= (destination). Pointing of= at the wrong device overwrites it. The source is only ever read here.
Verify: the image is the same size as the source and you can read files from it. Prevent: always image to a different, healthy disk. See ddrescue for failing drives.
Using ddrescue on a failing drive
ddrescue is the right tool when a normal copy would fail, because it's built for drives with bad areas. Instead of stopping at the first unreadable sector, it grabs everything it can in a fast first pass, records the bad regions in a map file, and then makes repeated, more patient passes over just the bad regions — trying different block sizes — to salvage as much as physically remains. The result is the best possible image of a dying drive, and the map file lets you resume where you left off if you have to stop.
The three arguments are the source, the output image, and the map file. Run it on the original, writing to a different disk, and let it iterate. It's read-only with respect to the source (it never writes back to the drive), which is exactly the safety property you want during recovery.
# source → image, with a map file for the bad regions
sudo ddrescue /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map
# re-run the same command to retry the bad regions more patiently:
sudo ddrescue -d -r3 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.mapVerify: the map shows most of the disk rescued and you can mount/extract files from the image. Prevent: keep ddrescue installed and a spare disk ready, so a rescue isn't delayed. See what recovery is realistic.
File recovery: what is realistic
It's worth setting honest expectations, because "recovery" means very different things in different situations. Recovering a recently deleted file from a healthy drive that hasn't been written to since is often quite feasible — the data is still there, only the pointer to it was removed. Recovering from a drive with heavy bad sectors, or one that's been written to after the loss, is much less certain, and recovering from a mechanically failing drive may require hardware-level work no software can do.
Two rules shape the outcome. First, the less you write to the drive after the loss, the better your odds — which is why the whole "work on a copy" approach pays off. Second, run recovery tools from a different machine or a live environment, and point them at the image, so the tool never writes to the original. Tools in this space (partition-recovery and file-carving utilities) range from "rebuild the lost partition table" to "scrape the disk for recognizable file patterns", and the right one depends on what actually went wrong.
Never install or run recovery software on the drive you're recovering from. Run it from elsewhere, against the image. If the data is critical and the drive is failing, a professional is usually faster and safer than a weekend of software.
When to stop and call a professional
Knowing when you've reached the edge of safe DIY is a skill in itself, and it saves both data and money. The clear "stop and call a professional" signals are: a drive that's clicking or grinding (mechanical failure — every spin risks more damage), a drive that was dropped, spilled on, or exposed to water, a drive that won't even spin up, and — most pragmatically — data that is genuinely irreplaceable and the drive showing any failure signs. In those cases, a cleanroom and the right tools matter, and a "one more try" at home is how recoverable data becomes unrecoverable.
The other honest signal is cost and risk. If the data is worth more than a professional's fee, and the drive is physically failing, paying for proper recovery is usually the rational choice. If the data is backed up, the answer is often simpler: stop, and replace the drive.
- Call a professional if: clicking/grinding noises; no spin-up; physical damage (drop, liquid); or irreplaceable data on a failing drive.
- Stop and replace if: the data is backed up and the drive is failing — no reason to risk the original further.
- Keep doing it yourself if: the drive is healthy and the problem is logical (a crash, permissions, a bad mount).
Advanced storage diagnostics
4 guidesThe earlier categories teach you to read a drive's health and its mount behaviour; this one is about reading the system's own account of what's happening. The kernel log and the filesystem journal are where the operating system writes down, in real time, every storage event it noticed — the resets, the I/O errors, the remounts, the journal replays. Learning to read those logs turns a vague "something's wrong with the disk" into a specific, addressable statement, and it's the bridge between "the drive is acting up" and "the drive's controller dropped it at 14:02 and it's remapping sectors".
These guides are for when the simple checks have pointed somewhere but not told you exactly where. They cover reading the kernel log for storage events, following the filesystem journal for clues about what a repair would do, the classic method for isolating whether the fault is the controller, the cable, or the drive, and a complete repeatable diagnostic workflow that strings the whole series together in the right order. None of it is destructive — it's all about reading before acting.
Reading kernel logs for storage problems
The kernel log is the single richest source of storage information on Linux, and it's read-only to read. Every time the storage subsystem notices something — a device appearing, a link resetting, an I/O error, a filesystem remounting itself — it writes a line here. The skill is less running the command than reading the lines: matching the device, noticing the pattern, and telling the difference between a one-off and a repeating fault.
Watch it live while you reproduce the problem, then grep the history for the device. The patterns that matter are repeats (the same sector, the same reset, over and over) and escalations (errors that start infrequent and get frequent), because those are the signatures of something degrading rather than something that merely hiccupped.
dmesg -w # live
dmesg | grep -iE "sd|nvme|ata|error|reset|I/O"
journalctl -k -p warning | grep -iE "sd|nvme|ata"Verify: you can point to the specific device and the repeating event. Prevent: keep an eye on the log after any scare. See I/O errors for what the messages mean.
Following the filesystem journal for clues
Journaling filesystems (ext4, XFS, and others) keep a journal — a record of recent changes they were in the middle of making — so that after a crash they can either finish or roll back those changes and stay consistent. When a drive comes back after a bad shutdown, the "recovering journal" you see at boot is this in action. Reading what the journal does tells you a lot: a quick, clean replay is normal; a replay that reports errors, or a drive that keeps needing recovery, is a signal that writes are being lost or corrupted.
This is also where you understand a subtle risk: a repair that "replays" or rebuilds journal state on a drive that's physically failing can, like any repair, make things worse if the media underneath is the real problem. So the journal is best read as a diagnostic — it tells you what the filesystem is trying to do — while the decision of whether to let it proceed still depends on the drive's health and whether you've imaged it.
Diagnose: read the journal-recovery lines at boot and in the log; note whether recovery is routine or reporting errors. Verify: clean boots with no journal errors. Prevent: clean shutdowns, and healthy media so the journal has a stable home. See repair ext4.
Isolating controller vs cable vs drive
When a storage problem is intermittent, the fault is somewhere in a triangle: the drive, the cable/connection, or the controller/port. These three produce overlapping symptoms, and the only reliable way to tell them apart is the swap method — changing exactly one variable at a time and watching which way the problem goes. It's systematic, it's fast, and it prevents the very common mistake of replacing a good drive because the cable was the problem (or vice versa).
The method: test a known-good drive in the suspect location (if it also misbehaves, the location — controller/cable/power — is the problem). Then test the suspect drive in a known-good location (if it behaves, the original location was the problem; if it still misbehaves, the drive is the problem). Two clean tests usually pin it down without any guesswork, and they cost nothing but a few minutes and a spare cable or drive.
- Known-good drive + suspect port/cable → faulty? Location is the problem.
- Suspect drive + known-good port/cable → faulty? Drive is the problem.
- Neither swap reproduces it → re-check power and the log (kernel messages).
A systematic storage diagnostic workflow
Everything in this series fits one order, and running it in that order is what separates a calm diagnosis from a scramble. The logic is always the same: confirm presence, identify the object, check its health, read the logs, test the connection, and only then touch the filesystem — because each step either solves the problem or safely narrows it, and the expensive/risky steps are deliberately last.
Keep this as your default path whenever storage misbehaves. It's also the shape of the repeatable health check you can run periodically, so a slow degradation is caught while it's still cheap.
- Detect — is the disk present? Not seen at all
- Identify — name the disk, partition, and UUID. Device names · UUID
- Health — read SMART and run a self-test. SMART · Self-tests
- Logs — read the kernel log for the device. Kernel logs
- Connection — swap-test controller/cable/drive. Isolate the three
- Filesystem — only now, mount read-only and, if needed, check/repair. Mounting · Repair
- Protect — back up / image before any risk. Image first
Prevention, maintenance and backup
5 guidesThe best storage troubleshooting is the kind you never have to do, and that's a function of three habits: a backup strategy that means no single drive is irreplaceable, a light maintenance routine that catches degradation early, and safe ways of moving and upgrading drives so that routine changes don't become data-loss events. This category is the payoff for everything earlier — once you can read health and isolate faults, these habits turn "hope it doesn't fail" into "if it fails, it's no big deal".
The theme is that prevention is cheap and recovery is expensive, and the gap between the two is enormous. A half-hour of backing up now is worth a great deal more than a weekend of recovery later. The guides cover the 3‑2‑1 backup model, a realistic maintenance schedule, safe habits for swapping and upgrading drives, cloning a healthy drive as a first-line backup, and a single repeatable "storage health check" you can run on a schedule so that the warning signs from category 6 are caught while they're still warnings.
A backup strategy that actually protects your data (3‑2‑1)
The 3‑2‑1 rule is the standard for a reason: keep three copies of your data, on two different types of media, with one copy offsite. It's designed so that no single event — a failed drive, a fire, a theft, a ransomware wipe — can take everything. A single external "backup" drive is not a backup by this standard, because it's one copy, one media type, and usually in the same room as the original; if the original fails or the room burns, you have nothing.
The practical version for most people: your working drive (copy 1), a local backup drive or NAS (copy 2, different media), and an offsite copy — a second external drive kept elsewhere, or a reputable cloud service (copy 3, offsite). Automate the local one so it happens without you thinking about it, and test that you can actually restore from it, because an untested backup is a hope, not a backup.
Verify: you can restore a known file from each copy. Prevent: automate and schedule; a backup you have to remember is a backup that doesn't happen. See cloning a healthy drive for the local copy.
A routine maintenance schedule for storage
Storage degrades gradually, and a light, regular check catches it while it's still a warning instead of a crisis. You don't need to do much, or often — the value is in consistency. A monthly glance at health and space, and a quarterly deeper pass, is enough for most people to catch a failing drive months before it fails and to avoid the "drive is full" surprises.
Keep it to a short, repeatable list so it actually happens. The checks are all read-only and quick: read the overall SMART status, glance at the key wear attributes, confirm there's free space (and inodes), and confirm your last backup succeeded. If anything looks off, that's your cue to go deeper with the rest of the series.
- Monthly: SMART overall status (read SMART); free space and inodes; last backup OK?
- Quarterly: the key wear attributes (attributes); a short self-test (self-tests); restore-test one file from backup.
- Anytime it feels off: run the full diagnostic workflow.
Safe habits for moving and upgrading drives
Most "I lost everything" stories that aren't about failure are about an upgrade or a move gone wrong — a drive swapped without a copy, a partition edited on the wrong disk, a new drive assumed to be empty when it wasn't. The habits that prevent these are simple and cheap: verify before you act, copy before you move, and label your drives so you never have to guess which is which.
Concretely: before swapping or upgrading, make a copy or image of the drive you're about to touch, and verify it. Label each physical drive with its contents and role. When connecting a new drive, confirm the OS sees it as empty (or as whatever you expect) before you write to it. And keep the "work on a copy, name the level you mean" rules from earlier — they're exactly what makes these operations safe.
Prevent: copy/image before you swap; label drives; verify a new drive is empty before writing. See cloning a healthy drive and name the level you mean.
Cloning a healthy drive as your first backup
A clone of a healthy drive is the fastest first line of protection, and it's different from a backup in a way worth understanding. A clone (or a full image) is a one-to-one copy of the whole drive — bootable, complete, restorable to identical state — which makes it perfect for "I'm about to do something risky, give me a way back." A file-level backup is better for ongoing protection and for recovering individual files over time. Use the clone for the moment before a risky operation, and the ongoing backup for everything else.
For a healthy drive, a plain block copy is reliable and simple; for just the data, a file-level copy with verification is lighter. Whatever you choose, the non-negotiable is verification — a clone you haven't confirmed is a clone you don't have. Check the size matches and, better, confirm you can actually read (or boot) from the copy.
# whole-disk clone (source read-only), then verify size
sudo dd if=/dev/sdX of=/mnt/backup/clone.img bs=4M status=progress
ls -l /dev/sdX /mnt/backup/clone.img # sizes should match
# data-only, with verification:
rsync -a --info=progress2 /mnt/data/ /mnt/backup/data/Verify: sizes match and you can read from the copy. Prevent: clone before any risky operation, on top of your ongoing 3‑2‑1 backup. See imaging.
Building a "storage health check" you can repeat
This is the whole series compressed into one thing you can run on a schedule and read in a minute. The idea is a fixed, short sequence of read-only checks with a fixed "what good looks like", so that when something changes you notice immediately instead of discovering it during a crisis. Run it monthly or quarterly; the goal is a wall of "all good" with an occasional "wait, that's new" that you can act on early.
Keep the commands identical each time — that's what makes the comparison meaningful. If a number that was zero now isn't, or a "PASSED" is now "FAILED", or a drive that was fast is now slow, that delta is your early warning, and the rest of the series is what you do next.
for d in /dev/sda /dev/nvme0n1; do
echo "== $d =="
sudo smartctl -H "$d" | grep -i "overall"
sudo smartctl -a "$d" | grep -iE "realloc|pending|uncorrect|spin|spare|wear"
dmesg | grep -iE "$(basename $d)" | grep -iE "error|I/O|reset" | tail -n 5
done
df -h; df -i # space and inodes- Overall status: PASSED on every drive.
- Realloc / pending / uncorrect / spin: zero.
- SSD spare/wear: comfortably above threshold.
- No new error lines for any device in the log.
- Free space and inodes: healthy headroom.
Prevent: run it on a schedule and keep the history, so change is obvious. See maintenance schedule and the full workflow.