Contents

Problem

A USB 3.0 external hard drive connected to a USB 3.0 port is not seen by the system. For example with the KDE desktop it does not appears in the Device Notifier.

Simple Solution

Connect the drive to a USB 2.0 port and try again.

Background

The USB 3.0 specification transfers data much faster than USB 2.0 but it also has extra commands, called the UAS or USB-Attached-SCSI protocol, which are particularly useful when transferring large numbers of small files. Unfortunately some commonly available hard drives do not support the full set of extra commands or need to be initialised in a non-standard way.

Regrettably there is also often a delay before the linux kernel developers are told of new devices with such quirks, it can take time to find ways around the problem and a further time before the revised code is available in the distributed versions of linux (i.e. openSUSE, Red Hat or Ubuntu).

The following describes ways to shortcut the process. However it needs experience of acting as a root user. Any errors could result in casastrophic failure of your system so, if you are not an experienced root user, get help from a friendly expert. Your local Linux Users Group will help. You also may find a local computer shop with a Linux expert.

Further Options

If you have a new device which fails to mount correctly, it is worth first checking the system logs to make sure that the kernel is at least able to interrogate the device and receive sensible replies. If this is not happening then the problem is most likely a hardware fault.

Interrogating the system logs

Recent versions of openSUSE use systemd to initialize the system and to process kernel messages. To see what happens when a new device is connected, open a terminal window and as root issue the command 'journalctl -f'. This can be done using the sudo command:

sudo journalctl -f

After asking for the root password this will generate a few lines of recent kernel messages and will then output further messages as they are produced.

At this point connect the hard drive via a USB 3.0 port. It should then output lines of the form:

This may then be followed by many lines of error messages. Note the Vendor and Product numbers on the second line of the listing above.

Force USB 2.0 Commands on a USB 3.0 Port

If the device connects through the USB 3.0 port and generates the above output but then fails, it is likely that it is the USB 3.0 commands that are causing the problem. These can be bypassed by adding the line described below to the file '/etd/modprobe.d/ignore_uas.conf'.

The file needs to be edited by root. If the 'vi' editor is used this could be via the command:

#sudo vi /etc/modprobe.d/ignore_uas.conf

The system will ask for the root password after which a line of the following form should be added to the file:

options usb-storage quirks=idVendor:idProduct:u

Wher idVendor and idProduct are the numbers from the system log. Thus for the output listed above the line would read:

options usb-storage quirks=0bc2:331a:u

Restart the system. This time when the USB 3.0 hard drive is connected it should connect and mount correctly. However its speed will not be optimum because it will only be using the USB 2.0 set of commands.

Getting the Latest List of Quirks

It has been found that many of the devices have similar quirks. It is thus possible that your installed linux kernel includes code to bypass the quirk but needs to be told which bit of code to use. The latest list of such quirks is usually found in the current mainline kernel. In April 2016 this can be found at "www.kernel.org".

If you click on the mainline 'browse' option and then the 'tree' tab, it is possible to work down the tree to the drivers->usb->storage directory. The quirks affecting USB 3.0 storage devices are given in file 'unusual_uas.h'. This consists of a series of specifications starting with "UNUSUAL_DEV" and followed by four numbers. The first two are the Vendor and Product numbers corresponding to the IdVendor and idProduct shown in the output lines above. Examples are:

If you can find the same two numbers for your own device in the list, make a note of the final variable in the list, for example US_FL_IGNORE_UAS or US_FL_NO_ATA_1X. These are flags which control the use of USB 3.0 commands.

Next you need to inspect the file 'usb.c'. This contains a routine 'usb_stor_adjust_quirks', which processes the file 'ignore_uas.conf'. Find the case command which associates the character found at the end of the above options line with the same set of flags. Thus, in the following extract, 'u' is defined as being equivalent to the flag US_FL_IGNORE_UAS, and 't' to the flag US_FL_NO_ATA_1X.

At this point you need to find the character corresponding to the your device's quirk.

Finally edit your own 'ignore_uas.conf' file, replacing the 'u' at the end of the line you added by the character from 'usb.c'. Restart your computer and again try connect the USB 3.0 hard drive to a USB 3.0 port. If your installed kernel supports the quirk then the device will mount correctly. If it does not then the best option is probably to go back to using the 'u' character in the file 'ignore_uas.conf'.

In that case, if your kernel is regularly updated, the code needed for your device will eventually be installed and you will no longer need the line in 'ignore_uas.conf'. This could take some time but if you are really keen and understand about compiling kernel modules it is possible to compile the latest 'uas' module, which handels USB 3.0 storage, for your current kernel. However that is outside the scope of this note.

Device not in 'unusual_uas.h'

If your device is not in the latest list it probably means that the developers have not been told about the problems with your device. The file gives instructions on how to add a patch and who to send it to. The easiest scheme is copy one of the statements containing the flag US_FL_IGNORE_UAS and to replace the Vendor and Product numbers with those for your own device.

However if you use this route be prepared to provide additional information, for example the error output from the kernel, and be prepared to compile and test additional module options. This is because as the developers do not like to bypass the USB 3.0 set of commands except as a last resort.