A hard drive appearing empty while containing data usually stems from a corrupted partition table, a damaged filesystem superblock, or an unrecognized file system type. The operating system fails to mount the volume because it cannot locate the structural metadata required to interpret the raw sectors. This guide details how to diagnose these specific failures using
fdisk,
fsck, and GPT recovery tools to restore access without immediately resorting to third-party software.
Identifying the Root Cause via Partition Tables
The first step in troubleshooting is verifying whether the kernel recognizes the physical device and its logical partitions. When a drive appears empty, it often means the partition table is missing or corrupted, causing the system to see only unallocated space. Use the
lsblk command to list all block devices and their mount points. If your drive appears under
lsblk but shows no partitions or has a size of zero, the issue lies within the partition structure rather than the individual files.
You should also check the output of
dmesg | tail for errors related to the specific device node (e.g.,
sdb). Look for messages indicating "I/O error," "bad GPT," or "unknown partition table." A corrupted GUID Partition Table (GPT) can make the drive invisible to standard mounting utilities. In such cases, the backup GPT header at the end of the disk might still be intact, allowing for reconstruction. Refer to our guide on
Unable to Access GPT Protected Partition on New 16TB External HDD for detailed steps on repairing GPT headers when the primary header is lost.
Checking Filesystem Integrity with fsck
If the partition exists but refuses to mount, the filesystem metadata is likely damaged. The most common culprit is a corrupted superblock, which contains critical information about the filesystem layout, including inode tables and block groups. Before running any repair commands, ensure the drive is not mounted. Attempting to run
fsck on a mounted filesystem can cause further corruption. You can verify the mount status using
mount | grep /dev/sdX.
To diagnose the filesystem type, use the
file -sL /dev/sdXN command, replacing
XN with your specific partition identifier. This command reads the superblock to identify if the filesystem is ext4, NTFS, exFAT, or something else. If the filesystem is recognized as unknown or corrupted, you can attempt a read-only check using
fsck -n /dev/sdXN. The
-n flag prevents any changes, providing a log of errors that helps determine the severity of the damage. If the output indicates minor inconsistencies, a standard
fsck -y /dev/sdXN may resolve the issue by automatically fixing detected problems.
Restoring Damaged Superblocks
When
fsck reports that the superblock is invalid or missing, you must restore it from a backup. Linux filesystems like ext3 and ext4 store multiple backup superblocks at predictable intervals throughout the disk. To find these locations, use the
mke2fs -n /dev/sdXN command. This simulates creating a filesystem without writing anything, outputting the block group numbers and the exact block addresses where backup superblocks are stored.
Once you have identified a valid backup superblock address, restore it using the command
fsck -b [backup_superblock_address] /dev/sdXN. For example, if the backup is located at block 8193, you would enter
fsck -b 8193 /dev/sdXN. After the restoration process completes, attempt to mount the drive again using
mount /dev/sdXN /mnt/point. This method is highly effective for drives that appear empty because the kernel cannot parse the initial metadata, even though the actual data blocks remain untouched on the platters.
Handling RAW or Unrecognized Filesystems
Sometimes, the drive will show up as "RAW" in Windows or simply fail to mount in Linux due to severe corruption or incompatible filesystem types. If
file -sL returns "data" instead of a filesystem name, the partition table might be correct, but the filesystem signature is gone. In this scenario, specialized tools like
testdisk can scan the disk for lost partitions. Testdisk analyzes the disk geometry and searches for known filesystem signatures, allowing you to recover the original partition structure.
For users dealing with mixed environments, such as recovering an NTFS drive that has become inaccessible, ensure that the appropriate drivers are installed. On Linux, the
ntfs-3g package provides read-write support for NTFS volumes. If the drive was previously accessible and suddenly became empty, check for recent power losses or unsafe removals, which often trigger these metadata failures. For more complex scenarios involving overwritten data structures, consider reviewing
Recovering Backup: Overwritten 512GB to 6TB Drive with GPT, NTFS, MFT, and Mirror to understand how metadata mirrors can aid in reconstruction.
Data Recovery Precautions
Before attempting any repairs, create a bit-for-bit image of the drive using
ddrescue or
dd. Working on a clone ensures that any failed repair attempts do not overwrite the remaining recoverable data. Store the image on a separate storage device with sufficient capacity. Once the image is secured, perform all diagnostic and repair operations on the cloned image rather than the original hardware. This practice minimizes the risk of permanent data loss during the troubleshooting process.
Frequently Asked Questions
Can I recover data if the partition table is completely deleted?
Yes, you can recover data even if the partition table is missing. Tools like
testdisk can scan the disk for existing filesystem signatures and rebuild the partition table based on those findings. Always work on a disk image first to prevent accidental overwrites during the search process.
What does it mean if fsck says the superblock is bad?
A bad superblock indicates that the core metadata describing the filesystem structure is corrupted or unreadable. This prevents the operating system from knowing where files are stored, making the drive appear empty. Restoring a backup superblock from the predefined locations often resolves this issue without data loss.
Is it safe to run fsck on a mounted drive?
No, running
fsck on a mounted drive is dangerous and can lead to severe data corruption. The filesystem expects consistent state while mounted; modifying it concurrently can break links and lose data. Always unmount the drive or boot from a live USB environment before running filesystem checks.
Why does my drive show as RAW after connecting to a PC?
A RAW designation means the operating system cannot recognize the filesystem format due to corruption, formatting issues, or driver incompatibility. It is not necessarily a sign of physical failure but rather a logical barrier to access. Identifying the original filesystem type allows you to apply the correct repair tools or drivers to regain access.
How do I find backup superblock locations for ext4?
Use the
mke2fs -n /dev/sdXN command to simulate filesystem creation and output the backup superblock addresses. The command lists block groups and their corresponding superblock locations without writing any data to the disk. These addresses are essential for restoring the primary superblock when it becomes damaged.