Add UDEV rule to fix duplicate serial numbers on QNAP TR-002

[zsteinmetz]

Is your feature request related to a problem? Please describe.

I have a QNAP TR-002 with two 4TB HDDs connected via USB to a Dell Wyse 5070 thin client running OMV 7.0-25. The QNAP is configured in individual/single mode making both disks visible to OMV. However, device information is masked by QNAP. The device model just reads "TR-002 DISK00" and "TR-002 DISK01" with two identical serial numbers.

Describe the solution you'd like

I added this modified UDEV rule to /etc/udev/rules.d in line with #746 and #1302, which seems to fix the issue.

ENV{ID_VENDOR_ID}=="1c04", \
  ENV{ID_MODEL_ID}=="0012", \
  IMPORT{program}="serial_id %N", \
  ENV{ID_SERIAL}="$env{ID_VENDOR}_$env{ID_MODEL}_$env{ID_SERIAL_SHORT}-$env{ID_INSTANCE}", \
  SYMLINK="disk/by-path/$env{ID_PATH}", \
  SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"

After a reboot, the OMV device list looks like this and I get the following udevadm outputs (see below).

Describe alternatives you've considered

N/A

Additional context

udevadm outputs for /dev/sdb and /dev/sdc

DEVPATH=/devices/pci0000:00/0000:00:15.0/usb2/2-1/2-1.1/2-1.1:1.0/host1/target1:0:0/1:0:0:0/block/sdb
DEVNAME=/dev/sdb
DEVTYPE=disk
DISKSEQ=2
MAJOR=8
MINOR=16
ACTION=add
SUBSYSTEM=block
TAGS=:systemd:
ID_BUS=usb
ID_MODEL=TR-002_DISK00
ID_MODEL_ENC=TR-002\x20DISK00\x20\x20\x20
ID_MODEL_ID=0012
ID_SERIAL=QNAP_TR-002_DISK00_WW62NQRY-0:0
ID_SERIAL_SHORT=WW62NQRY
ID_VENDOR=QNAP
ID_VENDOR_ENC=QNAP\x20\x20\x20\x20
ID_VENDOR_ID=1c04
ID_REVISION=6109
ID_TYPE=disk
ID_INSTANCE=0:0
ID_USB_MODEL=TR-002_DISK00
ID_USB_MODEL_ENC=TR-002\x20DISK00\x20\x20\x20
ID_USB_MODEL_ID=0012
ID_USB_SERIAL=QNAP_TR-002_DISK00_51323341423030393130-0:0
ID_USB_SERIAL_SHORT=51323341423030393130
ID_USB_VENDOR=QNAP
ID_USB_VENDOR_ENC=QNAP\x20\x20\x20\x20
ID_USB_VENDOR_ID=1c04
ID_USB_REVISION=6109
ID_USB_TYPE=disk
ID_USB_INSTANCE=0:0
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usb-storage
DEVLINKS=/dev/disk/by-path/pci-0000:00:15.0-usb-0:1.1:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-QNAP_TR-002_DISK00_WW62NQRY-0:0
ID_PATH=pci-0000:00:15.0-usb-0:1.1:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_15_0-usb-0_1_1_1_0-scsi-0_0_0_0
ID_PART_TABLE_UUID=a51e6e80-c2be-462b-90f9-3ac6681f854f
ID_PART_TABLE_TYPE=gpt
CURRENT_TAGS=:systemd:
USEC_INITIALIZED=6089547

