Identifying the Correct Device
The first step in recovering data from an external SSD is to ensure you are targeting the correct block device. When you connect the drive, the kernel assigns it a device node such as/dev/sdb, /dev/sdc, or potentially /dev/nvme0n1 if it is a high-speed NVMe unit connected via USB. It is critical to distinguish between the disk identifier (e.g., sdb) and its partitions (e.g., sdb1). Mounting the wrong device can lead to writing data to the system drive instead of the external one, which is catastrophic for data recovery.
Use the lsblk command to list all block devices along with their sizes and types. This output helps you confirm the capacity of the external SSD matches your expectations. For example:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
Look for the entry that corresponds to your external drive's capacity. If the drive is not listed, check the physical connections or try a different USB port. Once identified, note the device name for subsequent commands. Avoid using generic names like /dev/disk/by-uuid/... initially, as these can sometimes resolve ambiguously if multiple drives have similar UUIDs.
Analyzing the Partition Table
Since the drive uses an MBR partition scheme, it does not rely on a GPT header at the end of the disk. Instead, the partition information is stored in the first sector. You can inspect this layout using thefdisk utility. Run the following command, replacing X with your device letter:
sudo fdisk -l /dev/sdX
This command will display the partition table type (typically labeled as "dos" for MBR) and list any existing partitions. If the output shows partitions like /dev/sdX1, /dev/sdX2, etc., the partition table is intact, and the issue likely lies in the filesystem or mounting process. If the output indicates "No valid partition table found," the MBR may be corrupted, requiring more advanced recovery tools like testdisk. However, most cases involve a valid partition table that simply hasn't been mounted by the operating system.
If you suspect the partition boundaries are incorrect due to previous errors, you might need to reassemble disk partitions. Refer to our guide on Reassembling Disk Partitions from Separate Images in Linux for techniques involving partition image files.
Determining the Filesystem Type
Knowing the partition exists is not enough; you must know what filesystem resides on it. Common filesystems include NTFS, exFAT, ext4, and FAT32. You can determine the type using thefile command with the -sL flags, which specify a special file and follow symbolic links:
sudo file -sL /dev/sdX1
The output might read something like "/dev/sda1: Linux rev 1.0 ext4 filesystem data...". This confirms the filesystem type. If the output says "data" or "non-file-system," the filesystem metadata may be damaged. In such cases, do not attempt to write to the disk. Instead, consider creating a forensic image of the partition before running repair tools.
For users dealing with unexpected partition issues during setup, see Incorrect Partition Sizes Assigned During Linux Installation on New WD Blue SSD for context on how size mismatches can occur.
Mounting the Drive
Once you have identified the device and the filesystem, create a mount point directory. This is a folder where the contents of the drive will appear in your file manager.sudo mkdir -p /mnt/external_ssd
Now, mount the partition using the mount command. You should specify the -t option to explicitly tell the kernel which driver to use. For an NTFS drive, use ntfs-3g; for ext4, use ext4.
sudo mount -t ntfs-3g /dev/sdX1 /mnt/external_ssd
If the mount fails, check the system logs for specific error codes using dmesg | tail. Common errors include "wrong fs type" (indicating a mismatch between the detected and specified filesystem) or "device busy." If the drive was previously used on Windows, it might be in a hibernated state, locking the NTFS volume. In this case, you may need to boot into Windows and shut down properly, or use ntfsfix to clear the lock flag cautiously.
After successful mounting, verify access by listing the contents:
ls -l /mnt/external_ssd
If you can see your files, you have successfully accessed the data. To make this persistent across reboots, you would typically update your /etc/fstab configuration. Learn more about managing these configurations in Explain Information: You may need to update /etc/fstab.
Unmounting Safely
When finished accessing your data, always unmount the drive properly to prevent data corruption. Use theumount command followed by the mount point or the device name.
sudo umount /mnt/external_ssd
Verify that the drive is no longer mounted by running lsblk again. The MOUNTPOINT column for your device should now be empty. Only then should you physically disconnect the SSD.
Frequently Asked Questions
What if fdisk shows no partitions but the drive has data?
If fdisk reports no valid partition table, the MBR may be overwritten or corrupted. You should use a tool like testdisk to scan the disk for lost partitions and restore the table. Always create a backup image of the entire disk before attempting any repairs to avoid permanent data loss.
Can I access an NTFS drive on Linux without installing extra packages?
Modern Linux kernels include built-in read-only support for NTFS via the ntfs3 driver, which is included in newer distributions. However, for full read-write compatibility and better stability, especially with older Windows versions, installing the ntfs-3g package is recommended.
Why does my external SSD show up as "unmounted" in the file manager?
This often happens because the filesystem is not automatically mounted due to missing entries in /etc/fstab or because the system lacks the necessary kernel modules for that specific filesystem. Manually mounting the drive using the terminal as described above resolves this issue immediately.
Is it safe to run fsck on an external SSD?
Running fsck (filesystem check) is generally safe for fixing logical errors, but it carries a risk of data loss if the filesystem is severely corrupted. Always back up your data to another location before running any filesystem repair utilities, especially on drives containing critical information.
How do I fix permission denied errors when accessing the mounted drive?
Permission errors usually occur because the mounted files are owned by root or a different user ID. You can change ownership using the chown command, for example: sudo chown -R $USER:$USER /mnt/external_ssd. Alternatively, you can add options like uid=1000,gid=1000 to your mount command or /etc/fstab entry.