Bagpuss Posted October 4, 2011 Share Posted October 4, 2011 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. Quote Link to comment
mgoh99 Posted December 18, 2011 Share Posted December 18, 2011 Hi I just started getting this message after upgrading from b11 to b14. Anyone else experiencing this on beta 14 Quote Link to comment
darkside40 Posted December 24, 2011 Share Posted December 24, 2011 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) Quote Link to comment
EdgarWallace Posted January 7, 2012 Share Posted January 7, 2012 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? Quote Link to comment
1080p Posted January 26, 2012 Share Posted January 26, 2012 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? Quote Link to comment
1080p Posted January 30, 2012 Share Posted January 30, 2012 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. Quote Link to comment
dgaschk Posted January 30, 2012 Share Posted January 30, 2012 Use: rm -R ./.[Aa]pple* This will remove all files beginning with .apple or .Apple Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.