iSCSI on Gen2 (parts 1 & 2) Hosting & Mounting Targets

Ok. Today I spent a great deal of time messing with iSCSI on the gen2. So far, I have gotten it to host a target successfully. (I have connected to the hosted target, created a file system, copied files.)

I have now figured out how to get Virtual Volume manager working (kinda? Needs more testing), as well, and I have added some improvements to the init script hijack to make things work more as you expect them to.

What you need:

  1. you need some files from the MyCloud Mirror source package. Namely, some of the contents of the cramfs folder. The MyCloud Gen2 lacks certain administration programs needed for the web interface to function. (It calls iscsi_mgr.cgi, which wraps some console commands. Those commands are missing.)

  2. You need Fox_Exe’s WD_Crack package. You will also need to edit it a bit once it is installed. Specifically, you will need to have certain files copied into the root filesystem by its init script, and you will need to change two lines of his define.js file so that your MyCloud reports itself as a MyCloud Mirror. That will turn on the Storage tab, and turn on iSCSI options.

Now, the juicy details.

  1. either extract the following files from the MyCloudMirror GPL sources yourself, or pull them from here:
[I have broken it up into subfolders, sorry if that is annoying.]


  1. sftp into your mycloud, and create a folder on /mnt/HD/HD_a2 called “extras”. Place additional subfolders inside, called ‘etc’, ‘usr’, ‘bin’, and ‘sbin’, then create additional subfolders under usr containing ‘bin’ and ‘sbin’. These will contain whatever special goodies we want to get copied back into the ramdisk after a reboot, and are named appropriately.

  2. copy the above files into the following folder we just made:

  3. locate Fox_exe 's WD_Crack package on your hard drive. It is located at /mnt/HD/HD_a2/Nas_Progs/WDCrack . Inside you will find the following files:


In define.js, we need to make the MyCloud think it is a MyCloud Mirror. We do that by changing the top two lines, so that they read as follows:

var DEV_NAME = " [WD My Cloud EX1100 ™]";
var MODEL_NAME = "BG2Y";

in, we want to hijack the init script to have it restore our binary payloads, which are needed to turn on iscsi. Change it so that it looks a bit like this:



ln -sf $INSTALL_DIR/define.js $ORIGINAL_FILE
ln -sf $INSTALL_DIR/web /var/www/WDCrack

