External Drive Not Recognised on Linux: A Step-by-Step Diagnosis

A missing USB drive means many things. Did the kernel see the device? Does a block device exist for it? Can Linux even decipher the filesystem? Each command tells you exactly where the drive stops appearing, and diagnostic certainty depends on hitting them in the right order.

USB Bus and Kernel Detection

You're using lsusb and lsblk without results. You're scanning dmesg, but seeing no kernel messages for the drive. The first thing to prove is whether you're building a diagnosis from "kernel sees USB" or from an empty result at that earliest layer.

When a USB drive is first inserted, that's the threshold Linux crosses to show it at all. If no entries for the drive appear in the output of lsusb after you insert it, Linux never detected a USB protocol device there, and it never built a device node for you to work with.

With lsusb, one thing to watch for is whether the same device ID persists after device insertion. If the ID jumps for devices plugged in the same physical port, the system is seeing the new hardware but it might be doing so as a USB hub rather than a storage device.

dmesg is the other terminal real-time log that indexes kernel messages, including device specifics for newly inserted USB drives. You're looking for entries like "usb 1-2: new high speed USB device" or sometimes "usb connected".

journalctl --follow is arguably even more suited for this item-by-item real-time detection. It's not as refined as dmesg for device-specific messages, but it can show working and failed udisks2 calls as the drive appears and attempts to auto-mount.

Missing kernel messages don't immediately mean no device enumeration. Kernel modules for USB storage, hid, and usbhid need to be in the running kernel, or that's how dmesg only sees a USB hub but not a USB drive. The modules needed for a working usb protocol are still on the community UBuntu troubleshooting page, but they will be in the kernel documentation for your specific distribution.

The absence of the drive in lsblk, lsusb, and dmesg together means it has not appeared in the USB enumerated device list. It has not been registered at the USB protocol layer. You're probably looking at a cable, port, power, or hardware probe issue, rather than an issue with the drive's filesystem, partitions, or mountability on Linux.

Block Device and Partition Table

We are considering the case where a USB device appears in kernel messages and can be seen by lsusb, but it doesn't show up in the file manager at all.

lsblk lists information about all available or specified block devices. It's the closest the terminal has to a real-time file manager that sees only this device. If you see the drive there, Linux has a handle on a block device node in /dev, and you also have an abstract representation of it, for example, in /sys/block and /proc/partitions.

lsblk -f further builds on this view of the device to search for filesystems on its partitions. We're still only dealing with the Linux namespace for the device, though. If it's reported here, the device has a block device node with a valid partition table, and dmesg should take that as far as "read partition table" messages.

The marker to look for in lsblk -f is iso9660. It means the filesystem is read-only. The

These are still preliminary steps to a real mounting operation. A successful lsblk -f just means that the filesystem signature is known to the system, but it hasn't been presented to you as a storage destination. It often means udisks2 has triggered an on-demand mount in the background.

This no-visible-filesystem state is still over-working your USB stack unnecessarily, but it puts "mountable filesystem" and "visible in file manager" closer together. fdisk -l here is the command you need often because it allows you to inspect the partition table.

If you have the drive listed in lsblk -f or by an fdisk -l call, but you still don't have a filesystem, you are likely looking at an unsupported filesystem drive. A common real-world case is a drive formatted for the Raspberry Pi OS that uses a floppy disk-legacy udf filesystem.

The filesystem type doesn't appear in lsblk -f, and your auto-mount attempts fail with policykit errors rather than the drive being "disappeared" at higher levels of the USB stack. This is where the drive is most fully enumerated by Linux.

Filesystem and Mounting

If you can see the USB drive in the file manager or your disk label app, but you can't click to mount it, we've finally reached the filesystem-and-mount stage. It's at this stage too that you begin to deal with permissions errors.

With an lsblk -f call that sees "no filesystem," you would also have lsusb and dmesg entries. We are dealing with a fully enumerated device, probably with a block device node, but no analyzer has called the partition table readable or signified it as mountable.

The eventual mount point is usually /media/<username>/<volume_name>. This differs based on your flavor of Linux: Ubuntu and similar distros remap this to /mnt/<label>, and the Windows Subsystem for Linux mounts the Linux file system to /mnt/c.