DEVPATH=/devices/pci0000:00/0000:00:15.0/usb2/2-1/2-1.1/2-1.1:1.0/host1/target1:0:0/1:0:0:1/block/sdc
DEVNAME=/dev/sdc
DEVTYPE=disk
DISKSEQ=3
MAJOR=8
MINOR=32
ACTION=add
SUBSYSTEM=block
TAGS=:systemd:
ID_BUS=usb
ID_MODEL=TR-002_DISK01
ID_MODEL_ENC=TR-002\x20DISK01\x20\x20\x20
ID_MODEL_ID=0012
ID_SERIAL=QNAP_TR-002_DISK01_WD-WCC7K3LZ8T2U-0:1
ID_SERIAL_SHORT=WD-WCC7K3LZ8T2U
ID_VENDOR=QNAP
ID_VENDOR_ENC=QNAP\x20\x20\x20\x20
ID_VENDOR_ID=1c04
ID_REVISION=6109
ID_TYPE=disk
ID_INSTANCE=0:1
ID_USB_MODEL=TR-002_DISK01
ID_USB_MODEL_ENC=TR-002\x20DISK01\x20\x20\x20
ID_USB_MODEL_ID=0012
ID_USB_SERIAL=QNAP_TR-002_DISK01_51323341423030393130-0:1
ID_USB_SERIAL_SHORT=51323341423030393130
ID_USB_VENDOR=QNAP
ID_USB_VENDOR_ENC=QNAP\x20\x20\x20\x20
ID_USB_VENDOR_ID=1c04
ID_USB_REVISION=6109
ID_USB_TYPE=disk
ID_USB_INSTANCE=0:1
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usb-storage
DEVLINKS=/dev/disk/by-path/pci-0000:00:15.0-usb-0:1.1:1.0-scsi-0:0:0:1 /dev/disk/by-id/usb-QNAP_TR-002_DISK01_WD-WCC7K3LZ8T2U-0:1
ID_PATH=pci-0000:00:15.0-usb-0:1.1:1.0-scsi-0:0:0:1
ID_PATH_TAG=pci-0000_00_15_0-usb-0_1_1_1_0-scsi-0_0_0_1
ID_PART_TABLE_UUID=3bd48cd0-3858-4341-97db-9abc1904fabe
ID_PART_TABLE_TYPE=gpt
CURRENT_TAGS=:systemd:
USEC_INITIALIZED=6049449

Maybe you want to add this upstream? Let me know if you need more info.

[zsteinmetz]

Sure! It's this one: https://www.qnap.com/en/product/tr-002; the little brother of the TR-004 you added with #1532.

lsusb gives

ID 1c04:0012 QNAP System Inc. TR-002

[votdev]

Sure! It's this one: qnap.com/en/product/tr-002; the little brother of the TR-004 you added with #1532.

lsusb gives

ID 1c04:0012 QNAP System Inc. TR-002

Thx, i realized the name of the device is already mentioned in the issue title.

[votdev]

@zsteinmetz What about SMART? Does it work for the TR-002 or do we need the same adaptions as for TR-004? See

• S.M.A.R.T. support for USB multi-disk enclosure QNAP TR-004 #1302
• 778ceb1