## Begin binary copy hijack
cp -R /mnt/HD/HD_a2/extras/* /
## End binary copy hijack

## Initialize iSCSI stuff
iscsictl --init

## Initialize virtual volume manager stuff
vvctl --init

then reboot the mycloud.
When the mycloud comes back up, you will have access to the [storage] tab, and the iscsi section for creating targets will be active, and functional.

For the curious, the mycloud stores the target LUNs as image files, contained in /mnt/HD/HD_a2/.systemfile/iscsi_images .

It appears to be damned skippy fast too. I copied a 600mb disk image to a 1gb iscsi lun, at over 200mb sec from a windows host. (Configured with iscsi initiator)


Hi there,

Thanks for sharing this with the community, please keep us posted on your progress.

good job @Wierd_w!!

Perhaps if I kept my new EX2 that arrived today I might have two spare 8TB clouds for experimentation :stuck_out_tongue:

Next I need to get virtual volume manager up, then I need to get the RAID function up. I suspect that it is more missing admin programs underneath preventing them from working, but I need to identify the right ones, and what they need anywhere else in the file system. The hijack I am using here is capable of restoring config files in /etc, so I have a good chunk of the battle won already.

Now I need to wait for some more time off, so I can continue my hacking efforts. Then I can do that experiment with raid 1 between two myclouds, with one member of the raid being an iscsi target hosted by the remote mycloud. Kind of a poor man’s DR Site solution.

yup exactly what I needed… but I can only do that if I keep the EX2 to store my data somewhere, but if I keep the EX2 I would already have a mirror drive and would not have the need to hack my clouds :stuck_out_tongue:

You can still be of use in these endeavors. I dont have a REAL EX2 or Mirror. As such, I have to rely on pulling source packages to get at the files that ship inside those, and often certain config files are not present in the source packages.

If you have a REAL EX2, I might ask you some time for certain config files so I can bastardize them for use on the Gen2 single bay myclouds.

(It may sound stupid to be working to get RAID enabled on a device with only a single drive, but when you throw remote iSCSI LUNs and USB hosted disks into the mix, it becomes useful to have. WD should have enabled it by default if you ask me.)

my sentiments exactly…

in fact… it is in the Cloud ideas forum…

I would keep the EX2.

It already supports creation of iSCSI LUNs, and already has a functional RAID manager. Presumably, it already has functional virtual volume manager for mounting iSCSI LUNs as well.

With the hack I have already done on the Gen2, it can mount such a hosted LUN, and should be able to present it to the RAID manager as a valid volume for RAID creation.

That means you could use the EX2 as the main communication point, and have it doing the poor man’s DR to the remote MyCloud Gen2, by mounting the ISCSI LUN it his hosting and using it in a RAID group as RAID1.

Keep the EX2. :stuck_out_tongue:

Please send $1k and I’ll keep it :stuck_out_tongue:

and if I do keep it, just like my answer to Rac on answering his gen2 questions, I told him to get his own gen2.

Yes I like the fact that ex2 has iscsi even though I need to get a 3rd party initiator for my Mac :stuck_out_tongue:

I’ll sleep on it…

See my other post about this…

Thank you!
Couple of requests. Could you guys point me to the thread on installing the gen2 crack (i cant find it and i think it would complete the thread) BTW, the installation of Fox’s crack is because of only a few files needed or it’s more than a few that are needed? Also all this you’re doing works with the latest firmware? (2.30.165) I wouldn’t need plex since if i can use the gen2 as a iscsi target I’d use the Plex from the ex2 (once the ex2 is the initiator and the gen2 the target). BTW I do plan on keeping the ex2 ultra, so if you need files from it just let me know. It might take a little while but i don’t have a problem with that. Thanks again for your work!

See the WD MyCloud Gen2 - Enable apps install tab + Apps! discussion that is currently a few threads down from this current thread:

I nearly have virtual volume manager working. It is… cranky. Probably because I am trying to connect to the target hosted by the same mycloud. (Mycloud is both target and initiator-- it hangs up the connection unless you run through the dialogs REALLY fast-- then it adds it to its connection list, and then it can connect fine. Not sure what is going on there.)

When it mounts an iscsi lun, it gives it a /dev/sdb type block device. Neat. That means the raid manager wont know any different. :stuck_out_tongue:

As for your question-- See the VEEERY first post in the “install apps” thread. It gives the instructions you need to do to get the mycloud to accept an installable package. (that package being wdcrack. See the google drive or other mirror Fox_exe has provided there. It contains the necessary package file.)

It seems that the latest firmware is cranky and wont let you install apps without some lovin though. See way later in the thread for some work arounds.

1 Like

Well @Wierd_w, I’m sorry to say that I won’t be keeping the EX2 simply for the reason that it won’t fit my shelf :stuck_out_tongue: where-as my single drive clouds do and they look like books since I put covers on them.

However I’ll keep an eye open on your post and will consider it once you get all the wrinkles out.

Keep up the good work @Wierd_w!!

Ok, Further examinations of the built in RAID manager leads me to believe that it is either crippled beyond repair, or at the very least is not worth the effort.

Given that we have to use a script hijack to initialize iscsi and pals anyway, we can manually rebuild an array, mount it someplace, and make a share folder location for it in the same script, and do it that way. Arguably with much greater control.

Administration of the resulting array would require manual prodding with ssh however. See my prior posting about having fun with software raid for details.

Thanks, anyways. If be interested in your solution of mounting and having a script. (Btw, you mean to keep all your drives in sync, right?)

you had my hopes up and now I’m disappointed :frowning:

My ex2 is still sitting on my couch waiting for it to be returned to Best Buy. Must I really throw out 1k to get my wish :stuck_out_tongue:

I did look at Amazon and they are still selling the old curvy matching USB3 My Book 8TB on which I can build a raid based on your “Fun with software Raid on Gen2”. Could you kill the auto mount instead so that 1k partition is not needed? or dismount the auto mount and remount it as a /dev/md* device?

I never tried attaching a device without a partition table. If there is NOTHING for the automounter to grab, it should not make the device busy. I will test that shortly in a few hours. mdadm allows you to put WHOLE DISKS (without partition tables) as RAID members. The automounter likely wont be able to determine file system type on such RAID member disks, and so be unable to find a partition table, and thus have nothing to do with the disk. I will do experiments/tests tonight.


Yes. Using whole disk without partition table seems to make the automounter give up in frustration. (It sure complains A LOT in dmesg too.) Does not leave the base block device busy. Can use the whole volume. Getting the iscsi target and the local disk to be the same size is tricky though. I see that the iscsictl program has a “sectors” command that is meant to be aimed at a LUN. I presume this is to set it to a defined size in sectors, but might also set the sector size. This could be a problem for your OCD, because the raid device wlll be sized for the smallest disk in the array. This means either slightly over-provisioning the LUN, or not using the full size of the USB disk… Either I expect will upset your OCD, if you get upset over a teeny 1k partition. I will investigate further to see if I can get the iscsi LUN to be created/resized at a precise size in bytes, or sectors.

That said, I was able to create a new /dev/md* device, and attach both the blank USB stick I am using as the guinea pig, and the test iscsi LUN in a mirrored raid, (and using the debian chroot, partition it and format it), then mount it at a freshly created share by using the empty share location as a mount point.

I will now restart the NAS and see if the created mirror data on the USB drive causes issues with the automounter. If it manages to avoid getting grabbed up (mdadm writes a bunch of configuration metadata to the start of the drive where a partition table should be, so hopefully the automounter will give up in disgust again) then I will call this experiment a total success.

Note that when creating the array, you can tell it to include some disks as hot spares, so if you are SUPER DUPER paranoid, it can automatically promote and populate a hot spare USB disk of the same size if the iSCSI LUN goes down or the main USB disk fails.)


Nope, on reboot it detects a partition and wants to mount it. I will need to find a way to programmatically tell the stupid thing to unmount the volume. Looks like it is calling /usr/sbin/ to do the mounting. The dashboard can “eject” the USB drive, which really just unmounts it, leaving the block device active. I will investigate how the dashboard accomplishes this-- Looks like it invokes yet another .cgi file. Investigating, it appears to invoke a command called usbumount that takes a coded argument. My guess is that it takes a block device ID as that argument. Now is time for sleeping though.

1 Like

your post reads like Shades of Grey for the geeks :stuck_out_tongue:

Good work though…

Ok, so far so good. I can get it to let go of the USB drives with a two liner.

umount /dev/sd*#
usbumount /dev/sd*

(where * is the block ID, and # is the partition number)

That unmounts the volume, then does the cleanup, and makes the automounter leave it alone, and shows that the device is ejected in the dashboard. It can then be meddled with by mdadm. Those two will have to be fired for every USB disk you have attached.

Another thought occurs to me though. The default restart command does not know how to deal with our array. We need to rename it (since it is a binary elf), put a shellscript in its place that does the needful for shutting down our array, THEN calls the renamed reboot binary to safely shut down. That needs to be done at bootup. (Rather, renaming the reboot binary, and then copying our safe shutdown pre-script into its place, so that when reboot is invoked, our system downs SAFELY and PROPERLY.)

exactly what I was thinking :stuck_out_tongue:

So if I buy a USB 8TB, it would raid my cloud with my USB? I know that you raided two usb drives or probably two usb partitions, but can you raid the cloud that is running with a USB drive?