So far, we've crossed the USB protocol, had the USB kernel modules respond to the new device, worked out the block device node, and taken over a storage format that Linux is willing to mount. These are the things a lost USB drive most commonly fails at.

At this point, you're looking at two types of fail. The first is a volume mismatch or a user permissions error.

The volume error usually signals a Linux device mount manager that has reported the partition table is readable, but it is tagged with an unmountable filesystem. This is often an ext4 filesystem part of a software RAID which was not assembled with mdadm.

A second reason is a "device /dev/sdc not found". This error message outlines a permissions issue, often with gvfs (when you try to mount in the graphical environment), but sudo is needed.

Permissions and Desktop Policy

At this layer, when the drive is fully enumerated and labeled in the file manager, you're likely dealing with a permission error on the mount point.

This might be because auto-mount was disabled in Nautilus, Dolphin, Thunar, or another desktop environment application for media.

A filesystem in lsblk -f means Linux has built an understanding of a mount point out of the drive's partition table, and this is visible to the file manager if auto-mount is enabled by default.

If the <volume_name> still isn't available as a mount point, even when auto-mount is on, you might also have a graphical gvfs/_nfsdbus permission error. This is often a polkit error.

These are granted by the PolicyKit3, or polkit, daemon. The daemon lets the desktop file manager anticipate your intention to mount a local or network volume, and then decide when it can proceed with the mount operation.

You can check polkit rules on your Linux flavor, but the most common rule you will have to adjust is to grant your user permission to org.freedesktop.UDisks2.filesystem-mount-unprivileged objects.

What to Do When Nothing Appears

Some USB drives do not appear in lsusb, dmesg, or the file manager. Sometimes, lsusb detects the drive, but there is no indication of a filesystem. These missed USB drives are often physical port or device failures.

If the drive is not enumerated at all, meaning it doesn't show up in lsusb, and doesn't appear in dmesg, it's most commonly a problem with the device protocol or the cable.

Many USB 2.0 and 3.0 devices are powered over the USB bus, and USB 3.0 often demands high power for a fast transfer. If the cable is damaged or faulty, the drive might not be enumerated by the USB bus, and hence not registered as a device by the kernel. Replacing the cable and trying another USB port can resolve the issues at this stage.

Sometimes, device drivers cause these issues. Older USB drives, like those formatted in a Microsoft Windows XP era ntfs, might not be supported by the sinking driver support.

Drivers for more popular protocols like Fat32 and ext4 have pushed usbcore to the sidelines, but modprobe is often need to resolve if the driver appears for your drive and syslog shows no usbcore.

Another driver causing issue might be visibility in the file manager but not the root filesystem. This is a forum-cited gvfs issue that fails to share your mount between Nautilus and your web-based interface. In this case, restart gvfs, dont kill the process, because gvfs is responsible for async, among many other features, most specifically gvfs-backends, that might need to initialize during the restart.

NOW, IF NOTHING COMES UP FOR YOUR DRIVE:

Try turning off wpa_supplicant, save the connection, and turn it back on.

If you go back to the port issue and your USB 3.0 port has gone out of power, there might not be enough amperage to initially boot the drive, even if you do get Linux support. So many drives have bars for USB 2.0, and if you have USB 2.0 sharing support for USB 3.0 drive, you can fall back to USB 2.0, but it still might not mount. If nothing else works, it might be time to connect your drive to another computer and see if the error is at the drive level or kernel module level. Restarting the computer or the drive should also be in your checklist.

Setting permissions for a rooted filesystem

If you have access to a command prompt on your bootable USB, etcher or another method, make sure you have a superblock: your drive sdb 2

Then you can edit the permissions to something like: group sudo

The important thing is to be able to mount it as read-only. If you can't get mounting to happen because of these groups, it is time to let your filesystem be writable and mount it. If you have to boot into a permissive USB mode (often nonalpine or non-live-boot), then make sure your filesystem is writable, and that you don't run into journaled filesystem limits as a clean unmount.

Some Linux distrobutions point to a path like: /dev/sdXn where X is the drive letter If this is empty, try df | grep sdXn

Sources

• Ask Ubuntu — askubuntu.com
• Cloudhouse Technologies — cloudhousetechnologies.com