CNID DB error using AFP in Lion

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?

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.

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

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.

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.

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

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

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

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!

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

I've been having this problem ever since upgrading to firmware 4.2.20.
Tech support suggested downgrading to 4.2.19 and then reinstalling 4.2.20, but this did not have any effect.

After a little digging around, here's what I think the problem really is, and how to fix it...

Each time you mount a share on the NAS, there is a process which runs and does some maintenance on the CNID database (this maintains mappings from filenames to AFP id''s).
If you have a lot of files in your share, this can take a while, which is why mounting the share appears to lock up for a long period of time, before giving the 'Something is wrong with CNID DB' error.

If you SSH into the NAS, find where your share is on the drive, and then look in the hidden .AppleDB directory
In there, the CNID database is stored, and there are various log files. On My NAS the CNID database was pretty large, and the log files contained many errors about running out of lock space.

1) Unmount all shares from your machine (might not be necessary, I did it just to be safe)
2) Via SSH, rename the .AppleDB directory to OLD_AppleDB (you should do this for EACH share which is affected).
3) Reboot the NAS
4) When the NAS boots back up, try to mount the share. The NAS should recreate the .AppleDB directory (this time much smaller, and hopefully will not suffer form lock space problems). After that you should have read/write access on your share again

* disclaimer: I might be jumping the gun and its a temporary fix only. But its working for me so far. Since I've been frustrated by this problem for 10 days, Im really happy to have even a temporary fix.Hope it helps someone else.