I'm much more concerned about QNAP reversal to the distributed CNID DB aka DBD (with the CNID DB corruption issues resulting form unclean closed AFP client connections) from the NAS-based centralized one - leading to some more overhead on the initial connection - than on the storage location. Correct my if I'm wrong, have not spent a lot of time to check.

AppleDB subfolder again: # ls -ls /share/MD0_DATA/Multimedia/.AppleDB/cnid2.db 388 -rwxrwx- 1 admin administ 389120 Sep 12 14:42 /share/MD0_DATA/Multimedia/.AppleDB/cnid2.db* However, during QTS 4.1.0 Beta, there were some builds which used the storage volume based (and AFAIK this was also used with CDB instead of DBD): # ls -ls 88 -rw-r-r- 1 admin administ 86016 No idea what 'bug' you are behind here: DBD is default, as well as the storage location for the CNID DB (certainly on the QNAP afpd builds) - this config is not used in the QNAP dynamically created and maintained /etc/nf anyway. Xander-27 wrote:- dbpath for all shared folders are : (default location) QTS 4.1.0 2014061x as well as QTS 4.1.1 20140828 does make use of the 'classic'. Here is an example of the same issue resolved by using the vol dbnest option (too bad we can't try it on 3.0.5.) : Thanks for your help ! Xander. Netatalk is in version 3.0.5 (QNAP firmware up-to-date 4.1.0) (current netatalk version : 3.1.6) - CNID backend is DBD - dbpath for all shared folders are : (default location) What do you think ? Is that a bug of version 3.0.5 ? Informations that could be useful : - From version 3.0.6 of netatalk, there is an option 'vol dbnest' to force the behaviour (default to false) I describe : NEW (Changes in 3.0.6) : Option 'vol dbnest', when set to true, the CNID database for a volume is stored in the volume root of a share in a directory. However, from versions 3.x of netatalk, and with actual configuration, I think it should not. AppleDB folder is created at the root of the share to store the CNID database. Hello, When a shared folder is accessed via AFP, a.

Netatalk share home folder