CNID DB error using AFP in Lion

[Philippe31415]

I have an Ultra 6 with Mac OS X 10.7.3 on iMac 2011 and Radiator 4.2.19 and latest update done. AFP give me the CNID DB error. Urgent resolution would be appreciated.

[Blues]

Add me to the "problems with Lion" category (10.7.3). I have a ReadyNAS Pro Business Edition [X-RAID2] and I recently updated RAIDiator 4.2.17 to RAIDiator 4.2.19. I never had problems with 4.2.17 regarding getting a directory listing of a share. Since moving to 4.2.19 I often get "0 items, 2.28 TB available" displayed in my status bar on a share that has several directories. Do I really have to reboot the ReadyNAS to solve this problem each time?

[Fandu]

This is a log of the CNID error being generated:

Code: Select all

ReadyNAS:~# tail -f /var/log/netatalk.log
Mar 12 18:11:49.501555 afpd[12911] {uams_dhx2_pam.c:653} (I:UAMS): DHX2: PAM Auth OK!
Mar 12 18:11:49.501836 afpd[12911] {auth.c:266} (N:AFPDaemon): AFP3.3 Login by ReadyNAS
Mar 12 18:11:49.636085 afpd[12911] {volume.c:2045} (I:AFPDaemon): CNID server: localhost:4700
Mar 12 18:12:33.023880 afpd[12911] {cnid_dbd.c:439} (E:CNID): transmit: Request to dbd daemon (db_dir /c/.timemachine) timed out.
Mar 12 18:12:33.024161 afpd[12911] {file.c:264} (E:AFPDaemon): Reopen volume /c/.timemachine using in memory temporary CNID DB.
Mar 12 18:13:15.387267 afpd[12911] {auth.c:924} (N:AFPDaemon): AFP logout by ReadyNAS
Mar 12 18:13:15.394101 afpd[12911] {afp_dsi.c:99} (N:AFPDaemon): AFP statistics: 15.56 KB read, 752.70 KB written
Mar 12 18:13:15.394381 afpd[12911] {dircache.c:616} (I:AFPDaemon): dircache statistics: entries: 15, lookups: 354, hits: 335, misses: 19, added: 15, removed: 0, expunged: 0, evicted: 0
Mar 12 18:13:15.394962 afpd[12911] {afp_dsi.c:570} (N:AFPDaemon): done
Mar 12 18:13:15.403119 afpd[1394] {main.c:216} (I:AFPDaemon): child[12911]: done
Mar 12 18:14:20.762137 afpd[12963] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 192.168.1.141:63242
Mar 12 18:14:20.776505 afpd[1394] {main.c:214} (I:AFPDaemon): child[12962]: exited 1
Mar 12 18:14:20.776826 afpd[1394] {main.c:216} (I:AFPDaemon): child[12963]: done
Mar 12 18:14:20.856485 afpd[12964] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 192.168.1.141:63243
Mar 12 18:14:20.863519 afpd[12964] {uams_dhx2_pam.c:321} (I:UAMS): DHX2 login: ReadyNAS
Mar 12 18:14:22.000894 afpd[12964] {uams_dhx2_pam.c:210} (I:UAMS): PAM DHX2: PAM Success
Mar 12 18:14:22.017087 afpd[12964] {uams_dhx2_pam.c:653} (I:UAMS): DHX2: PAM Auth OK!
Mar 12 18:14:22.017367 afpd[12964] {auth.c:266} (N:AFPDaemon): AFP3.3 Login by ReadyNAS
Mar 12 18:14:22.055103 afpd[12964] {volume.c:2045} (I:AFPDaemon): CNID server: localhost:4700

Any idea why requests to dbd are timing out?

[franklahm]

This is a log of the CNID error being generated:

[code]ReadyNAS:~# tail -f /var/log/netatalk.log
...
Mar 12 18:12:33.023880 afpd[12911] {cnid_dbd.c:439} (E:CNID): transmit: Request to dbd daemon (db_dir /c/.timemachine) timed out.
...

Either the CNID database deamon (cnid_metad) is not running or hanging. You have ssh access to this unit? Are you somewhat familiar with CLI?
Checking whether cnid_metad is running could be done with a command like this:
$ ps -efl | grep cnid

Some background on the CNID stuff:
http://netatalk.sourceforge.net/2.2/htmldocs/configuration.html#CNID-backends

Can you PM me all available Netatalk logs please?!

[Fandu]

chid appears to be running:

[b]ReadyNAS:/var/log# ps -efl |grep cnid
5 S root 1506 1 0 81 0 - 728 - 20:54 ? 00:00:00 /usr/sbin/cnid_metad
0 S root 2226 807 0 77 0 - 1064 - 21:21 pts/0 00:00:00 grep cnid[b]

