No Dashboard after power failure

The stupid lights abruptly went out here in San Diego last Thursday.  After the power was restored my MBL has been working fine except for the Dashboard. The page does not respond and times out.

I’ve tried re-installing it from the CD but that only temporarily restores it, and only for that networked machine.  It’s down on all the others.

The Dashboard isn’t mission critical, but it’m sure it’s trying to tell me something.

Thoughts …

(Ps - Always keep plenty of candles and batteries on hand.  And thank God for my battery powered radio.)


better if you contact the techical support via phone and explain the issue

otherwise you may end with a faulty disk soon enough


Which dashboard?   The WEB dashboard, or the PC WD dashboard?


Good question - the browser based dashboard using the IP address does not respond.  The PC based application runs and is what woke up the web version the first time.  And then later I attempted to reinstall from the disk. 

Still down.



Thanks, good to know.  I’d hate to have this thing poop out on me. 


HAve you tried poking the reset button?

Now then…  I’ve had a similar problem but I rebooted my MBL before trying to do an update. Luckily I had SSH enabled so managed to download the Debian upgrade archive from WD’s product support site and directly invoke the script that initiates an update from file.  I’ve recently documented what I did in the official “latest firmware” thread/discussion on this here community forum.  Hopefully you have SSH access enabled.  If not…  Pass.  Dunno then.  Maybe it needs to go back to Western Digital if the reset button does not work.

When the update completed the Dashboard became alive.

My post copied from the other thread…

Thought I would turn off all the services and then reboot my MBL. On reboot the Dashboard UI is not accessible. The IP is allocated dynamically but the IP is reserved on the router so the IP stays the same.

Luckily I have kept SSH enabled so had to download te update file to the Public share and initiate the update by executing the firmware update by file script.

NAS:/DataVolume/cache# . /usr/local/sbin/ /DataVolume/shares/Public/apnc-020202-020-20110825.deb
basename: invalid option -- 'b'
Try `basename --help' for more information.

 Now…  What is basename. Why did it fail to execute?  From the colour of the LED and the hard drive sounding busy I am assuming at the time I post this that the updatre is in progress.  I’m keeping the SSH session open during the update in-case closing the interactive sessions also terminates the update.

Why would a simple reboot kill the Dashboard UI?

EDIT: Luckily the update using worked and the Dashboard UI began working again under the current firmware. Still, after a reboot why did the Dashboard UI die after a reboot?

:wink: myron did you post to the right thread

to the original poster, maybe your router picked a different IP for the MBl on power up?  Are you runnign dhcp?  do you have one reserved?  Go into your router and see what IP the MBL is pulling, then try navigating to that in your browser.


I haven’t found the reset button yet, but I did try the old  “unblug power - count to 20-mississippi-power on” method of resetting.  No joy.



Um, yeah. I’ll give that a whirl.


Yes I did. The Dashboard vanished on my MBL post-upgrade to current firmware after reboot BUT the MBL has it’s IP reserved on my router so it always gets the same IP address so the loss of access to the Dashboard ain’t the MBL getting a different IP.

Mind, you, I did spot something that might be part of the cause of the Dashboard dissapearing within the MBL…

It’s a file named allow.conf in the /tmp folder.

<Directory /var/www/UI>
Order deny,allow
Deny from all
Allow from 172.16.

Seems a bit suspicious. If I read this right the deny rule is actioned before the allow rule and whatever is reading this file never gets to the allow rule.

Hmmm…  :-S


It looks like it’s correct, but puzzling to understand.

Explanation at:

I am running the latest firmware so maybe it’s fix for me.  If it’s not fixed then the only thing I can think of is if the IP address changes on the MBL NAS then this file does not get altered so the Apache web server does what it’s told and denies access to all? Pass… I’ll try not reboot my MBL incase that kills the Dashboard again.  :slight_smile:

Myron, that’s the corret syntax.

First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default.

First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.


Order Deny,Allow

Deny All

Allow 172.16.

will deny Everything except from 172.16.x.x.

Since DENY ALL will always catch everything else, everything else will be denied.

Thanks. As the allow.conf file is in the \tmp folder I assume it’s included from another of Apache’s configuration files and it’s in the tmp folder because it’s re-written by some script when the network configuration changes.

It’s another issue (I would call it a bug) that W.D. decided to deliberately introduce, their explanation is to close off a security hole.  I found it useful to remotly configure my NAS and now I can’t.

Why I took interest in this thread was because on the previous firmware when I simply rebooted the NAS, the Dashboard became inaccessible.  I’m sort of thinking that this new (annoying) “security” feature that W.D. introduced may be causing the bug where the Dashboard becomes inaccessible even from the local area network.