Linux filesystems *NOT* supported by My Cloud?


When you’re right, you’re absolutely right!

I, myself, have been involved in software QA for, oh, well, ah, longer than I’d like to admit! and it just boggles my mind.

If we grant the possibility that different processor families will bend the code in particular directions. . . And if we grant the additional possibility that porting from processor “A” to processor “B” is a non-trivial task. . .

In any event - especially in the Linux world - maintaining even a “reasonably consistent” code base should not be hugely difficult. Especially when you compare it to the headaches and issues raised when you fork the code base like this. With a little care, you can run Linux distributions that are - at the very least - functionally compatible on everything from CERN’s supercomputers to a Raspberry Pi, to a wet pancake.

Sigh. . . .

So, how do I get from where I am to where I should be?

Jim “JR”

Wise guy!

Give 'em a SMACK!! (laughing!)

1 Like

Well you could run an “sudo apt-get update” but be prepared to in all likely hood brick the My Cloud. :laughing:

One way to find where certain command files are located is to run a search for them either using SSH or via the Find Files in WinSCP.

For example using SSH one can issue the command: find / -name "fdisk" which on the v4.x firmware yields the following:

WDMyCloud:~# find / -name "fdisk"


1 Like

Does anybody know if gen 2 clouds are 4k or 64k code files. If 64k then fdisk from a gen 1 cloud could possibly copied to the gen 2 cloud. Missing libraries could be a problem. Otherwise a standard debian program could be copied to the gen 2 cloud.
In either case running fdisk on the gen 2 would just fail to run if it is the wrong version or is missing a library.

PS fdisk is not on the gen 2.

OK, here’s what I’ve got here on this beastie:

