One question about the damon.log file :
As I am on Mac OS X, what do you think is the best solution to avoid the oversize issue of this file ?
Should I erase it every week for example, before WD post a new firmware that will correct this issue ?
If I don’t reboot the drive, is the file daemon.log still growing ?
Thank’s !
Alas ThierryB, I am not a MAC expert. I’ll be able to use one but after that I’m stuck. I’ve been trapped my Microsoft.
The initial symptom that there is a problem is that the MyBook Live stops going to sleep because the 20M of storage allocated to ramlog is exceeded but what happens then is ramlog disables itself (needs the MyBook Live to be rebooted once the fix-ups are done) and the logs written dorectly to the disk.
As I don’t need AppleTalk I’ve turned off that protocol on my MBL and I don’t see this problem so whatever it is related to the MyBook Live’s netatalk service and Apple computing hardware.
From what others have posted and what I’ve found out I’ve managed to collect enough information to help other people de-brick their Dashboard UI.
My duggestion is to configure your Apple computing devices to use the SMB file sharing protocol and shut-off AFP as a temporary workaround until Western Digital’s firmware department permanantly solve the problem and release another firmware for the MBL.
In the meanwhile, you are correct. Keep an eye on the log files. You can use the df -h command to view how much of /var/log is used. If the space allocated to /var/log is not 20M then remlog has been shutdown because the total of all the logs has exceeded 20Mb.
If you can find out what CNID (whatever it is) on your MAC that’s causing the MBL to panic and grow deamon.log then maybe you can shut that off instead?
I’ve noticed that the QuickView applet can also grow another log file quickly, but not as quickly. I don’t have my computers on 24/7 or for very long periods so not experienced this different problem but as a precaution I’ve disabled WD’s QuickView applet on my computers so my MBL, at the moment, is quite happy, complient and functional.
Best advise I can give at this moment in time.
I’m happy that my efforts hae helped a few people and is still helping. Other advise is for everyone to enable SSH and then change the defailt password of the root user from welc0me to something else using Linux’s passwd command and make the password secure.
I had same problem of growing daemon logs, MBL not sleeping.
I wrote to WD customer service about my logs and stuff but yet to hear from them.
Meanwhile, I manage to discover a temporary turnaround for my never sleeping MBL.
It probably only work for people who has simlar issues as mine. Here goes:
If the error message of your growing daemon logs is the same old message that is caused by the Apple Talk service, it will be helpful to read on.
You need to know how to access to the root directory of the MBL
Do a “df -h” and if your ramlog (in my case "ramlog-tmpfs " is at 100%), that means your MBL is probably not going to sleep.
Do a “ctrl c” or copy of the text “/etc/init.d/netatalk stop” without the " " so that it is available on your clipboard.
That command when executed should prevent the rapid writing of the error messages to the ramlog and subsequently to the daemon logs (that is my guess).
Since your ramlog is already full, stopping the service only prevents the daemon logs from building up, so you need to do a reboot (in my case, i type “reboot” at the command and the program will prompt me to reconnect in 5s).
The idea here is to access the root and disable the apple talk before the error messages fill up your ramlog after the reboot.
As soon as I got connection to the root (auto connection every 5 seconds), onec I see the command box, I quickly do a paste of the text and enter so that stops the apple talk. Upon checking “df -h”, I realised my ramlog is only at 54%, and in 10 minutes, my MBL went to sleep as expected.
I might have to do this whenever I do a reboot or shutdown but at least I gain some functions of the drive while waiting for a permanent fix hopefully. I will also be enabling one feature at a time (e.g twonky server, wd2go) while maintaining the current functions of the drive. Will update whenever things stabilise.
Henry
Henry, there is a lot more to this problem and I’ve collected/documented the additional information.
Just to clarify that when ramlog gets full and shuts down, like goes into some sort of bypass mode, then all the logs that are in ramlog get flushed to disc and you’ll see from the dg -h command that the storage capacity of ramlog-tmpfs is no longer 20M. Your solution, same someone else’s which I have used (forgot who found that one out) works.
If the system partition fills up to 100% then other things then go wrong which required more fixing up then just eraseing daemon.log and daemon.log.1.
I think at the moment it is not known if the CNID DB errors are rapidly thrown up is because of a fault of software within the MBL or if it’s a fault within Apple’s operating system that’s sending data to the MyBook Live that incorrect, so the logging of the CNID DB error within the MyBook Live may actually be valid and correct. It’s just that the routine that managed the log files within the MyBook Live don’t expect a log file nuclear exploding in size.
Henry,
I decided to try your directions as my ramlog had maxed out (i.e. showing 100% on df -h). So I stopped ramlog and then attempted a restart but now it won’t restart. The appropriate section of the ramlog reads as follows:
df -h & ramlog status is as follows:
Interestingly, I can now mount the drive successfully on my MAC and daemon.log is now well under control:
But sadly Remote Access is still bricked.
Jamie
Hi,
As I use Time Machine, I can’t stop the netatalk process on the MBL.
It’s easy to use SMB instead of AFP to connect the drive to the Mac, in order to access to the Public folder.
The daemon.log file as grown from 4,1 to 4,5 Mo in the last 10 hours.
I suppose that Time Machine use the AFP protocol by default ?
Just a question : Do I need to reboot the MBL if I erase the daemon.log file ?
Thank’s !
I hope WD will not wait a too long time until a new firmware that will fix this issue.
Last point, I’m still waiting for an answer from WD until January 3rd, so thank you again Myron for all the help ! 
hi Quadra Guy,
I can’t see your screen shots on my browser.
anyways, “MyBookLive cnid_metad[1823]: error in accept: Socket operation on non-socket” was the only error message shown on my daemon.log and daemon.log.1. That made me think that my ramlog must have been filled with those error messages and thus reaching 100% in seconds. So I intervened so that the ramlog will stay under 20MB. It was a temp fix because I have to do it everytime I do a reboot or power cycle. Did you have the same error message?
Since then, I backed up all my data and chanced upon a “use at your own risk” thread, I realised my MBL must be in a big mess now, so I decided to try “/usr/local/sbin/factoryRestore.sh noreformat”, I lost all my previous settings, including having SSH disabled. I had to export configuration and do a manual correction to “enable” and import the configuration back to the MBL. After enabling SSH, I took a quick look at the logs and the appletalk service error message was gone, and my drive could go to sleep just waking up every 4,000-5000 seconds to renew DNS lease.
My next attempt is to do a normal shutdown and see if it behaves normally when it is booted back up.
Henry
Henry,
Sorry about my screen shots not being readble to you.
I just checked daemon.log and do not see the error you quoted. My log is currently filling up with “localhost afpd[6463]: deletecurdir: error deleting .AppleDouble in “””.
I have posted excepts from my log to this and other threads and am hoping WD wil take note.
I am not too keen on the “use at your own risk” route and think I will wait a bit longer for some indication from WD that they are closing in on a fix.
I did put an item on the Apple Community Forum regarding this issue, including a link to this forum and topic. I am hoping this will warn future MAC users of this issue and turn them off purchasing this product as I am non too happy with it so far.
Cheers,
Jamie
Jamie,
The “use at your own risk” comes from this following thread:
http://community.wdc.com/t5/My-Book-Live/new-My-Book-LIve/m-p/299058/highlight/true#M6332
It was provided by a WD Staff BBBBBrandon
Not sure what risk the factory default reset w/o format is.
It is actually solving all my known issues so far (fingers crossed)
It goes to sleep on time.
I do not have to disable the Apple Talk service (not that I need that, but it was triggering the error messages previously)
I have enabled Remote Access and Twonky service and it still goes to sleep on time.
The only error message I have getting so far is
Jan 9 17:47:06 localhost mDNSResponder: ERROR: getOptRdata - unknown opt 4
but it is not clogging up my logs so I hope to live with it.
I picked this from the net, so hopefully nothing is too wrong.
"opt 4 for is the EDNS0 ‘Owner’ option. It allows a server, before sleeping, to ask a sleep proxy for a wake-on-lan if an important packet is sent to the sleeping server.
Older versions of mDNSResponder do not understand this Owner option.
It should not cause any problems other than filling your log files."
I will be trying out WD Photo (iphone app) and also using the WD Live SMP next to see if there are other factors that wake the MBL up from sleep.
I hope your issues get solved soon.
Henry
henlihai wrote:
Since then, I backed up all my data and chanced upon a “use at your own risk” thread, I realised my MBL must be in a big mess now, so I decided to try “/usr/local/sbin/factoryRestore.sh noreformat”, I lost all my previous settings, including having SSH disabled. I had to export configuration and do a manual correction to “enable” and import the configuration back to the MBL. After enabling SSH, I took a quick look at the logs and the appletalk service error message was gone, and my drive could go to sleep just waking up every 4,000-5000 seconds to renew DNS lease.
My next attempt is to do a normal shutdown and see if it behaves normally when it is booted back up.
Henry,
After reading the “use at your own risk” thread, I think I am going to go through with a “/sbin/factoryRestore.sh noreformat”. However, before I push the “GO” button could you please clarify what you mean by “I had to export configuration and do a manual correction to “enable” and import the configuration back to the MBL.” In other words, what config file are we talking about and what did you manually correct?
Cheers,
Jamie
Jamie,
I vaguely remember that when I first encounter some issues with MBL, I tried to log in to root of the drive but I realised my SSH was not enabled. So I had to do a http://mybooklive/UI/ssh and I could enable from there.
When I apply the “/sbin/factoryRestore.sh noreformat”, I try to log in after reboot but I can’t. And I remembered that I have to enable SSH, but this time around, the link did not bring to the same page. Fortunately, I could access the dashboard / UI and there is an option where you can do an Import / Export of your configuration. So firstly, I export my factory default settings, I open that file using a Notepad, I change the SSH settings to “enabled” and save that file, import the same file back to the drive. After a couple of minutes waiting for the drive to read the new settings, I was able to log in to the root once again.
You can log in to your dashboard / UI and search for the import / export section. Do an export of your current settings and view it. You will understand what I mean at that time.
Henry
Henry,
One last question: After you performed the “/sbin/factoryRestore.sh noreformat” did you have to re-update the firmware?
Jamie
No, it was on the latest firmware as I did a check for update and it didn’t require me to re-update.
I read somewhere in this forum that he was told to do a factory restore after updating the latest firmware and all his problems were solved, it seems like that to me (so far so good) and for you too if you try. =)
Henry
So, here is the update:
I tried the “/usr/local/sbin/factoryRestore.sh noreformat” route but it did not seem to take - not sure why. However, since I did not have a lot of data on the drive I elected to go with a “Quick Factory Restore” from the DB UI. Once I reset ssh to enable, changed root’s password, and reset all my settings (e.g. Static IP, FTP to enable, shares, users, remote acces, etc.) the thing has been functioning well and as expected ever since (3 days and counting). I run df -h periodically throughout the day to check on status and everything looks good. Interestingly Ramlog does not show up on the list. I also check the size of /var/log/daemon.log and it has not been appended to since that initial start-up back on Jan 9.
I have a few audio files copied onto the Public Share and have 2 iDevices accessing the drive through WD 2go. These are both working and have been for the last 2 days. The Public Share mount to my MBAir works as well (i.e. no “Something wrong with the volume’s CNID DB” error shows up). I have logged onto the mount via Guest & my own user account successfully.
I will be copying over a few more media files to test things over the next few days.
I have two PCs runing WIN7 on my network and am going to set up the backup procedures for these today. I will keep you posted on my experiences.
Jamie
That’s good to hear. Things are looking good.
Anyways, “/usr/local/sbin/factoryRestore.sh noreformat” requires a reboot if I recall correctly.
I was also wondering then how come nothing happened after that command.
Henry
Many thanks for all the posts.
I do not want to stop the service since I use a Mac as one of my machines.
I do not know why people have not tried the obvious answer, link the log file to /dev/null.
/dev/null is the bit bucket, null device, write all day if you want. It does not do anything.
ln -s /dev/null daemon.log
from the /var/log directory.
This is what I now see
MyBookLive:/var/log# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md1 1968336 1001592 866756 54% /
tmpfs 51200 0 51200 0% /lib/init/rw
udev 10240 6784 3456 67% /dev
tmpfs 51200 0 51200 0% /dev/shm
tmpfs 51200 3136 48064 7% /tmp
ramlog-tmpfs 20480 2048 18432 10% /var/log
/dev/sda4 1941348672 2964288 1938384384 1% /DataVolume
Seems like a good idea to me.
Glen Lalonde
glalonde,
the logs help us to determine where the errors are coming from and what causes it.
To me, the log files are not the issues.
My logs are normal now after I have done a factory reset without reformat.
I am on the latest firmware too.
The error messages are gone and the drive goes to sleep on time.
Henry
Agreed. Also, performing a link to the null device “could” cause problems elsewhere. It’s also not a good idea to disable log files because if something else goes wrong then you don’t get any clues where the problem lies.
I am not saying this in the final fix, I want the issue resolved too. It’s a workaround for now. Enabling the logs is of no value since in 30 seconds they fill up with one line over and over for this log. Thus it is of no value being enabled. I did not see others indicating simply doing a factory reset will fix it. Disabling appletalk might, but I need that enabled. Thus I think doing the link is the simple solution for most, until the real fix comes out from WD.
DId this fix, plus the ‘delete’ apple database thing, and all is good now. Mac does backup, MBL goes to sleep.
Glen.
It’s a solution. 
It it works then it’s not to be knocked.
My consern is not knowing how the firmware designers tie things up internally. For all that anyone knows there might be something in there that might occasionally examine daemon.log for “whatever reason”.
Also, the log file management scripts and programs. How do they cope when they encounter the (linked to) /dev/null?
I just advise caution.
| Forums | News and Announcements | Register | Help | Forum Guidelines |
Copyright © 2021 Western Digital Technologies, Inc. All rights
reserved.
|
Trademarks
|
Privacy
|
Community Terms of Service
|
Site Terms of Use
|
Copyright
|
Contact WD
|