Cnid db?

[Joe K]

Hello,

I recently installed FreeNAS 8 on a HP Microserver, and am currently in the process of copying several TB of data oto it. Everything fine so far, and pleasantly fast as well. My other computer is a MacBook Pro, and I was using AFP to copy the data

This morning there was a strange error message in a window on the Mac, it said:

"Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details! Switching to Read- only mode."

I rebooted the Microserver and I now can copy data onto it again, but it is now a lot slower than before. Also the FreeNAS share keeps unmouting itself in the middle of copying data.

What can I do? I haven't found any documentation on this, maybe somebody can point me in the right direction?

Thank you,
Joe

 

[OneStickShortOfaBundle]

I have exactly the same problem as Joe. I updated to the latest FreeNAS last night and now I get "Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details! Switching to Read- only mode." Can anyone offer some help that would be understood by a mere mortal such as me?

My volumes are now locked and I can't save anything to my server. Help please!


Update - I have just set up a completely new NAS and installed FreeNAS-8.0.1-RELEASE-amd64 on it and exactly the same problem has reoccurred with the new AFP I made. How do I fix this?

I've also discovered this :- In addition to the CNID DB problem 43,033 invisible ‘.AppleDouble’ folders and 12,790 visible ‘I7CIPB~N’ files have appeared on my server. Is it safe for me to delete all these files?

Unfortunately http://support.freenas.org/ticket/763 has been closed but it has not resolved my problem. They propose that I should - ‘Adjust your permissions so your guest or login account can write the .AppleDB files to the share. Once you do that, the problems both you and I have seen above will go away.’

I would be very grateful to anyone who could explain to me how to do this.

 

[labtopia]

i discovered this same problem today after upgrading to the release. this seems to be fixed with this action:

downloaded ONYX for mac, used the PARAMETERS/FINDER to 'show hidden files and folders
mounted the volume via SMB cifs share
renamed the .AppleDB folder to something else. (i later deleted the renamed folder)
unmounted and remounted via AFP, and no errors and R/W access is restored.
i am guessing the .AppleDB will be rebuilt as needed...

 

[labtopia]

i discovered this same problem today after upgrading to the release. this seems to be fixed with this action:

downloaded ONYX for mac, used the PARAMETERS/FINDER to 'show hidden files and folders
mounted the volume via SMB cifs share
renamed the .AppleDB folder to something else. (i later deleted the renamed folder)
unmounted and remounted via AFP, and no errors and R/W access is restored.
i am guessing the .AppleDB will be rebuilt as needed...

 

[OneStickShortOfaBundle]

i discovered this same problem today after upgrading to the release. this seems to be fixed with this action:

downloaded ONYX for mac, used the PARAMETERS/FINDER to 'show hidden files and folders
mounted the volume via SMB cifs share
renamed the .AppleDB folder to something else. (i later deleted the renamed folder)
unmounted and remounted via AFP, and no errors and R/W access is restored.
i am guessing the .AppleDB will be rebuilt as needed...

Thanks labtopia but I have tried that and I still keep getting told that I don't have permission to alter or delete the .AppleDB folder. :(

 

[pierrep]

hello
the bug was closed

in order to make it work, you need to recursively give write access to all .AppleD* directories and files.

To do that, the easiest is to make sure all users needing access are in the same group and this group gets write access to those files.

I don't know the exact reason (maybe new version of netatalk ?)

In my case, i have a "local" access type, so my users are in the group "users" which has write access to above-mentionned files

 

[OneStickShortOfaBundle]

hello
the bug was closed

in order to make it work, you need to recursively give write access to all .AppleD* directories and files.

To do that, the easiest is to make sure all users needing access are in the same group and this group gets write access to those files.

I don't know the exact reason (maybe new version of netatalk ?)

In my case, i have a "local" access type, so my users are in the group "users" which has write access to above-mentionned files

