Firmware 2.30.165 Discussion

That is not entirely true. My Gen2 has the rlog running every ten minutes. It currently has been sleeping since
8:20:43 the current time is 10:13:00.
What I found on the gen1 was that once the code was in cache there was no physical disk activity. But at 03:00
in the morning alot of physical disk activity was initiated and those cached programs were forced out. Then when
the system went to sleep it would end up having to bring back code that was cache before. This caused the disk to wake up. This was the major cause of the 8 second sleep.

In my case with gen2 and without cloud enabled. I only coment this line in the crontab and the disk star to sleep otherwise not. Don’t know why the different behaviour.

I’m currently runnning a script thru ssh that checks every 5 seconds to see if any disk activity has been done.
If so it displays the sda line from /proc/diskstats. It is now 10:50 and the disk is still sleeping.

Any news when they release the new version officially?

Nope

I probably wouldn’t update with this version, yet. Not that I know of anything that was wrong with it. There could have been any number of simple reasons for pulling it. Nonetheless, I’m sure a firmware update will be re-released as soon as we can get it out.

I really don’t think that’s an appropriate response.

If you decide to withdraw a build, then there’s almost certainly a good reason to do that.

So withdraw it properly, explain why, and provide reversionary instructions for anyone who has upgraded.

Really, if the ‘community manager’ doesn’t know what’s going on with the product, it’s a pretty good indicator that there is something seriously wrong with communications within the corporation.

Really not a good sign.

1 Like

@cpt_paranoia, do you need more nails? :stuck_out_tongue:

On Easter Monday…?

Can the issue be mitigated by not forwarding any ports to the My Cloud from the router and if using the My Cloud service, the relay connection service will be used. That will hide the My Cloud from the Internet.

It’s a probable work-around to the immediate issue. @Bill_S, what do you think?

I think this will be the gold version with all the bugs and vulnerabilities solved :joy: for the time they take to release.

It’ll be slower, but, yes, it’s a definite work-around.

1 Like

So no need to not use the My Cloud storage devices while awaiting a fix. :slight_smile:
Just don’t forward ports to the My Cloud for now.

I bought a mycloud and I cannot use the full potential because of the vulnerabilities. I think wd should take more care about the people that trust on their products while buying. I have a my cloud without cloud. So what should be the name for this “new” product? My non-cloud Nas

MyNas is probably a better name. Given how the gen2 basically wants to force you to use WD’s software ecosystem to even attempt to use it as a cloud backend device. It IS possible to get a gen2 to properly export through a firewall, but given its security holes, that is like preemptively asking to hold money for the Nigerian Prince.

Judicious abuse of the USB startup script could accomplish this, and would be an easy and painless revert. (just unplug the drive, and reboot the nas) For permanent changes, re-baking the cramfs container that gets mounted at /usr/local/modules (It is physically stored on /boot which is a rw ext4 volume) would let you completely and persistently change the webroot (and thus the whole GUI), and a great many system things, as the existing initrd calls a system invocation script in /usr/local/modules/script which does all the user init stuff (which you could re-bake by baking the cramfs container again)

I may consider researching how to make use of the persistent partition (HD_a7) to completely replace the system contents of the cramfs container, and patch into the root FS with symlink creation, to make the Gen2 more user configurable (persistently) like the Gen1 is. That is sure to void the warranty though. (current thought is a hyper minimal cramfs container, that just contains a script to bounce control back to the local, editable contents of the persistent partition, because the initrd explicitly mounts said cramfs container, then jumps startup execution there. Keep it around as a legacy artifact to avoid modifying the initrd and as a known early hook in the boot process, then jump out and do everything else outside it.)

It would be hilarious we WE fixed the security holes being discussed.

The version is again released? Can someone check if this works OTA? Are “all” the vulnerabilities fixed? I cannot test because I’m not at home.

For those who missted it, WD has once again released firmware 4.05.00-315 & 2.30.165 for the single bay My Clouds:

New Release - My Cloud Firmware Versions 4.05.00-315 & 2.30.165 (4/19/17)

cough wrong post Bennor, this is the 2.30.165 post… and I was just thinking how come they didn’t release the 2.30?

Ahhhh ok… unexpected WD actions :stuck_out_tongue: apologies to @Bennor