logs pm'd.

Thanks!

[franklahm]

chid appears to be running:
[b]ReadyNAS:/var/log# ps -efl |grep cnid
5 S root 1506 1 0 81 0 - 728 - 20:54 ? 00:00:00 /usr/sbin/cnid_metad
0 S root 2226 807 0 77 0 - 1064 - 21:21 pts/0 00:00:00 grep cnid[b]

So it seems to be running but not responding. We'd need stuff like strace or gdb installed on the box in order to determine why and where it's hanging. From your logs the main CNID daemon cnid_metad seems be hanging very early in its startup, because it is not even printing this messages

Code: Select all

Feb 26 12:37:59 ReadyNAS cnid_metad[1556]: Set syslog logging to level: LOG_NOTE

which it should display every time its starting. Is there a chance you can install gdb on the unit? Is gcore installed? I can't check because our test unit just died and we're awaiting replacement.

-f

[Fandu]

Well I was able to get gdb installed, but apt-get is giving me a dependancy problem when I try to install strace.

It seems like this is a known problem - http://www.readynas.com/forum/viewtopic.php?f=65&t=48964

Any ideas?

[peterw]

I came into this CNID Error problem just recently, approximately 10 days after establishing from scratch a dedicated ReadyNAS Ultra 4 Plus to be the Time Machine for a group of 10.6.8 Macs:

OSX 10.6.8 (all 6 Macs backing up via Time Machine, some hourly as they are running 24/7, others less frequently and only when in use)
Backup Time Machine is a ReadyNAS Ultra 4Plus running RAIDiator 4.2.19.
Backup share allocated size 2.5 TB.

After reading a bunch of posts about people having uncertain but some success by going into the ReadyNAS file system to manually delete ".AppleDB" stuff and whatever else with root tinkering, I wanted to see whether I could get the ReadyNAS to heal itself.

What seems to work for me in getting rid of this error and restoring full Time Machine functionality (continuation of backup to, as well as looking back into existing sparsebundles) is:

1. in Frontview: System > Performance - UNCHECK "Disable full data journaling" <APPLY>

2. Then: System > Shutdown - CHECK "Check and fix quotas on next boot…", select "Shutdown and reboot device" <APPLY>

After the reboot and when the ReadyNAS came back online, I was able to re-enable Time Machine on each Mac, and things picked up where they left off prior to the CNID error. Whether doing "step 1" above shall prevent future CNID errors remains to be seen. But "step 2" seems to fix the exisitng CNID db problem, at least in my case.

Curious to see whether this helps others, especially those who are running OSX 10.7 Lion.

Also curious to understand technically why this CNID error occurs.

[ryanrk]

I recently had this issue and all I did was reboot my ReadyNas pro 6 and it fixed the issue.

[damianp]

I got the same thing today, odd, on my ReadyNAS Pro Business Edition. It was recently rebuilt(factory defaults). I restarted it and seems to be ok, nothing in the logs though to indicate any problem. Radiator 4.2.19 and OS Lion, latest revs.

[Blues]

I did as peterw suggested. So far I'm not getting the CNID message, but I still have the other problem: When I AFP to one of my shares it takes several minutes of lots of audible disk activity (spinning beach ball) in the RNPB for Finder to return 0 items in one of my shares that I know contains three root level directories and more than 200GB of data.

I've had this problem only since moving from 4.2.17 to 4.2.19. I thought the latest Beta (4.2.20-T42) would solve it, but it's the same as it was with 4.2.19. I hope a solution is found soon.

[BigBearf]

Same issue. Updated to 4.2.20 and got error message. Volume read only. I am doing the "Check and fix quotas on next boot…", select "Shutdown and reboot device" Will post results.
bigbearf

[BigBearf]

Did "Check and fix quotas on next boot" and got error message to "Perform volume scan on next boot". Did both still with CNID error and still in read only mode. Will probably reboot again and then await response from board members before I proceed further.
bigbearf

[mayhem9]

A few months ago when I was having this problem (see earlier comments in this thread), I opened a trouble ticket with tech support. After looking at my logs, their best suggestion was that I should replace one of my mirrored 2TB drives because of a relatively large number of 'smart' errors in one of them. This seemed strange and costly. Instead, I bought a new Readnas Ultra 2 pro (I was planning to buy it for other reasons soon anyway) and rebuilt my readynas NV with new firmware and a full re-load of data. Now, I no longer have the problem-- both work fine.

If all else fails, i suggest a full re-install if that is an option.

Matt

[spotspot]

I have this problem too! What a disaster. I followed peterw's advice with no effect. Please help!!

Best solution so far: use CIFS/SMB instead. funny that the MS protocol works better than NFS (unix/linux) or AFP (Apple) when i'm on a mac talking to a linux box!