SOLVED AFP problems

[michael.keller]

Hi all,

I'm having some problems with my FreeNas server and I'm not sure how to fix this. After a reboot I can only access my AFP-share as read-only. I've already tried:
- reboot ;)
- delete the AFP-Share and add a new one with the same path
- changed the default file and folder permissions so everyone should have read/write/execute abilities
- change the volume permissions so everyone should have access (with recursively checked)

If I try to delete a file on the share, the console says the following:

Code:

Feb 10 13:23:24 misami_fileserver afpd[14972]: Login by mk (AFP3.4)
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error deleting key/value from cnid2.db: Invalid argument
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: dbd_delete: Unable to delete entry for CNID 592
Feb 10 13:23:24 misami_fileserver afpd[14972]: Reopen volume /mnt/volume/server using in memory temporary CNID DB.
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error closing database name.db: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error closing database didname.db: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error closing database devino.db: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error closing database cnid2.db: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
Feb 10 13:23:24 misami_fileserver cnid_dbd[14973]: error closing DB environment: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery

I couldn't find any hint how to run a database recovery.
I'm running FreeNas on a Supermicro Board (I think it's an A1SAi-2550 with an Intel Atom C2550 @ 2.40GHz) with 32GB of ECC-RAM. My volume is a Raid-Z2 with 6 x 1TB WD Red Drives.

Any help is appreciated. If you need more information, please ask.
Thanks!
Michael

 

[nojohnny101]

Did you always have these problems since initial setup? Or did they start showing up after you updated Mac OS X or after updating FreeNAS?

What version of Mac OS X are you running? FreeNAS version?

 

[michael.keller]

I'm sorry I forgot to mention: I'm running FreeNAS-9.10.2 now. I had FreeNAS-9.10.2-U1 running before without any problems. When the problems started today, I also tried to boot with the 9.10.2 Version, I thought it might fix the problem - but it didn't. All clients are MAC OS 10.9.5 and everything was running smooth since I had to shutdown the server and reboot earlier today, because we're having construction in our building and they had to cut the electrical for 30 minutes.

 

[nojohnny101]

Well to immediately solve your problems, why not just roll back the boot environment? Older versions are usually stored so you should be able to go back to 9.10.2-U2 easily. Then see if the problem still exists.

 

[michael.keller]

unfortunately, this wasn't a success. I rolled back the boot environment to 10.9.1-U4, 10.9.2 and 10.9.2-U1 - but the problem is persistent through all environments. I get the same console message as pasted in my first post when I try to delete a file on the afp share.

 

[nojohnny101]

Ok so you shutdown the server, then started it back up and you had AFP connectivity issues. So you updated to the latest version of FreeNAS and that didn't help. You tried rolling back and that didn't help either. Is that correct?

Have you tried creating a new user and giving it access to your AFP share and see if the new account can authenticate?

I would also create a new dataset with same permissions as your troubled one and try connecting to that.

What are you permissions settings? Unix? Mac?

Can you do a screenshot of the dataset you are trying to access through the CLI and doing an "ls -la" command (post output in code tags here on forum).

 

[michael.keller]

Hi nojohnny101

Thanks a lot for your help! I could determine that the problem was on the share itself because of our investigation so far and read a bit about AFP shares. So I decided to take a shot at deleting and recreating the CNID database yesterday and today all seems to work fine. I finally have write permissions on my share again without the console showing any error messages. I still have absolutely no idea what caused this, or how to prevent this from happening again.
I used the

Code:

dbd -f <path to netatalk volume>

command to do this. As I consider myself anything but an expert I strongly recommend to anyone else having the same issues not to blindly use this command.

 

[nojohnny101]

Don't know how much I helped, but glad you got it solved. I have never heard for a corrupt CNID database causing that, good find! Just from the little googling I did just now after your post, seems like it was all yours symptoms.

Thanks for posting the solution, it is very likely to help someone in the future during searching!