Response please.
Come on WD. It’s a simple question. What caused the LED issue and is it truly fixed in the latest firmware? Not updating until I know for sure.
I am having the same problem. I bought my Mybooklive in February and over this past weekend the green led stopped working. If I reboot the led goes from red to blue to blank. Except for that I can backup on the drive and access files on it with no problems. I updated to the latest firmware 2 weeks ago with no problems. It is annoying since there is no way now to see the status of the drive except though software. I really would like to see an answer to this problem.
RESPONSE PLEASE. COME ON NOW!
I don’t believe the firmware update had the fix for this. In fact I’m not sure if it didn’t cause the problem. I used mine without any problems. I updated the firmware, but I can’t say for sure whether the LED problems started before I updated or not. I just know it worked well for a couple of months.
I have the same problem that when I boot it up the blue light comes on for a little bit, a quick red flash and then it goes dark. I am afraid that when I need to retrieve files there won’t be anything there. This is my first external hard drive and if I had known what the problems and lack of support I would have looked elsewhere.
Question… At any time has the power to the NAS being removed without shutting it down? Has a script become corrupted that controls the LED? (I’ve been playing and got the LED to do a morse code SOS signal and also randomly showing different colours each second but I wrote a separate script to do this so as not to break my NAS. I tread carefully here so as not to wake up any NAS dragons!)
I’m thinking along the lines of if there is is some file system corruption on the NAS. I’ll need to check but after the 20th time that the NAS is shutdown/powered up since the last check a file system integrity checked is invoked by the MBL. Also the MBLalso invokes a file system integrity check every 180 days.
I think it’s possible invoke the file system integrity check from the root shell but don’t remember the command to invoke the check.
Nehptis wrote:
RESPONSE PLEASE. COME ON NOW!
I thought this issue was being looked at, but I escalated it again. Once I hear something on this, I’ll let you know.
Just FYI, the same issue (No LED light) started to happen with my MBL. I first noticed it last night (The unit is behind the stack of papers so LED is not in the direct line of site:stuck_out_tongue: ) Anyway, it was OK last weekend. Firmware had been updated when it came out last month.)
It doesnt appear there is any performance problem with the NAS, just a blank LED.
bill_s wrote:
This issue should have been fixed with our newest firmware update.
Just to fill everyone in. The latest update does not address a LED light that has burned out (potentially). What it did address is drives showing “bad” status in the dashboard AND potentially a RED LED light. It looks as if from what you guys are describing in this thread that the LED lights may not be operational from a physical level. I have sent a few of you PM’s to see if we can have your drives RMA’d and sent to myself for investigation.
Myron, If you can share the script to control the LED, then I can check my MBL through SSH access to determine if the failure is at hardware level or at software level. My MBL is already 1/3 full and I really hesitate to RMA the hard disk without knowing if this is really a faulty hardware.
To verify what the drive thinks the color is you can do this:
cat /usr/local/nas/led_color
adachim wrote:
Myron, If you can share the script to control the LED, then I can check my MBL through SSH access to determine if the failure is at hardware level or at software level. My MBL is already 1/3 full and I really hesitate to RMA the hard disk without knowing if this is really a faulty hardware.
Actually, you can control the LED yourself from the bash command line. Does not need a script. Just remember to change the LED back to the colour it was at as the script(s) check the previous colour and if it’s the unexpected colour the script will leave it alone. For example, change the colour to red and it’ll remain red until you change it to blue or green.
echo green > /usr/local/nas/led_color
echo blue > /usr/local/nas/led_color
echo red > /usr/local/nas/led_color
echo white > /usr/local/nas/led_color
If you use cat /usr/local/nas/led_color then you’ll be shown what colour the LED’s supposed to be.
You can use the red/green/blue commands above (individually) to check the three primary colours to test the LED.
If you want to see how the LED is controlled on a moment to moment basis then examine the script /usr/local/sbin/monitorio.sh and to see how it’s controlled on start-up /etc/rc.local. The white colour is used in /usr/local/sbin/updateFirmwareToLatest.sh and /usr/local/sbin/updateFirmwareFromFile.sh.
Now, disclaimer time… Messing around within the Linux OS as user root could result in a voided warranty. Especially if you load any script in an editor, alter it, (thus goofing it up) and save it resulting in a NAS that won’t start!!! There be dragons there. Wake any of them up and you’ll have your head in your hands!!!
The scripts I mention are very important to the function of the NAS. Best use cat to view the contents of the scripts and expand the terminal’s scroll back buffer so you can examine them easily. Or use the nano editor BUT DO NOT SAVE ANYTHING when exiting the editor.
I guess if you know exactly what you’re doing you could (WDC would not recommend it and neither would I!) add to a script or two a change of LED colour to verify that a script is starting and ending.
Me? I’m leaving all the scripts and stuff well alone. I use PuTTY to access access the logs, move a folder from one tree/share to another and fix faults. I’ve also made copies of all the configuration files just in case some configuration file gets screwed as then simply copying back a working configuration file should sort things out. At some point I’ll end up writing a simple script that will quickly take a snapshot of all the configuration files and shove them in a compressed zip archive.
Enjoy and tread very carefully! 
Oh, I see.
This means the status of the LED is written in the file " /usr/local/nas/led_color" and a process must be fetching that status and changing the color of the LED accordingly.
When looked into it, my blank LED status was supposedly “green.”
Only color that works is RED. BLUE is blank and WHITE is blank.
Curious that WHITE does not work either. If WHITE is achieved by turning RED, GREEN and BLUE, I would think ECHOing WHITE should show RED if indeed this is a hardware problem.
I more’d the script files you mentioned and decided to stay clear of those files. This appears too dangerous to play with those files. I wonder which process or daemon is controlling the LED thogh.
Yes. /usr/local/sbin/monitorio.sh is constantly running. It’ actuallly responsible for putting the drive to sleep and waking it up to the best thing it to leave /usr/local/sbin/monitorio.sh well alone but there is no harm ln having a look what it does. 
Maybe it’s not a tri-colour LED but four individual LEDs? I’m not opening up my NAS until it’s failed and totally out of warranty.
Oh, boy… I just joined this “club of sadness” … just noticed my beautiful LED not working anymore.
I’m not sure if this happened after I was messing around with idle3-tools to get rid of increasing load count or it was pure coincidence and LED was dead before and I just didnt noticed it before…
Now I will read this whole thread to get info “what is what” and what can I do about it.
sux.
I was superb way how to tell, when drive is “ON” and when “stand-by”.
Edit: OK, did not read whole thing yet, but now my idea is to somehow use RED light for “normal working-mode” since its only color seems to be working. Will take a look on that monitorio.sh script later, but of course advice how to do that is highly appreciated from WD or from other users.
Can’t think why the LED would stop working becuae of using idle3ctl, which has worked perfectly and for me too the constant load and unload of the heads drive heads is cured. Way happier now.
It’s still on my task list to figure out what conditions caused the NAS to go to sleep, but it is monitorio.sh that seems to handle this.
So, WD what is your approach to solving this issue, which is obviously widespread? Asking us to send you our drives for possible RMA so you can test is not reasonable. Where do you expect us to store / backup our data if we send you our drives?
I suggest you come up with a different approach.
Nehptis wrote:
So, WD what is your approach to solving this issue, which is obviously widespread? Asking us to send you our drives for possible RMA so you can test is not reasonable. Where do you expect us to store / backup our data if we send you our drives?
I suggest you come up with a different approach.
I have private messaged a few users so we can investigate this issue. I am making arrangements with these indivuals.
If you would like to replace your drive under warranty, you can create an RMA. If you would like a replacement first, we offer advanced RMA’s in some areas:
http://websupport.wdc.com/warranty/rmainfo.asp?custtype=end&lang=en
1 Like
Brandon Advanced RMA will work for me. (This will allow me to first back up my volume before I send back the unit) I will PM you with more info.
