In the previous two posts on how to use the password protection feature of hard disks and SSDs and how to unlock them when temporarily connected to another computer via a USB adapter, I mentioned that the adapter has to support the UAS (USB Attached SCSI) protocol. Unfortunately, some (older) USB-3 to SATA adapters do not support the protocol which results in strange hdparm error messages. As I was doing this for the first time, I had the dilemma that I didn’t know if the strange error messages were a result of a mistake I made or if the adapter did not support the required protocol. After a bit of searching I came up with the following procedure to check for support:
In a first step one needs to find out which USB device ID the adapter has been given. Here’s an example:
# lsusb [...] Bus 003 Device 118: ID 0bc2:3343 Seagate RSS LLC Desktop [...]
The lsusb command lists all USB connected devices so you have to search for the USB SATA adapter based on the device names that is given in the list. In my case the adapter was easy enough to identify and was device 118 on USB bus 3.
With this information run the lsusb command again with the -t option. This results in:
# lsusb -t
[...]
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 118, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 3: Dev 63, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 64, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
[...]
If the device supports UAS, the corresponding driver is shown in the device’s list entry. In my case the first adapter I tried did not support UAS which resulted in the following lsusb output (and subsequently to strange hdparm error messages):
[...]
|__ Port 2: Dev 124, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
[...]
So if your adapter supports UAS the basic hdparm info command will reveal a lot of information about the drive. Here is an abbreviated example:
#sudo hdparm -I /dev/sdb
/dev/sdb:
ATA device, with non-removable media
Model Number: Samsung SSD 860 EVO 2TB
Serial Number: xxxxxxxxxxxxxxxx
Firmware Revision: RVT0xxxx
Transport: Serial, ATA8-AST, SATA 1.0a,
SATA II Extensions, [...]
Standards:
Used: unknown (minor revision code 0x005e)
Supported: 11 8 7 6 5
Likely used: 11
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
[...]
Security:
Master password revision code = 16385
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level high
[...]
USB-3 Trouble
While this worked very nicely with my adapter for non-password protected drives, things got very weird if password protection was enabled. When connected over USB-3, I was unable to send the password unlock command, the LED on the adapter would just keep blinking. After a bit of tinkering, I found out that when I connected the adapter over USB-2, I could unlock the device just fine. I tried on two different computers with Ubuntu 18.04 and 20.04 and the result was the same: USB-3 didn’t work for unlocking, USB-2 did. To me it’s not clear if this is a bug of the adapter or the UAS Linux driver.
So while I can unlock a password protected drive over USB-2 just fine, it’s a major bottleneck for transferring large amounts of data, as transmission speed is limited to 40 MB/s. To get around this, my solution is to first use a USB-3 to USB-2 adapter, unlock the device, disable the password protection. Then reconnect the device to USB-3, perform the data transfer. Once done I password protect the drive again. This can be done over USB-3 because once unlocked, hdparm and the Linux UAS driver work just fine. A bit of a riddle. So here’s the command sequence required for this:
# Over USB-2 sudo hdparm --security-unlock hex:xxxxxxxxxxxxxxx /dev/sdb sudo hdparm --security-disable hex:xxxxxxxxxxxxxxx /dev/sdb # Reconnect to USB-3 for fast data transer # Finally, password protect the drive again. Can be done # over USB-3 sudo hdparm --security-set-pass hex:xxxxxxxxxxxxxxx /dev/sdb # Verify that the password lock is in effect: sudo hdparm -I /dev/sdb
Not ideal, but it gets the job done!