root@Storage2 /bin # help
Built-in commands:

    . : [ [[ alias bg break cd chdir command continue echo eval exec
    exit export false fg getopts hash help jobs kill local printf
    pwd read readonly return set shift source test times trap true
    type ulimit umask unalias unset wait

The /bin directory:

root@Storage2 /bin # ls
addgroup       delgroup       ionice         nice           sleep
adduser        deluser        ipcalc         passwd         stat
ash            df             kill           pidof          tar
bash           dmesg          ln             ping           tinylogin
busybox        dnsdomainname  login          ping6          touch
cat            echo           ls             printenv       true
chgrp          egrep          mkdir          ps             umount
chmod          false          mknod          pwd            uname
chown          fgrep          mktemp         rm             usleep
cp             getopt         more           rmdir          vi
date           grep           mount          sed            watch
dd             hostname       mv             sh
root@Storage2 /bin #

The /sbin directory

root@Storage2 /sbin # ls
adjtimex    ifconfig    losetup     modprobe    swapoff     udhcpc
arp         ifenslave   lsof        pivot_root  swapon      vconfig
fsck        init        mdev        poweroff    sysctl      zcip
getty       logread     mkswap      route       syslogd
root@Storage2 /sbin #

Oh, and I just noticed. . . I can’t find a 'naffing on/of button on this beast! So, in order to power this beastie down, I have to log into its webmin page? (or the SSH shell?) Sheesh! (shaking head. . .)

The lack of an on/off button within the Dashboard is a well known issue discussed in several prior threads. the solution is to either use the WD Access program or issue the shutdown command via SSH.

This device as with most NAS devices, is design to be 24x7.
Whatever you do, do not just pull the power plug, since there is a mechanical hard drive.

It can be done either via dashboard or CLI as specified on previous Bennor’s post

As a guy I knew a long time ago used to say: “Not so, Buffalo Breath!” :wink:

This is true, and ONLY true, if you are lucky enough to have a system with the 4.n firmware in it. The newer 2.n firmware devices do not, repeat NOT, have the ability to safely shutdown the device at all!

Viz.: My posting at Safe shutdown

I know this is way off topic, but it’s this kind of horse-hooey that makes me want to find whoever was responsible for this debacle, and CHOKE THE [snap!] OUT OF HIM!!

I have an ancient My Book World (blue rings edition) that, at the very least, has a power button. Of course, the Einsteins that developed the firmware for this beastie designed it so that the power lights go off first - making the user think it’s off - about two minutes before it has truly shut down. Result: Many borked My Book World systems, (including mine!), and a while slew of dissatisfied customers.

In my case, I solved the problem with a red LED wired across the +12v power to the hard drives in my device. When the LED is off, I can safely shut down power to it.

(fume, fume, rant, rant. . . .)

Jim “JR”

p.s. I’m still experimenting with the USB stuff.

The firmware file for the 2.n systems is 106 megs in size.

If what I am thinking is correct, you’d have to copy the “busybox” file to the other system, assuming that it will work on that processor.

Jim “JR”

Just to be sure: have you tried the shutdown which is supposed to be possible from the ‘User’ ‘information icon’ at the top of the Dashboard (the head icon)? That’s what the user manual says is possible.

That does not exist in the current 2.n firmware.


Using the method suggested by Domemvs,

. . . the machine appears to shut down, but does not appear to cleanly unmount the filesystem first, resulting in a “Power” warning in the webmin page when you log in again, and it spends a while fsck’ing the system.

More research is needed.

Jim “JR”

You don’t need to copy busybox. The gen 1 cloud does not have busybox. You would just copy fdisk from the gen 1 to the gen 2. Try to run it. If it works good.
If you look at the files in the /bin /sbin /usr/bin and /usr/sbin most will be a symbolic link to busybox. On the gen 1 they are all seperate files. The problem is that the gen 1 is compied wiht 64k page size. The standard Debian is compile with 4k page size. If you know someone with a gen 1 cloud get the fdisk from them and name it fdisk64k then get the standard fdisk and call it fdisk4k. Check each one. The thing that may happen is that you will have a missing library.



You get the Golden Kewpie Doll! :laughing:

Completely nuking, (as in “dd if=/dev/zero of=/dev/sd[x] bs=8M”), repartitioning, and re-creating the ext4 filesystem solved the problem, (emoticon of smiley-face scratching head in wonder), and I think there’s more going on here than just a missing power switch.

I do not have the time right now to dig into this in the big way, however there should be (with the emphasis on the “should be” part), no reason why everybody and his uncle’s brother will mount a device, and the My Cloud won’t.

Obviously, more research, and perhaps a firmware update, is needed.

I’m being shipped overseas in almost exactly 48 hours, and I have to be “ready to deploy” by 0700 on Friday, so I might not get much more time to play with this until I’m feet-dry on the other side. That is, God willlin’ an’ the Creek Don’t Rise! :slight_smile:

This thing is fun, and despite the fact that I want to STRANGLE both the Dev and QA teams, I am having fun with it. I have it bung-full with just short of 6T of stuff, and I’m bringing an empty 3T USB “outrigger” drive with it.

Massive Kudos and huge thanks to everyone who has helped, (make that read “put up with”), me during this odyssey.

Jim “JR”

This has been discussed before. While the v2.x user manual claims in two separate places that there is a shutdown button on the Dashboard. Fact is there is currently no shutdown button on the Dashboard. Stupid and something you’d figure they’d fix ASAP. But they haven’t.

Glad it worked. Seems the My Cloud has trouble with certain hard drive partitions that only repartitioning fixes.

When we last saw our Fearless Hero, he was commenting within the thread Safe shutdown about how to shut the My Cloud down without trashing the hard drives. . . .

As I noted there, there is a very cleverly hidden binary command called (drum-roll please!) “halt”. As in "smack your head with your palm “halt” "

If there was a “Doh!” emoticon, I’d be using it now.

The way you use it is from within a SSH shell - log in, and then type the command “halt”. Hit the enter key, and watch the lights on your My Cloud unit do their Death Dance as it (gracefully!) shuts itself down, without trashing the hard drives.

Once the front panel light goes off, the filesystems are unmounted, drives parked, power removed, and it’s ready and raring to be thrown into a duffel-bag and shlepped to God Only Knows Where.

Jim “JR”

p.s. Why they can’t link a button from the Webmin page, or from within the totally useless Windows app, to the obviously existing “halt” function is beyond me. When I get the chance, maybe there’s a way to edit the dashboard page to add a button that links to the halt command, 'eh?

See you all on the other side!

Jim “JR”

Going back to the “not mounting USB drives with filesystem [ blah-blah ]” discussion. . . .

Looking at a drive that was successfully mounted on the My Cloud, discloses a hidden file named “.smbm.xml” in the root of that drive. Examination of that file discloses that it is apparently a fragment of a samba.conf configuration file for SMB. This file contains information about how the My Cloud will mount and expose the drive for use when plugged in.

I have not confirmed this, but there might be another explanation to the failure-to-mount issue:
What if, for whatever reason, the My Cloud does not have permission to write to the root of the USB device? In that case, it might not be able to create - or update - the smbm.xml file, and as a consequence it fails to mount the device. Even though normally it would be able to mount it just wonderfully.

Again, I do not know if this is true for a fact and I do not have time to experiment with it at the present time, though it would be interesting to play with.

One good test would be to take a drive that - for whatever reason - fails to mount, and then run a “chmod 777 [path to drive]” command. Or a “chown” to whatever the owner of the filesystem is. (or both?)

If anyone gets time to play with this, try it and let me know if that helps.


Jim “JR”

Sigh. . . .

If it were only that simple. As I have discovered, something like 99.9999% of the software on the 2.n version systems is embedded in the firmware, within a write-only squashfs filesystem. With that the ability to make modifications to the filesystem are (virtually?) impossible.

Jim (JR)

In both the gen1 and gen2 system the software is embedded in the firmware. Only those things that other people
install in the gen1 is outside of the firmware. The gen1 uses a Debian system compiled with 4k page size on firmware version 3.xx. The firmware version 4.xx uses 64k page size. On the gen1 system the Linux commands are seperate programs. On the gen2 a lot of the Linux commands are built into a file called busybox. Also the gen2 systems have a limited number of libraries. One can copy a program from a standard Debian Linux system and copy it to a gen2 system. The odds of that program running are slim. Since the necessary libraries may not be installed.