• openmediavault/deb/openmediavault/usr/share/php/openmediavault/system/storage/storagedevicesd.inc

  Line 72 in 97b2379

  public function getSmartDeviceType() {

[zsteinmetz]

SMART doesn't work out of the box, no. I was still trying to figure out why, though.

smartctl does work with -d sat, so I was thinking about adding the following to /etc/smart_drivedb.h before submitting a ticket to smartmontools.

{ "USB: ; QNAP TR-002",
  "0x1c04:0x0012",
  "",
  "",
  "-d sat"
  },

With that, smartctl in auto mode provides me with the correct info but the OMV WebGUI seems to be stuck in a loop when trying to access SMART values. It doesn't even show my internal SSD. CPU I/O is really going up and after a while a get the following error:

Failed to connect to socket: No such file or directory

OMV\Rpc\Exception: Failed to connect to socket: No such file or directory in /usr/share/php/openmediavault/rpc/rpc.inc:141
Stack trace:
#0 /usr/share/php/openmediavault/rpc/proxy/json.inc(95): OMV\Rpc\Rpc::call()
#1 /var/www/openmediavault/rpc.php(45): OMV\Rpc\Proxy\Json->handle()
#2 {main}

Interestingly, sometimes and after waiting five minutes or so, I get the complete SMART device list in the WebGUI including the TR-002 drives, yet again accompanied by a number of CPU monitoring alerts. The Celeron J4105 should be powerful enough not to struggle with that and I haven't seen such delays with my internal drive before.

EDIT: When trying to add one of the HDDs from the TR-002 to SMART monitoring (after waiting that long time), the device field is empty. So maybe OMV still has problems with the model IDs?

Don't know if this is comparable to the problems you faced with the TR-004 but yeah, we might need some adaptations. What do you think? Let me know, if certain logs would be helpful for you. journalctl and omv-engined -d weren't overly informative, at least for me.

[votdev]

I think adding the config to the smartmontools custom database is the better approach. Additionally i would think about opening a bug-/feature request on their GitHub page so that other Qnap TR-002 will benefit from that as well. It is sad that the producers of such hardware do not take care that tools like smartmontools or other tools in the Linux environment do not know their devices by default. This would reduce troubles for their customers a lot (and projects like OMV as well).

[zsteinmetz]

So true, @votdev! Do you happen to have an idea why opening SMART and drive lists takes super long now in the OMV web GUI? It didn't before adding the TR-002 to /etc/smart_drivedb.h. And smartctl still provides the same info right away.

[zsteinmetz]

My bad, I found the problem. The delay in retrieving SMART data is not related to OMV. I used smartctl -a for testing but OMV uses smartctl -x, which is similarly slow on the CLI due to a connection time out (ATA_SMART_READ_LOG failed). Still need to figure out why this is though ..

[zsteinmetz]

Just for reference if others face the same problem: the timeout occurs because the QNAP TR-002 doesn't support multi-sector I/O (see smartmontools/smartmontools#237).

A workaround is to use smartctl -H -i -g all -g wcreorder -c -A -f brief -l xerror,error -l xselftest,selftest -l selective -l directory -l scttemp -l scterc -l defects -l sataphy instead of smartctl -x which excludes the -l devstat argument.

@votdev, would it make sense to catch such timeouts earlier so that they don't slow down OMV? smartctl only times out after about 1 min with adds up to 2 min for both drives. In such cases, a downsized second try with smartctl -a would make sure that there is at least some SMART data showing up in OMV. What do you think?

[votdev]

@votdev, would it make sense to catch such timeouts earlier so that they don't slow down OMV? smartctl only times out after about 1 min with adds up to 2 min for both drives. In such cases, a downsized second try with smartctl -a would make sure that there is at least some SMART data showing up in OMV. What do you think?

But a second call will additionally increase the delay. Doing this would mean a lot of code changes because the current implementation fully relies on the output of --xall. If some one is encouraged to do that, i'm happy to see a PR from the community to see how it works. I'm having too much other things on the plate that have more priority.

[zsteinmetz]

I don't feel experienced enough with the internals of OMV (yet) to prepare such a PR, I'm afraid. For the time being, I successfully tested the following hack/workaround. Don't know if you would advice messing around with smartctl like that but it works.

For fellow users who face a similar issue: please use this at your own risk!

Create /bin/smartctl as root, make it executable, and add the following code lines:

#!/bin/bash
sid=$(udevadm info --query=all --name=${@: -1} | grep 'ID_SERIAL=')

if [[ $sid = *QNAP_TR-002* ]] ; then
  inj="-H  -i  -g  all  -g wcreorder -c -A -f brief -l xerror,error -l xselftest,selftest -l selective -l directory -l scttemp -l scterc -l defects -l sataphy"
  args=$(echo "$@" | sed -E "s/(--xall|-x)/$inj/")
  /sbin/smartctl $args
else
  /sbin/smartctl $@
fi

This short script overrides the default smartctl command for all devices matching a specific ID_SERIAL and replaces --xall with a set of arguments (inj) that give a similar SMART output but without the connection time out. For all other devices, the arguments are passed as is.

Then add the following to /etc/smart_drivedb.h:

  // QNAP TR-002
  { "USB: ; ",
    "0x1c04:0x0012",
    "", // 0x6109
    "",
    "-d sat"
  },

[votdev]

  // QNAP TR-002
  { "USB: ; ",
    "0x1c04:0x0012",
    "", // 0x6109
    "",
    "-d sat"
  },

Isn't it possible to add the necessary command line args to -d sat. I think this structure is simply passing the -d sat to the command line args when calling smartctl with a disk that matches the given criteria specified in the struct.

[zsteinmetz]

Isn't it possible to add the necessary command line args to -d sat.

Not yet, but I created an issue at smartmontools/smartmontools#237 already. Maybe it will be added in the future.

[votdev]

@zsteinmetz This PR should be of interest to you. It reduces the number of requested data to the minimum when querying the SMART infos. Only -xall is used to fetch SMART and non-SMART data in special cases. Because of this the device overview should not throw any errors anymore in your case; there will be an error only when fetching the complete report for the Extended Information page. As a side effect, querying the SMART info for all devices has been dramatically increased.

[zsteinmetz]

Sounds great! Can't wait to test it!

[zsteinmetz]

Works like a charm. Thank you! My previous workaround is needed only for speeding up the "Extended Information" tab, which I haven't used much anyway. Ah, and manually triggering self tests still takes a while. This seems bearable given that most people use CRON jobs for that, I guess.