Linux Storage Troubleshooting becomes much easier when you first determine whether the problem is with the physical drive, partition table, filesystem, or mount configuration. A disk that disappears completely needs a very different fix from a partition that exists but refuses to mount.
Linux storage problems can range from simple /etc/fstab mistakes and full filesystems to USB disconnects, filesystem errors, SSD/NVMe issues, or damaged partition tables. The safest approach is to identify which storage layer is failing before running repair commands.
This guide walks through practical checks for missing disks, mount errors, partition problems, filesystem issues, full drives, external storage, and SSD/NVMe errors while helping you avoid changes that could put important data at risk.
The most important rule with storage troubleshooting is to diagnose before repairing.
Protect the data first: If a disk is making unusual noises, repeatedly disconnecting, reporting serious I/O errors, or contains irreplaceable files, minimize writes and make a backup or recovery image before running repair tools.
Quick Diagnosis: Start With What Linux Can See
| Symptom | Check first |
|---|---|
| Disk missing completely | Firmware/connection, lsblk, kernel log |
| Disk appears but partition is missing | Partition table, fdisk/parted |
| Partition exists but will not mount | Filesystem, mount error, permissions |
| System boots slowly after adding a disk | /etc/fstab, missing UUID/device |
| “No space left on device” | df -h, df -i |
| External drive disconnects | Cable, USB port, power, kernel log |
| GPT partition warning | Partition-table context; do not format automatically |
| Filesystem marked dirty/corrupt | Unmount, back up, use filesystem-specific tools |
| SSD/NVMe I/O errors | SMART/NVMe health, kernel log, backup |
| Drive is read-only | Filesystem errors, hardware, mount state |
| Wrong disk size | Partition layout, device mapper/LVM, filesystem size |
The first question is not “How do I repair it?” It is “Does Linux see the device, the partition, and the filesystem?”
1. List Disks, Partitions and Filesystems
Start with:
lsblk -fThis shows:
- disks;
- partitions;
- filesystem types;
- labels;
- UUIDs;
- mount points.
For more detail:
sudo fdisk -lor:
sudo parted -lDo not run formatting commands just because a device has no mount point.
A partition without a mount point can be perfectly healthy and simply not mounted.
Start here
Recommended guides
OviOS Linux V6 POLARIS Is Here: A Generational Leap for Open-Source Storage
OviOS Linux V6 POLARIS is here with Kernel 7.0, OpenZFS 2.4.2, systemd, NVMe-oF, S3 support, and a browser-based monitor —…
ZFS on Linux: Building Resilient Storage Systems in 2025
Dive into the world of ZFS on Linux and discover how to build resilient storage systems in 2025! This comprehensive…
How to Recover Deleted Files on Linux: A Complete 2026 Guide
Deleted the wrong file on Linux? Here's how to recover it fast — with the right tool for your exact…
2. Check Kernel Messages When a Disk Is Missing
If a drive does not appear where expected, inspect recent kernel messages.
For general storage:
dmesg | grep -iE 'nvme|ata|scsi|usb|i/o error|reset|timeout'For an external drive, reconnect it and then inspect recent output:
dmesg | tail -n 80Look for:
- device resets;
- USB disconnects;
- I/O errors;
- timeouts;
- failed initialization.
If the disk repeatedly disappears at the hardware/kernel level, a mount command is not the fix.
3. Check Disk Space and Inodes
For filesystem usage:
df -hLook especially at /, /home, and any dedicated data partitions.
A filesystem at 100% can cause:
- application failures;
- failed updates;
- login problems;
- database errors;
- inability to create temporary files.
Also check inodes:
df -iA filesystem can have free gigabytes and still report:
No space left on deviceif it has no free inodes.
This often happens when a directory contains enormous numbers of small files.
4. Find What Is Using the Space
To inspect top-level usage on a filesystem:
sudo du -xhd1 /For the home directory:
du -hd1 ~The -x option keeps the root check on the same filesystem, which avoids accidentally walking through mounted external or network filesystems.
Common large areas include:
/var/log;- package caches;
- container images;
- virtual machines;
- downloads;
- old backups;
- application caches.
Do not delete unfamiliar system directories merely because they are large. Identify what created the data and use the appropriate cleanup method.
5. A Partition Exists but Will Not Mount
First identify the filesystem:
lsblk -fThen try mounting it manually to obtain a useful error.
Create a temporary mount point:
sudo mkdir -p /mnt/testdiskThen:
sudo mount /dev/DEVICE /mnt/testdiskReplace /dev/DEVICE with the actual partition, not a disk name copied from an example.
If mount fails, read the error message.
Common causes include:
- unsupported/missing filesystem tools;
- a dirty or inconsistent filesystem;
- wrong filesystem type in configuration;
- encrypted/LVM layer not opened;
- Windows Fast Startup/hibernation for NTFS;
- hardware I/O errors.
Do not add the partition to /etc/fstab until manual mounting works reliably.
6. Check /etc/fstab When Boot Is Delayed or a Mount Fails
View the configuration:
cat /etc/fstabCompare UUIDs with:
lsblk -fIf a partition was recreated, cloned, or reformatted, its UUID may have changed.
An incorrect fstab entry can:
- delay boot;
- drop the system into emergency mode;
- leave a mount missing.
Before editing:
sudo cp /etc/fstab /etc/fstab.backupAfter editing, on systemd-based systems you can test mount definitions without rebooting:
sudo mount -aIf that returns an error, fix it before rebooting.
Be especially careful with the root filesystem and EFI partition entries.
7. Understand GPT and MBR Warnings Before Acting
GPT and MBR are partition-table formats.
Modern UEFI systems commonly use GPT, while older BIOS-era setups may use MBR.
A message mentioning GPT does not automatically mean the disk is corrupted.
For example, a formatting or filesystem command may warn that it found a partition table because you accidentally targeted the entire disk instead of a partition.
Before proceeding, check:
lsblkand:
sudo fdisk -lMake sure you understand whether the command target is:
/dev/nvme0n1the whole disk, or something like:
/dev/nvme0n1p3a partition.
TechRefreshing already covers this class of issue in more detail in its Linux GPT partition-error guides. Treat warnings as a reason to inspect the target, not a reason to click through blindly.
8. External USB Drive Keeps Disconnecting
If an external drive appears and disappears, check:
- another cable;
- another USB port;
- a powered hub where appropriate;
- whether the enclosure needs more power;
- another computer if available.
Watch:
dmesgduring the disconnect.
If the kernel reports repeated USB resets or the entire device vanishes, filesystem repair may not address the underlying physical connection.
Do not run a repair tool repeatedly on an unstable connection.
9. Check SMART Health for SATA Drives
If smartctl is available through smartmontools, inspect a SATA drive:
sudo smartctl -a /dev/sdXReplace /dev/sdX with the actual disk.
SMART data can provide evidence about:
- reallocated sectors;
- pending sectors;
- errors;
- temperature;
- device health information.
Do not judge a drive from one number without understanding the vendor and attribute. The overall error log and trend matter.
For an important drive showing I/O errors or deteriorating health, back up data before attempting intensive filesystem repairs.
10. Check NVMe Drive Health
For NVMe drives where nvme-cli is installed:
sudo nvme smart-log /dev/nvme0Device naming can differ.
Look for media/data integrity errors, critical warnings, temperature, and available spare information.
Again, health tools are evidence—not a guarantee that a drive is healthy or dead.
If the kernel is logging repeated NVMe resets or I/O errors, prioritize the data.
11. Filesystem Errors: Unmount Before Repair
Filesystem repair tools should generally not be run against a mounted filesystem that is actively being written to.
For ext filesystems, fsck is commonly used through filesystem-specific helpers, but the correct procedure depends on the filesystem and whether it is mounted.
For a non-root partition, unmount first where safe:
sudo umount /dev/DEVICEThen follow the filesystem’s supported repair procedure.
Do not blindly run:
fsck -yon an important disk just because a guide says so.
Automatic “yes to everything” repairs can discard data structures. Back up first when possible and read the repair output.
For the root filesystem, use recovery/live media when necessary.
12. Btrfs, XFS and Other Filesystems Need Their Own Tools
Not every Linux filesystem should be treated like ext4.
Examples:
- Btrfs has its own checking and recovery tools.
- XFS uses
xfs_repairfor repair. - NTFS has different Linux and Windows-side considerations.
- exFAT/FAT filesystems use their own utilities.
Do not choose a repair command before confirming the filesystem with:
lsblk -fUsing the wrong repair tool is not useful and can be dangerous.
13. Drive Became Read-Only
A filesystem may remount read-only after serious errors to protect itself from further damage.
Check mount state:
mountand kernel messages:
dmesg | tail -n 100Look for filesystem and I/O errors.
Do not immediately force the filesystem back to read-write. Determine why it became read-only first.
If the cause is storage hardware failure, additional writes may make recovery harder.
14. NTFS Partition Will Not Mount After Windows
A Windows partition can refuse normal read-write mounting when Windows Fast Startup or hibernation left the filesystem in a state that Linux should not modify.
If the mount error mentions hibernation or an unsafe NTFS state, boot Windows and perform a full shutdown after disabling the relevant hibernation/Fast Startup behavior.
Do not force-write a hibernated Windows system volume unless you understand the data-loss risk.
The safer fix is to leave the Windows filesystem in a cleanly shut-down state.
15. Permission Problem or Mount Problem?
Sometimes the disk mounts correctly but your user cannot write to it.
Check the mount point:
findmntand permissions:
ls -ld /path/to/mountThe correct solution depends on:
- filesystem type;
- mount options;
- ownership model;
- whether multiple users need access.
For Linux filesystems, normal Unix ownership/permissions apply.
For FAT, exFAT, or NTFS, ownership can be controlled through mount options because those filesystems do not behave exactly like ext4 permissions.
Avoid solving every permission issue with:
chmod -R 777That removes meaningful permission boundaries and is rarely the right long-term configuration.
16. Disk Is Present but the Filesystem Uses the Wrong Size
After expanding a virtual disk, partition, RAID/LVM volume, or physical partition, the filesystem may still retain its old size.
Check:
lsblkand:
df -hIf the block device is larger but the filesystem is not, the filesystem may need to be grown.
The correct command depends on:
- filesystem;
- LVM/device mapper;
- partition layout.
Do not run a filesystem-grow command intended for ext4 on XFS or Btrfs. Follow the filesystem’s documentation.
17. LVM Changes the Device Layout
Systems using LVM may not mount filesystems directly from ordinary partition device names.
Useful commands include:
sudo pvssudo vgssudo lvsIf the physical disk is visible but the logical volume is missing, investigate the LVM layer before editing /etc/fstab or formatting anything.
A device such as:
/dev/mapper/vgname-lvnamecan be the actual filesystem device even though the physical storage lives elsewhere.
18. Encrypted Drives Need to Be Unlocked First
LUKS-encrypted storage adds another layer.
List devices:
lsblk -fEncrypted partitions may show a crypto type rather than the final filesystem.
If the encrypted container is not opened, the filesystem inside it will not appear normally.
Use your distribution’s normal encrypted-volume tools and recovery information.
Do not reformat a partition merely because the filesystem inside an unopened encrypted container is not visible.
19. Before Repartitioning, Back Up the Partition Table
When you genuinely need to change partitions, first make sure critical data is backed up.
For GPT/partition work, record the current layout with tools such as:
sudo fdisk -lor:
sudo parted -lScreenshots or saved command output can be useful.
Partition editing carries real risk. Verify disk names, sizes, and mount state before applying changes.
A Practical Linux Storage Troubleshooting Order
Use this sequence:
- Back up important data if the disk is unstable.
- Run
lsblk -f. - Check
df -handdf -i. - Read kernel logs for I/O/reset errors.
- Confirm the partition table with
fdisk -lorparted -l. - Try a manual mount only after identifying the filesystem.
- Compare UUIDs with
/etc/fstab. - Check SMART/NVMe health when hardware failure is possible.
- Unmount before filesystem repair where required.
- Use the correct repair tool for the actual filesystem.
- Change partitions only after confirming you have the correct disk.
Storage troubleshooting rewards patience. A mistaken command can destroy the evidence—or the data—you were trying to recover.
Disk, Partition and Filesystem: What Is the Difference?
A disk is the physical or virtual storage device.
A partition table such as GPT or MBR describes how that disk is divided.
A partition is one region of the disk.
A filesystem such as ext4, Btrfs, XFS, NTFS, or exFAT organizes files inside a partition or logical device.
A mount point makes that filesystem accessible within the Linux directory tree.
Those layers explain why a disk can be detected while a filesystem still refuses to mount.
Official References Worth Checking
Useful primary references include:
- Linux kernel storage documentation
- util-linux documentation
- filesystem-specific documentation for ext4, Btrfs, XFS, and others;
- smartmontools
- your Linux distribution’s storage and recovery documentation.
For destructive operations, always prefer the current documentation for your actual filesystem and distribution.
A Linux disk problem does not automatically mean the data is lost. Start by identifying which layer still works, protect important files, and repair only the layer that has actually failed.
