AFP not working - logs show 'no space left on device'

[wishie]

As the title suggests, I can no longer seem to mount any AFP shares, and the unRAID logs show errors as follows (full diagnostics also attached to post):

 

Aug 10 13:32:30 wishie cnid_dbd[32310]: Error opening lockfile: No space left on device
Aug 10 13:32:30 wishie cnid_dbd[32310]: main: fatal db lock error
Aug 10 13:32:30 wishie cnid_dbd[32310]: Failed to open CNID database for volume "Time Machine"
Aug 10 13:32:30 wishie cnid_dbd[32310]: delete_db() failed: No space left on device
Aug 10 13:32:30 wishie cnid_dbd[32310]: reinit_db() failed: No space left on device
Aug 10 13:32:30 wishie afpd[31924]: read: Connection reset by peer
Aug 10 13:32:31 wishie cnid_metad[32343]: Multiple attempts to start CNID db daemon for "/mnt/user/Time Machine" failed, wiping the slate clean...

 

I can't see any of my disks being anywhere near capacity.. the only thing that was close, was my docker image, which i've now doubled in size, but still have the issue.

 

Since I use the AFP share for my Time Machine backups, it's pretty important to me that it continues to work. Apparently you can do Time Machine over SMB with High Sierra, but I've yet to get that to work. Any help on that would also be appreciated.

wishie-diagnostics-20180810-1334.zip

[John_M]

It's caused by corruption of the Netatalk database, which has proven to be quite fragile. There's a separate database for each AFP-exported share and it's kept in the .AppleDB folder in the root of the share. So for a share called ShareName, the database folder is /mnt/user/ShareName/.AppleDB.

 

There have been discussions about this before here, here and here. The trouble is that AFP is not used much these days and support for it might well be removed from unRAID in the not too distant future. I'll be disappointed when that happens because I have a number of old Macs that can't be upgraded to newer than OS X Lion and whose SMB implementation is clunky. In the meantime here's what you can do to improve your own experience.

 

The quick fix is to shut down your Mac, then from the unRAID command line delete the .AppleDB folders from the root of each share.

rm -rf /mnt/user/ShareName/.AppleDB

Then restart the Netatalk service (rebooting your unRAID server will do that). Then restart your Mac and mount the share. This initial mount will take a while as the database is rebuilt.

 

A longer term fix is to do what I did and move the location of the database away from the root of the share. A good location would be onto your cache pool. Unmount all AFP-mounted shares first. I made a new folder within the system folder (/mnt/cache/system/AppleDB) and pointed Netatalk to it - in the unRAID GUI go to the Shares page and choose one of your exported shares. Scroll down to AFP Security Settings and edit Volume dbpath to be the name of the new location (in my case, /mnt/cache/system/AppleDB) and click Apply. Repeat for your other AFP exported shares, giving the same location. When you next AFP mount your shares the /mnt/user/ShareName/.AppleDB folder will automatically be relocated to /mnt/cache/system/AppleDB/ShareName/.AppleDB where it is much more responsive and much less prone to corruption.

 

Edited August 10, 2018 by John_M
Typos

[wishie]

Cool, thanks for that.. I will do as you have done and move the .AppleDB files onto the cache SSD.

Have you tried using TimeMachine over SMB in High Sierra (if you have any Macs running High Sierra) ?

 

[John_M]

I do have a MacBook Pro that runs High Sierra and I use SMB whenever I mount an unRAID share but I don't use unRAID as a Time Machine destination for that computer. I just use a USB-connected external hard disk.