I was using an external USB drive formatted as VFAT and the My Cloud had no issues accessing it. However, when I reformatted the same drive as ext4 from my Linux workstation, it no longer recognizes the drive despite /proc/filesystems claiming to have ext4 support. In dmesg I see the following error:
I see several other errors as it appears to try to mount as JBD2, FAT, and ufsd. I explicitly unmounted and checked the drive from my workstation to make sure everything was ok before attempting to connect it to the My Cloud.
I tried to fsck the drive manually on the My Cloud, but it fails to find the proper fsck utility:
fsck (busybox 1.20.2, 2015-02-25 14:32:43 CST)
fsck: fsck.auto: No such file or directory
I tried looking for fsck.ext4 but the only fsck I see (in /sbin/) is fsck → busybox.
What’s going on here? Why can’t I access my drive?
Oh, that’s interesting. Is this somehow related to the large block scheme built in the kernel? I don’t suppose there is any way around this is there by compiling a new kernel module or something? I’m trying to remotely sync an ext4 filesystem on an identical drive (via rsync) and while HFS+ is probably the closest to being compatible I’m still concerned about the issues this would pose.
Officially the supported formats are what is listed in that WD Support Knowledgebase link.
Unofficially there might be ways of modifying the My Cloud OS, depending on what My Cloud model you are using, to support additional formats. Primarily this may be done by using a different OS on certain My Cloud models. See the following discussion that some have successfully implemented (often after much work) to run different OS’s on their single bay or certain multi bay My Cloud models.
The main issue with the single bay My Cloud models is the modified firmware that WD created as the OS. You cannot do an apt-get to install modules on them as they typically brick the device. One can try building their own modules or modifying the existing ones by compiling their own OS using the GPL firmware WD makes available on the WD Support page for each My Cloud model. But again it takes time, effort and above all knowledge to successfully do so.
There are no issues using rsync to copy data to or from a My Cloud device to another NAS other than the need to generally have to do it via SSH. I’ve done it between a Synology NAS and a first gen single bay My Cloud. Its once again an unofficial method, not one endorsed or supported by WD with respect to single bay My Cloud models.
Hi Bennor,
Thanks for your reply, I’ll definitely take a look at the link you provided. At some point in the past I installed the latest development tools on the device and actually got node.js to compile to the point where node itself would work - not npm much less things like node-gyp, and you’re right it was a lot of work.
What specific My Cloud device do you have? Outside of the GPL firmware files there are no official “development tools” for the single bay/single drive My Cloud models. If you have a multi bay My Cloud model you should see the specific subforum for it where people who are more familiar with that device may be able to assist with further questions.
It’s a single bay “Gen 2” device with the “v2” firmware. At the moment I’m having trouble finding where I actually installed the tools on the device, but it was the Synology toolchain (I posted a thread about this in 2017).
I should also add that the link in that page contradicts the owner’s manual (http://products.wdc.com/library/UM/ENG/4779-705147.pdf) “For use with My Cloud devices on firmware 02.xx.xx” (which is what my device has). Specifically, on page 85, it says:
The My Cloud device supports the following formats for externally attached USB drives:
FAT32
NTFS (read and write capability)
HFS+J
Ext2, Ext3/Ext4
XFS
So uh… I would still like that ext4 support as promised in the manual…
You are assuming that manual is correct or accurate. It isn’t. There are a number of errors in the v2.x single bay user manual. For example there is mention in the user manual of a “shutdown option”. WD removed that option in the v2.x firmware on the single bay unit. Many past discussions (and complaints) about it going back years. Then there is “Chapter 10 Safepoints”. No such thing in the v2.x firmware, instead its called “Backup”. Fact is the v2.x single bay user manual isn’t accurate on what options or features the unit has.
If there is an incompatibility, it would be with the automount scriptlet/commandlet itself, and not the actual mycloud’s loaded filesystem drivers.
Still, I vaguely remember having EXT3 work fine. I had nothing but trouble with the baked in btrfs driver. It causes segfaults in the mycloud the instant it attempts to touch a file system.
From the sound of the issue, it sounds like EXT4 volume being detected as EXT3 by the automounter, and the EXT3 driver going “Hell no, I won’t go.” I have vague memories of experiencing this myself in the past.
I would just recreate the volume with EXT3, and call it a day, if you absolutely need *nix style file security descriptors.
