# [netatalk] Something wrong with CNID DB



## bugboy (Dec 18, 2010)

I recently upgraded my ports collection and I guess net/netatalk has been upgraded as well. Yesterday, I first saw a message when I accessed an AppleTalk volume that looks like this:

*Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details!*​
I have stopped the AppleTalk service and removed all .AppleDB, .AppleDouble, ... directories and files. Then I reinstalled net/netatalk and updated afpd.conf and AppleVolumes.default, so they are in sync with the files that are installed with the distribution (no important changes needed to be made). Then I restarted the server, but I still get the same message. The server doesn't contain any information in /var/log/messages. I noticed that the cnid_metad process is not running and I read this should. It is installed though...


```
afpd 2.1.3 - Apple Filing Protocol (AFP) daemon of Netatalk

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version. Please see the file COPYING for further information and details.

afpd has been compiled with support for these features:

        AFP3.x support:	Yes
      Transport layers:	TCP/IP DDP
         CNID backends:	dbd last tdb 

             afpd.conf:	/usr/local/etc/afpd.conf
    afp_signature.conf:	/usr/local/etc/afp_signature.conf
   AppleVolumes.system:	/usr/local/etc/AppleVolumes.system
  AppleVolumes.default:	/usr/local/etc/AppleVolumes.default
       UAM search path:	/usr/local/libexec/netatalk-uams/
  Server messages path:	/usr/local/etc/msg/
```

Can anyone point me in the right direction? This is very annoying. I am currently running FreeBSD v8.1-RELEASE and netatalk v2.1.3.


----------



## vonProteus (Jan 16, 2011)

Same problem.


----------



## bugboy (Jan 16, 2011)

I have fixed the problem. I have rebuilt my databases several times, but nothing helped. Then I looked at my configuration and there was a problem with AppleVolumes.default. You can specify a *cnidscheme* for each volume. You can choose between *dbd* (default), *last* and *tdb*. In my case the cnidscheme was set to the value *cnid*, which is invalid. After changing it back to *dbd* everything worked fine again.

I don't remember setting this value by hand, so maybe it was incorrect in some example or default configuration. I think the new version is more strict when parsing the configuration. Hope this helps and please let it know in this topic.


----------



## vonProteus (Jan 17, 2011)

Thanks, this helps me.


----------



## ian-nai (Feb 2, 2011)

What are the permissions on /usr/local/etc/msg/? I'm not seeing any messages in there. I'm also getting the same error, but changing cnidscheme to dbd actually 'broke' the server.


----------



## leifdenby (Apr 7, 2011)

Hi,

I fixed the problem on my server. I think my cnid db was corrupted.

1. Stop netatalk.
2. Delete the .AppleDB cnid db in the root of your share(s).
3. Make sure that the cnidscheme is set to dbd AppleVolumes.default (this seems to be the safest db option anyway, i.e. least prone to corruption. http://netatalk.sourceforge.net/2.1/htmldocs/configuration.html#CNID-backends)
4. Crucially, make sure that the cnid_metad daemon has been started. To get FreeBSD to start this daemon add the following line to /etc/rc.conf:

```
cnid_metad_enable="YES"
```
This was the part I was missing.
5. Start netatalk.

Hope this helps,
Leif


----------



## ian-nai (Apr 8, 2011)

It works now, without any weird error!

Of note, Leif, between your steps 4 and 5 I ran `dbd -r` on my shares.  I don't know if this was a necessary step or not, but it seemed like a good idea to rebuild the db.


----------



## novafluxx (Oct 10, 2011)

leifdenby said:
			
		

> Hi,
> 
> I fixed the problem on my server. I think my cnid db was corrupted.
> 
> ...



Thanks for this information! I was missing the line in rc.conf. Glad Google found this thread for me. Thanks for the information.


----------



## traustitj (Jun 17, 2013)

Hi.

Just found this thread with Google as well. I noticed that my CNID database always returned errors, but it was because my line was

```
cnid_metadb_enable="YES"
```
and it has been fixed to

```
cnid_metad_enable="YES"
```
All this trouble for one extra "b"*.*


----------



## Soundboutique (Sep 23, 2013)

*CNID DB error with both GoFlex and WD My book*

_I was w_ondering if there is a fix that can be done for someone who's not adept with coding? Or, even a place here somewhere in the Bay Area that might be able to help? I first started with these error messages on my seagate GoFlex drive. 


```
Message from server "GoFlexHome"
Something wrong with the volume's CNID DB, 
using temporary CNID DB instead. Check server messages
for details. Switching to read-only mode.
```

I've found that my 'personal' folder is missing all the files. However a few times I was able to access and see the 'Public' folder and the files inside of it. And, it just recently started happening with my WD my book now too. So, of course by process of elimination I've figured out it's not a problem with my hard drives, but with my MacBook. But, not sure at all.

I'm hoping there's a simple fix? Something I can do to adjust on my laptop? I've already maybe lost a bunch of data, don't know why... it was there one day and gone the next? The drive still shows a small amount of available space, so the files must still be there on the GoFlex, but can't access them, and can't see them in the folders. I haven't done any updates and nothing about my setup has changed since before the problem. 

I'm on a MacBook and OS 10.6.8. I don't have time machine turned on nor have I ever used it. It seems like a lot of people are having this same problem and I haven't found a good solution on the web anywhere. Any help is greatly appreciated.


----------



## DutchDaemon (Sep 24, 2013)

This is a FreeBSD-only forum. We don't deal with OS X here.


----------

