WD is happy to announce the latest firmware update for the My Book Live. For information about the firmware update, please check out the release notes.
Please feel free to post your experiences in this thread.
1 Like
My advise to anyone applying any updates… TAKE A BACKUP OF YOUR DATA !!!
I’m hoping that this update might address the issue of the Web UI disappearing. Where trying to access it through a web browser results in the MBL’s web server simply not being there.  Before applying the update, enable SSH as this can act as your back-door to try fix things in case the Web UI is unresponsive.
First sign-onto the MBL’s Web UI as normal then change goto the URL: http://MyBookLive//UI/ssh
(Replace MyBookLive with the name you’ve given your MBL)
Me having my MBL’s SSH enabled help me recover my MBL from a bricked Web UI when performing the previous update. If SSH has been off I would have ended being forced going through WD’s R.M.A. process and the associated inconvenience.
1 Like
Just checked the release notes, there’s no real reason for me to update if this was the only fix; if it’s not broken then don’t fix it 
For some people it’s a necessary fix because of lack of understanding and putting their MBL onto the DMZ. I’ll be putting in the update once the Safepoint back-up’s been fully updated.
Unless it’s done and not been documented, it’s a pity that this update does not solve the problem of a computer being prevented from connecting to shared resources using WebDAV buy default. I must admit I have not had this problem and all connections to my MBL have been through the Microsoft Networking Client to the MBL’s Samba service. Maybe I’m just one of the lucky ones? 
Myron, the bug had nothing to do with computers using WebDAV instead of Samba. The bug was that you could access any file in a share via HTTP by using a specially crafted URL.
Surprised the LED issue that plagues everyone is not resolved in this firmware.
Yes, I’m aware of this, but there are reports of WebDAV being usied instead os Samba and because of this there are reported performance issues. It’s what I’ve observed discussed within several threads within this forum. I’m not experiencing this slow data throughput issue. My systems seem to always be going through the Samba service.
Glad the security issue what existed within WebDAV has been addressed. 
Nathan_H wrote:
Myron, the bug had nothing to do with computers using WebDAV instead of Samba. The bug was that you could access any file in a share via HTTP by using a specially crafted URL.
Trying to perform the update by getting the MBL to download the update. Greeted with . . .
30000 - Unknown error. Please ensure you are not facing network connectivity issues and try again.
(update_
 Processes invoked.
root 12668 1 0 79 3200 0 10:08 ? 00:00:00 /bin/bash /usr/local/sbin/updateFirmwareToLatest.sh http://download.wdc.com/nas/apnc-020301-024-20111019.deb
root 12671 12668 0 79 2816 0 10:08 ? 00:00:00 /bin/bash /usr/local/sbin/updateFirmwareToLatest.sh http://download.wdc.com/nas/apnc-020301-024-20111019.deb
root 12849 12671 1 193 8448 0 10:08 ? 00:00:00 curl http://download.wdc.com/nas/apnc-020301-024-20111019.deb
root 12672 12668 0 56 1536 0 10:08 ? 00:00:00 tee -a /dev/null
 No problem with connectivity . . .
NAS:/var/log# ping download.wdc.com
PING a622.g.akamai.net (77.109.169.184) 56(84) bytes of data.
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=1 ttl=55 time=98.4 ms
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=2 ttl=55 time=106 ms
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=3 ttl=55 time=107 ms
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=4 ttl=55 time=117 ms
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=5 ttl=55 time=115 ms
64 bytes from a77.109.169-184.deploy.akamaitechnologies.com (77.109.169.184): icmp_seq=6 ttl=55 time=118 ms
^C
--- a622.g.akamai.net ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 98.405/110.647/118.235/7.108 ms
 The ping command was invoked on the MBL.
So, what went wrong?
Managed to apply the update but manually downloaded the file and sent the upgrade file from the computer to the NAS.
Any news about a bug where when a static IP configuration is applied that the MBL still picks-up the DNS settings off the LAN’s DHCP server and replaces the static DNS entries?
What a mess!!!. Just auto-upgraded to 02.03.01.024.
Huge wait times to even connect to the dashboard 1 minute+ delay in logging in, 45sec-1:30 to logout. minutes and minutes to access, use, save settings. Green light flashing while drive is “idle.” I have done re-sets, power down, swap router rj45 ports. Additionally, there was one dashboard error “31319” and a warning about losing network connectivity (traffic, timing. crowding?)… BOGUS. This is on a SOHO LAN with one user and no other activity (printing/internet).
This is the same as a previous forum thread —
Tech support advises if the above steps do not work, unit is defective. Huh? Unit was not defect before firmware “upgrade.”
I have manually download the firmware and will try a reinstall.
I will report again.
In the meantime, anybody have suggestions?
A manual reinstall of the firmware cured at least one issue --that of the green light flashing, even if the MBL was idle, and also stopped the harddisk drive itself from churning, even when there is no activity.
Access speeds are a bit faster, especially for log-off. It still takes 24 seconds until the log-on screen appears after it is called up by my browser. If this is useful, the MBL is assigned a static IP and the IP is assigned as static in the router. There remains typical lag times of 10-20 seconds for the various menu screens to populate.
In all fairness, the Dashboard is usually something that one will not be heavily using so the Dashboard operating on a bit of a slow side could be tolerated. As long as it’s now way too slow. With the new firmware the speed of the Dashboard UI is still operating at a reasonable speed.
After the second install of the new firmware, it operates faster than after the first firmware upgrade install. You are right, going to the Dashboard is a very occasional experience. 1) Before this firmware upgrade, attaching to/opening the Dashboard and all its functions was faster/quicker. 2) After the first upgrade install took place, the green light would not stop blinking nor the hdd spin down (1/2 hour) before I removed the power. Re-setting made no difference. The first firmware upgrade could have been buggy, and that might explain it. The second install, however, still slows down use of the Dashboard over the earlier version of the firmware.
Do you recommend to upgrade to this firmware?
If you are not having any issues with the drive at this time, I suggest not doing anything to disturb its functioning. In plain language…if it ain’t broke, don’t fix it. Make sure the Dashboard is not set to automatically install updates (MBL IP address/(log in) /settings/system/updates/auto update --uncheck). So, in a word-No. Not right now, not yet. Wait to see if I am the only one with problems.
I wanted the firmware because it plugs a security vulnarability where private files could be accessed without the need for a user name and password.
Don’t know why your drive ain’t going to sleep. Even with the new firmware mine is happily going to sleep when it’s not doing anything. Extract the log files and have a look to see if there is something else going on.
While you have a good reason to upgrade. I’d wait a few days until there is some more positive traffic on this thread. I am finding that, with the re-install, each time I hit the Dashboard, all its functions are faster. As mentioned before, the constant on blinking green light and the churning hdd have stopped.
Please re-read ALL of my posts. I repeat --after re-installing the firmware upgrade, the constant green blinking light and churning hdd stopped. I ran the diagnostic routine and read each of the log entries. There were no entries that stated “error” or “failure” or the like. As I said before, I suspect a bad first attempt. What is curious is that, after the re-install, each time I access the Dashboard, things are moving faster and faster. Quite inexplicable.
Are the NFS issues fiexd?
