Hi All,

 

Have got a problem with AFP shares on my unRAID box running b12 on a HP Proliant MicroServer (1.3GHz AMD Neo), 2GB ram.

My client machine is a first generation MacPro dual 2.66GHz Xeon running 10.6.8, 4GB ram.

 

When trying to mount an AFP share, I get the following message on the Mac:

Something wrong with the volume's CNID DB, using temporary CNID DB instead. Re-mounting read-only. Check server messages for details!

 

On the unRAID side, I see the following messages in the log:

Oct  4 14:17:49 MicroServer afpd[3462]: transmit: Request to dbd daemon (db_dir /mnt/user/media) timed out.

Oct  4 14:17:49 MicroServer afpd[3462]: Reopen volume /mnt/user/media using in memory temporary CNID DB.

 

When this happens, I've found that doing the following cures the problem:

 

1. Stop netatalk.

2. Delete the .AppleDB cnid db in the root of my share(s).

3. Running 'dbd -r', followed by 'dbd -rf' if errors are shown from the output of the first command.

4. Start netatalk.

 

However, this process takes 5-6 hours on my largest share, due to the large number of files.

This is now the 3rd time that I've seen this corruption of the CNID DB, and I'd really like to know what's causing it.

 

There are some suggestions on other forums that the corruption is down to sharing the volume simultaneously over SMB and AFP. The suggestion is to disable SMB sharing. This simply won't work for me, as I need to access the server from both Windows and Mac clients.

 

If anyone has any ideas or suggestions, please let me know.

 

Andy.

 

 

 

 

Hi I just started getting this message after upgrading from b11 to b14.  Anyone else experiencing this on beta 14

I get the Message when Time Machine tries to mount a Public AFP User Share by itself.

 

When i mount it manually time machine does it job as normal.

 

I use b13.

 

Edit:

By the way when connection fails i always have this message in my Syslog:

Dec 25 17:53:26 HTMS afpd[5261]: dsi_stream_read: len:0, unexpected EOF
Dec 25 17:53:26 HTMS afpd[5200]: dsi_stream_read: len:0, unexpected EOF

And what temporarely solve the problem for me is the restart of the afpd service (for example by changing something in the shares export options)

Same here - since a couple of days my server is reporting this:

 

Jan  7 16:42:17 Tower cnid_dbd[4334]: Error opening lockfile: Permission denied (Errors)
Jan  7 16:42:17 Tower cnid_dbd[4334]: main: fatal db lock error (Errors)
Jan  7 16:42:17 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:17 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:18 Tower cnid_dbd[4340]: Error opening lockfile: Permission denied (Errors)
Jan  7 16:42:18 Tower cnid_dbd[4340]: main: fatal db lock error (Errors)
Jan  7 16:42:18 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:19 Tower cnid_dbd[4341]: Error opening lockfile: Permission denied (Errors)
Jan  7 16:42:19 Tower cnid_dbd[4341]: main: fatal db lock error (Errors)
Jan  7 16:42:19 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:20 Tower cnid_metad[4342]: Multiple attempts to start CNID db daemon for "/mnt/user/Fotos" failed, wiping the slate clean... (Minor Issues)
Jan  7 16:42:20 Tower cnid_dbd[4342]: Error opening lockfile: Permission denied (Errors)
Jan  7 16:42:20 Tower cnid_dbd[4342]: main: fatal db lock error (Errors)
Jan  7 16:42:20 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:21 Tower cnid_dbd[4343]: Error opening lockfile: Permission denied (Errors)
Jan  7 16:42:21 Tower cnid_dbd[4343]: main: fatal db lock error (Errors)
Jan  7 16:42:21 Tower afpd[4114]: read: Connection reset by peer
Jan  7 16:42:38 Tower last message repeated 18 times
Jan  7 16:42:38 Tower afpd[4114]: transmit: Request to dbd daemon (db_dir /mnt/user/Fotos) timed out.
Jan  7 16:42:38 Tower afpd[4114]: enumerate(vid:24, did:2, name:'.'): error adding dir: '1998' (Errors)
Jan  7 16:44:23 Tower sshd[4635]: Accepted password for root from 192.168.178.27 port 49616 ssh2
Jan  7 16:44:23 Tower sshd[4639]: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory
Jan  7 16:44:23 Tower sshd[4639]: lastlog_openseek: /var/log/lastlog is not a file or directory!
Jan  7 16:44:23 Tower sshd[4639]: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory
Jan  7 16:44:23 Tower sshd[4639]: lastlog_openseek: /var/log/lastlog is not a file or directory!

 

Might have something to do with these errors .... TM is trying to renew the backup after a short period of time (only about a month last time):http://support.apple.com/kb/HT4076

 

Anyone experience the same issues?

I have just noticed something similar after downgrading my server to 5.0b10 due to RAID card issues.

 

This is from the log when I try to mount a share from an OS X Lion computer:

 

Jan 27 12:15:22 passionfruit afpd[3511]: AFP3.3 Login by nobody
Jan 27 12:15:29 passionfruit cnid_dbd[3520]: Set syslog logging to level: LOG_NOTE
Jan 27 12:15:29 passionfruit cnid_dbd[3520]: error deleting key/value from cnid2.db: DB_SECONDARY_BAD: Secondary index inconsistent with primary
Jan 27 12:15:29 passionfruit cnid_dbd[3520]: dbd_delete: Unable to delete entry for CNID 24
Jan 27 12:15:29 passionfruit afpd[3511]: Reopen volume /mnt/user/applications using in memory temporary CNID DB.
Jan 27 12:15:58 passionfruit afpd[3511]: AFP logout by nobody
Jan 27 12:15:58 passionfruit afpd[3511]: AFP statistics: 2.80 KB read, 9.97 KB written
Jan 27 12:15:58 passionfruit afpd[3511]: done

 

OS X displays an error from my unRAID server and then I eject the share. Am I able to flush the AFP DB manually somehow?

I've had a little success with my DB_SECONDARY_BAD issue. I managed to make AFD happy again by logging in via the console of my server and entering the following at the root of each user share:

 

rm -R ./.AppleDB

 

After stopping Plex, the array and rebooting the server I was able to mount my shares as normal from OS X.

Use:

rm -R ./.[Aa]pple*

 

This will remove all files beginning with .apple or .Apple