Thanks pierrep but I am sorry to be so stupid about this but there are so many options that I find this confusing.
At the moment I am the only user. I have not set up a group.
My Storage Permissions are set to Owner (user): wheel
Owner (group): wheel. Those were the default settings.
All of the Read, Write, Execute boxes are checked.
The Type of ACL: Unix
When I check the Check permission recursively: button and then Change it takes about a day before it tells me that the changes have been made and I find that the Write checkboxes have become unchecked for Group and Other.
But, I still can’t write to my storage. :(

 

[pierrep]

mmmhh
i must admit i'm not doing this through the GUI at all....
my users (2 of them) are in the group "users"

i did something like :

ssh <username>@<freenas>
->>> enter user password for freenas
su -
->>> enter admin/root password for freenas
cd /mnt/pool/dataset
chmod -R 755 .AppleD*
chgrp -R users .AppleD*

exit
exit

then restart the AFP service

wouldn't know how to do this through the GUI... except restarting AFP

 

[OneStickShortOfaBundle]

mmmhh
i must admit i'm not doing this through the GUI at all....
my users (2 of them) are in the group "users"

i did something like :


then restart the AFP service

wouldn't know how to do this through the GUI... except restarting AFP

Thanks. Is there a way to enter these commands from the GUI or do I have to connect up a monitor and keyboard to my NAS? I seem to remember that with FreeNAS 7 I could enter commands.

 

[Durkatlon]

You need to turn on ssh and then use a terminal client to log in remotely. People like PuTTY on Windows, not sure what's the equivalent on Mac.

 

[OneStickShortOfaBundle]

You need to turn on ssh and then use a terminal client to log in remotely. People like PuTTY on Windows, not sure what's the equivalent on Mac.

Thanks for the info. Unfortunately I am using a Mac and I don't have access to a PC. I wonder if it is possible to use the Terminal for this? I'd still need someone to hold my hand though.

 

[Durkatlon]

Yeah, the terminal in OSX is just Unix as far as I know. So you should be able to type "ssh <IP>" where <IP> is the IP address of your FreeNAS box, and it should come up with a login prompt. Of course the ssh service must be turned on on the FreeNAS side.

 

[OneStickShortOfaBundle]

Yeah, the terminal in OSX is just Unix as far as I know. So you should be able to type "ssh <IP>" where <IP> is the IP address of your FreeNAS box, and it should come up with a login prompt. Of course the ssh service must be turned on on the FreeNAS side.

OK I’ve turned on ssh and I can ssh <username>@192.168.1.101 but it will not let me type or paste in my password.

 

[OneStickShortOfaBundle]

Please can someone tell me how to resolve this CNID DB problem before I am forced to abandon FreeNAS altogether and look for alternate NAS software. I have tried all the advice that has been given but I am still locked out of my server several weeks after the problem began.

I do not know how to allow access to the .AppleDB files with my Mac. There does not seem to be any way to do this from the GUI and I do not possess the knowledge to do it from the Terminal.

Please unlock this ticket <http://support.freenas.org/ticket/763> as it has not been resolved for those of us using the GUI. Far more detailed guidance is needed to enact a fix.

 

[OneStickShortOfaBundle]

Thanks to everyone who has tried to help but I’m afraid that none of the advice has worked. I still can’t write to my server. The only thing that I can think of is to delete the whole ZFS RAID volume and create a new one then restore the data from the backup. Are there any last suggestions before I take this drastic step?

 

[labtopia]

i know you might have tried but like i mentioned, this for me was fixed by deleting the hidden apple dir and rebooted nas. they were rebuilt as macs reaccessed the volume with afp. everything has been fine since. also i havve applied the 8.0.2 update and some other things are fixed too like emails.

you might try this update as well.

you should not have to 'blow away' your volume at all

hope this helps

 

[OneStickShortOfaBundle]

i know you might have tried but like i mentioned, this for me was fixed by deleting the hidden apple dir and rebooted nas. they were rebuilt as macs reaccessed the volume with afp. everything has been fine since. also i havve applied the 8.0.2 update and some other things are fixed too like emails.

you might try this update as well.

you should not have to 'blow away' your volume at all

hope this helps

Thanks labtopia but I have tried all of that and I cannot delete the necessary files either from AFP or SAMBA. I keep getting told that I do not have the necessary permission. I have tried numerous permission settings (recursively) but it doesn't seem to make any difference. If I could just delete these stubborn files then I could move on. :(