Hi all,
i have searched the forums already but cant seem to find the answer… i have a external USB chassis that houses 5 disks, i would like to create a RAID set on this for archival data (speed isn’t an issue even though it is USB3)… but all the disks don’t have serial numbers when installed in here… i have seen the article on fake serials etc… but am not sure how to apply this in the real world…
any help would be great!!
@Brett_Abela A very belated welcome to the Rockstor community.
In this context it is risky and tricky to apply additional udev rules as it is already the case that udev can’t tell them apart: udev authors chose serial for a reason. The rules would have to use some other element than serial with with to assign a serial after the fact as it were. That might be usb bus id or the like but then switching drive locations would break things, potentially badly.
To my thinking this would make the described hardware inappropriate and most likely unusable with Rockstor. We have seen enclosures like this before and it’s not a good show that they hide their hosted drives serials, or plain lie about them, and consequently upset udev’s ability, and consequently Rockstors, to tell them apart.
Can you say the make and model number of this device?
And what is the output of the following command when the drives are in the enclusure:
lsblk -P -o NAME,MODEL,SERIAL,SIZE,VENDOR,TRAN,TYPE
Linking to your other similar post on this issue from way back (sorry I missed that one):
Thanks and hope this helps.
NAME=“sdf” MODEL=“0041-2EL11C " SERIAL=“000000000000” SIZE=“5.5T” VENDOR=“ST6000VN” TRAN=“usb” TYPE=“disk"
NAME=“sdd” MODEL=“ST5000DM000-1FK1” SERIAL=“W4J14Q3K” SIZE=“4.6T” VENDOR=“ATA " TRAN=“sata” TYPE=“disk"
NAME=“sdb” MODEL=“Elements 10B8 " SERIAL=“575856314539343235335A56” SIZE=“931.5G” VENDOR=“WD " TRAN=“usb” TYPE=“disk"
NAME=“sdb2” MODEL=”” SERIAL=”” SIZE=“7.8G” VENDOR=”” TRAN=”" TYPE=“part"
NAME=“sdb3” MODEL=”" SERIAL="" SIZE=“923.2G” VENDOR="" TRAN="" TYPE=“part"
NAME=“sdb1” MODEL=”" SERIAL="" SIZE=“500M” VENDOR="" TRAN="" TYPE=“part"
NAME=“sdg” MODEL=“000-1F2168 " SERIAL=“000000000000” SIZE=“3.7T” VENDOR=“ST4000DM” TRAN=“usb” TYPE=“disk"
NAME=“sde” MODEL=“ST5000DM000-1FK1” SERIAL=“W4J14QJT” SIZE=“4.6T” VENDOR=“ATA " TRAN=“sata” TYPE=“disk"
NAME=“sdc” MODEL=“ST5000DM000-1FK1” SERIAL=“W4J13QWN” SIZE=“4.6T” VENDOR=“ATA " TRAN=“sata” TYPE=“disk"
NAME=“sda” MODEL=“ST6000VN0041-2EL” SERIAL=“ZA15TQZ1” SIZE=“5.5T” VENDOR=“ATA " TRAN=“sata” TYPE=“disk"
NAME=“sdh” MODEL=“000-1F2168 " SERIAL=“000000000000” SIZE=“3.7T” VENDOR=“ST4000DM” TRAN=“usb” TYPE=“disk"
NAME=“sdh1” MODEL=”” SERIAL=”” SIZE=“128M” VENDOR=”” TRAN=”” TYPE=“part"
NAME=“sdh2” MODEL=”” SERIAL=”” SIZE=“3.7T” VENDOR="" TRAN="" TYPE=“part”
all the 0000’s are the USB attached ones…
and its an Orico 5 bay USB
@Brett_Abela Thanks for the info.
As you say it’s giving all it’s hosted disks the same “000000000000” serial numbers.
As it goes we have seen the same in a 4 bay ORICO USB 3.0 device. Must be a habit of theirs 
Pretty sure this was added after a report from forum member @beaglenz in the following forum thread:
Looking again at that thread is seems the long serial made up by udev, presumably by adding on the usb sub device or something was then unique, if only by drive location rather than actual drive (would need confirming before actual use as it may just be order of appearance which could change between boots and would thus be no good at all) . And in turn udev was at least able to construct by-id names with the 4 drive version.
On a hunch of mine could you give us the output of the following commands:
ls -la /dev/disk/by-id/
and:
udevadm info --name sdg
and
udevadm info --name sdh
But in those last 2 commands please replace that sd# type name with that given to the drives in the enclosure that have the suspect serial, these types of names can change from boot to boot and so a re-run of the lsblk command should tell you what the names are on a particular boot.
I have in mind a potential ‘dirty hack’ that might get you up and running (As long as we keep it between ourselves of course 
): that is if you are desperate to use that enclosure (although I would still not recommend it’s use) and are happy to do a little code editing; and to have to repeat it after every update!!! Lets see how the output of thoses commands looks first as it may not be possible at all (as opposed to just not recommended).
Cheers.
lrwxrwxrwx 1 root root 9 Jan 22 14:09 ata-ST5000DM000-1FK178_W4J13QWN -> …/…/sdc
lrwxrwxrwx 1 root root 9 Jan 22 14:09 ata-ST5000DM000-1FK178_W4J14Q3K -> …/…/sdd
lrwxrwxrwx 1 root root 9 Jan 22 14:09 ata-ST5000DM000-1FK178_W4J14QJT -> …/…/sde
lrwxrwxrwx 1 root root 9 Jan 22 14:09 ata-ST6000VN0041-2EL11C_ZA15TQZ1 -> …/…/sda
lrwxrwxrwx 1 root root 9 Jan 22 14:25 usb-ST4000DM_000-1F2168_000000000000-0:1 -> …/…/sdg
lrwxrwxrwx 1 root root 9 Jan 22 14:16 usb-ST4000DM_000-1F2168_000000000000-0:2 -> …/…/sdh
lrwxrwxrwx 1 root root 10 Jan 22 14:16 usb-ST4000DM_000-1F2168_000000000000-0:2-part1 -> …/…/sdh1
lrwxrwxrwx 1 root root 10 Jan 22 14:16 usb-ST4000DM_000-1F2168_000000000000-0:2-part2 -> …/…/sdh2
lrwxrwxrwx 1 root root 9 Jan 22 14:45 usb-ST6000VN_0041-2EL11C_000000000000-0:0 -> …/…/sdf
lrwxrwxrwx 1 root root 9 Jan 22 14:09 usb-WD_Elements_10B8_575856314539343235335A56-0:0 -> …/…/sdb
lrwxrwxrwx 1 root root 10 Jan 22 14:09 usb-WD_Elements_10B8_575856314539343235335A56-0:0-part1 -> …/…/sdb1
lrwxrwxrwx 1 root root 10 Jan 22 14:09 usb-WD_Elements_10B8_575856314539343235335A56-0:0-part2 -> …/…/sdb2
lrwxrwxrwx 1 root root 10 Jan 22 14:09 usb-WD_Elements_10B8_575856314539343235335A56-0:0-part3 -> …/…/sdb3
lrwxrwxrwx 1 root root 9 Jan 22 14:09 wwn-0x5000c5008bb8454c -> …/…/sdc
lrwxrwxrwx 1 root root 9 Jan 22 14:09 wwn-0x5000c5008fd5bce5 -> …/…/sde
lrwxrwxrwx 1 root root 9 Jan 22 14:09 wwn-0x5000c5008fd5e0ec -> …/…/sdd
lrwxrwxrwx 1 root root 9 Jan 22 14:09 wwn-0x5000c50093684785 -> …/…/sda
udevadm info --name sdg
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/host7/target7:0:0/7:0:0:1/block/sdg
N: sdg
S: disk/by-id/usb-ST4000DM_000-1F2168_000000000000-0:1
S: disk/by-path/pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: DEVLINKS=/dev/disk/by-id/usb-ST4000DM_000-1F2168_000000000000-0:1 /dev/disk/by-path/pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: DEVNAME=/dev/sdg
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/host7/target7:0:0/7:0:0:1/block/sdg
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_INSTANCE=0:1
E: ID_MODEL=000-1F2168
E: ID_MODEL_ENC=000-1F2168\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0539
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.1:1.0-scsi-0:0:0:1
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_1_1_0-scsi-0_0_0_1
E: ID_REVISION=0X06
E: ID_SERIAL=ST4000DM_000-1F2168_000000000000-0:1
E: ID_SERIAL_SHORT=000000000000
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=ST4000DM
E: ID_VENDOR_ENC=ST4000DM
E: ID_VENDOR_ID=152d
E: MAJOR=8
E: MINOR=96
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=1710737
@Brett_Abela Thanks for the info. From:
We see each of the 3 drives in the Orico enclosure has a by-id name, which is part of the problem sorted (no serial devices get no by-id name at all), but what we now need to know is if those names are assigned on a first come first served basis, which may change from one boot to the next, or as I am hoping, on a bay/enclosure-slot basis. Can you see if you can establish this? Ie you have 2 different models of drive there and given the enclosure rather unhelpfully obfuscates the actual serials we can’t tell the difference by name alone from the 2 similar models (the essence of why serials are relied upon in Rockstor and by udev). If you can establish that a bay in that enclosure always get the same number assigned to it, ie the “0:0”, “0:1”, “0:2” bit at the end assigned by udev to it’s “ID_SERIAL” element (and in turn used in the generated by-id name, then we have a chance.
So Rockstor can usually track a drive across various different connection methods because it uses the serial, baring serial obfuscation mechanisms of course: But given this enclosure spoils that it can’t. However if the enclosure, and it’s subsequent observation by the usb and block subsystem, is itself consistent with bay numbering then you will at least have that. I.e if a drive is not moved from one bay to the next it will always have the given say “000000000000-0:1” unique element (think those 2 same model drives where there is nothing more to tell them apart). So although less robust it is a potential, if slightly degraded’ way, of tracking a device.
Sort of it: if each bay consistently get the same 0:1 type ending irrespective of it’s content or any of the other bays content then we have a usable ‘bay stable’ system. Otherwise we do not. Rockstor attempts to track drives from their unique id (serial) up, with what this enclosure does it can only manage drives from their bay location up. That may be enough if that is in fact what’s happening here, as long as that is understood in it’s use: mostly this should be fine however.
As this is a potentially time consuming effort on both our parts please be clear on if you would like to attempt the hack path (if the above drive bay to serial mapping end up being stable)? No worries otherwise, but from my perspective it’s the second time such an enclosure has come up on the forum and they look like nicely build pieces of equipment so if we can find a way to accommodate them (if possible), given the above bay level tracking rather than device level tracking, and users are aware of this limitation, then it would be good all around to explore this option. And potentially add it as a ‘special case’ if the interest was there. If the given slot to serial stability is there, I think I see a way to make this so.
Hope that helps and let us know you findings, if you have time of course, on that bay to serial stability (irrespective of other bays content).
N.B. Be sure to also test with the first bay empty, ie do the serials then start from ‘0:1’ and not the so far observed ‘0:0’.
Thanks.
Hi, apologies for resurrecting an old thread but this one looked unresolved. I have an 8 bay Orico unit which has the same problem. I can’t find anything about firmware updates for the JMS567 controller that could address the problem.
To answer your question on whether the “0:0” or “0:1” is assigned by the bay of the drive. Sadly not. The last digit sequentially increases for each drive detected regardless of the bay that it is located in. Which would make the enclosure suitable for Rockstor.
@outicnz Welcome to the Rockstor community.
OK, that’s a shame as from my last post this means that these devices are unusable by Rockstor. Oh well, can’t win them all. It is in my opinion a flawed design to obfuscate a drives only unique element (pre-formatting).
Thanks for confirming this devices workings re the udev names. Most helpful. Funnily enough I was wondering about this just the other day, since it was left unresolved prior to your input.
Do please keep us updated on an other future firmware or internal/external switch option that might change this behaviour as then we could look to accommodating their behaviour if it turned out it was then possible.
Hello, also sorry to resurrect an older thread, but I’ve just started using Rockstor, and have been trying all day to get a 4 drive bay to work with it, when I came across this and anther post.
I do, however, see that the drives are assigned a number 0:0, 0:1, 0:2, 0:3 when they are attached, but have no idea if this is fixed, or can change on reboot.
I love these drive bays, and have 2 of them actually, but hate the thought that I potentially can use them with Rockstor. So any help is figuring out how to provide something unique for these drives is much appreciated.
Just tell me what you need from me, and I’ll do my best to get it back to you.
@bmcgonag Welcome to the Rockstor community.
No worries on that account. The more interested input the better.
Re:
To this question, it looks like we have already had the answer from @outicnz Re:
And from this it pretty much guarantees, on startup, this element of the drive name is arbitrarily assigned. As such it is unreliable and so can’t be used by Rockstor as a reliable drive ‘tracker’.
It may be that there are setting on these enclosures, or firmware fixes etc, that can lead to a reliable naming mechanism. We absolutely need a reliable way to identify (read track) an individual drive regardless of it’s content in order to do the thing we try to do. If you can find a way to retrieve the serial number of a drive whilst it’s within one of these enclosures then it should be possible to first recognise when a drive is within one of these and second to singularly identify that drive by a special case instigated by the enclosure indicator.
So as per my comment to @outicnz
Sorry for the bad news.
I’d suggest, since you have local access to one of these enclosures, that there is an opportunity to confirm @outicnz findings re:
and
to which @outicnz’s understanding is that these names do not represent slots. In which case the next immidiate hope might be to modify/install udev rules that do give us drive or at least bay tracking capability. But even if we got bay tracking stability, if one move a drive from one bay to another it’s serial number would change. That, to Rockstor, would mean the original appearance of the drive (in it’s first bay) would disappear and a new drive would appear. This does not lend itself to stable device tracking. Let us know how you get on. Also it may well be worth confirming this behaviour re changing serial numbers as per drive time start-up in our Rockstor 4 release which has a far newer kernel. Things may have changed in the mean time in how the linux kernel and udev treat/see these devices:
See:
and it’s linked and associated GitHub repo:
Hope that helps.
Hello there!
I think I have an interesting input at that matter. I’ve got a Yottamaster Y-Profession/Y-Pioneer 5 Bay External Hard Drive Enclosure (no-RAID USB 3.0 A/B variant also known as PS500U3) – I’ve got it from a second hand, but it is apparently similar to
Filled it up with 5 Seagate ST4000NC000-1FR168 drives, tried to use with Rockstor and… stumbled upon the all same (all zeros) drive serial number problem. BTW my enclosure seems to be based on ORICO as well:
rockstor:~ # lsusb
Bus 003 Device 002: ID 125f:a578 A-DATA Technology Co., Ltd. ORICO USB Device
...
and, yes, the by-id name seems to be assigned same way in my case. I can confirm the following
In my PS500U3 the scan appears to go top-down in terms of bay order. Anyways, I have to agree with
But I’ve found that hdparm returned Serial Number is actually ok! It’s exactly same as at the drive’s label (the factory printed sticker I mean) in my case. Which would make such Serial Number a reliable drive tracker IMHO.
Walking this way (hinted with @phillxnet’s mention of udev / thanks @phillxnet!) I was able to coin a dirty workaround. Here it goes:
/usr/lib/udev/orico_id with the following juice:#!/bin/sh
SERIAL=`expr substr "$(/sbin/hdparm -I $1 | grep Serial\ Number)" 22 8`
SERIAL_HEX=`echo -n "$SERIAL" | xxd -ps -c 200`
EXPORTS=`/usr/lib/udev/scsi_id --export --whitelisted -d $1`
EXPORTS="${EXPORTS/ID_SERIAL=33000000000000000/ID_SERIAL=ORICO_hdparm-sn-$SERIAL}"
EXPORTS="${EXPORTS/ID_SERIAL_SHORT=3000000000000000/ID_SERIAL_SHORT=$SERIAL}"
EXPORTS="${EXPORTS/ID_WWN=0x3000000000000000/ID_WWN=0x$SERIAL_HEX}"
EXPORTS="${EXPORTS/ID_WWN_WITH_EXTENSION=0x3000000000000000/ID_WWN_WITH_EXTENSION=0$SERIAL_HEX}"
echo "$EXPORTS"
/usr/lib/udev/rules.d/60-persistent-storage.rules:# Workaround for ORICO USB enclosure disk serial number problem
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}=="*000000000000000000000000000000*", IMPORT{program}="orico_id $devnode", ENV{ID_BUS}="scsi"
I hope the workaround may help other Rockstor and ORICO (or Yottamaster) users.
Rockstor developers, please consider implementing a clean fix based on the hdparm finding. I offer my help.
Happy New Year, Everyone!
PS I’m on Rockstor 5.0.5-0 Testing / openSUSE Tumbleweed: 20230313 (Linux: 6.2.4-1-default) in a Proxmox 8 VM
Hi, I also encountered this problem with orico dock station.
I tried creating mentioned scripts but problem is still here. I suppose this is due to my serials altought are same for different HDDs, but they are not zeros, so I have to correct script, but I cannot figure out how.
Can you help me, @Greg_R?
in case if needed - my serials are “DD5641988389F”
@DarkDeny, welcome to the Rockstor community.
What is the output of
hdparm -I /dev/sd? | grep 'Serial'
(assuming your devices have the nomenclature sdX)?
They all show up with the same number (the one you posted above)?
Not that it makes much of a difference for these scenarios, but can you also put the Rockstor version number?
I tried to check this out, but got -bash: hdparm: command not found
RockStor version is: ROCKSTOR 4.5.8-0
ah, yes, the package needs to be installed first (which would also be a pre-requisite for any of Greg_R’s scripts to work.
zypper in hdparm, I believe it is.
Actually the package was in place, I missed that I need to sudo running that command.
Output was: Serial Number: 78EWNTNAS
You currently only have one drive? Or did all drives return that same serial number?
yes, I disconnected second drive so that I can have my share available on my PC.
ok, I guess the question now would be, if you connect the second drive again, and run the command, will you get the same output for each of the drives (I would expect not). You might want to run this directly from the terminal, rather than through the Rockstor WebUI to eliminate any other factors …
If they are different, I would then try to run the script from above orico_id /dev/sda (and then for the other device, assuming it might be /dev/sdb and see what the outputs are for each.
If they are different, I would think the udev rule should work, but you already said it does not seem to.