Apenas um tiro muito selvagem no escuro; documentação do netatalk diz isso:
The AFP protocol mostly refers to files and directories by ID and not by name. Netatalk needs a way to store these ID's in a persistent way, to achieve this several different CNID backends are available. The CNID Databases are by default located in the @localstatedir@/netatalk/CNID/(volumename)/.AppleDB/ directory.
cdb
"Concurrent database", backend is based on Oracle Berkley DB. With this backend several afpd daemons access the CNID database directly.
Berkeley DB locking is used to synchronize access, if more than one afpd process is active for a volume. The drawback is, that the crash of a single afpd process might corrupt the database.
O BerkeleyDB já me mordeu tantas vezes no passado (com o outro software, eu não usei o netatalk) que eu acho que pode ser o problema, mais uma vez. Se você estiver usando o backend do CDB e houver arquivos BDB ( *.bdb
ou mais) presentes no diretório @localstatedir@.../.AppleDB/
, tente fazer backup desses arquivos em algum lugar e, em seguida, execute o comando db_repair
lá. O nome do comando pode ser db4.9_repair
ou similar, refletindo a versão atual do BerkeleyDB.