Inside netatalk share points you will find several files and directories which are created automatically by the afpd process either for its own internal use or for the internal use of the MacOS. None of them should be directly visible in the Finder on the Mac.
Many of them have to be writeable in order for netatalk to function properly. This can present problems if users have shell access to the netatalk server. At the very least, users can "hide" files inside these writeable folders. At worst, a malicious user could confuse netatalk in a bad way. It is unlikely that a malicious user could cause loss of another user's data by exploiting permissions on these items.
Below is what we hope to be a comprehensive list of these files and directories, their purpose, and a discussion of what Unix permissions should be set on them.
Note that in general on Netatalk shares, all directories should have the setgid bit set. This forces any new files or folders created to have the same group as the folder they were created in. On some operating systems, notably FreeBSD, the group owner is always inherited from the parent directory, so the setgid bit is not necessary.
This directory exists inside each folder on a Netatalk share. It contains meta information like creator/type and eventually the resource fork of each file in that folder. Its permissions should match those of its parent directory, i.e. anyone who has write access to the parent directory must have write access to the corresponding .AppleDouble directory.
This file specifically contains meta information about the directory. If the directory is the volume root then it contains the volume specific metadata, especially the "volume creation time" (important since AppleShare clients differentiate bitween different volumes on the same server by this timestamp)
This directory exists under the top level of each share point. It contains the "desktop database" which is the method by which the MacOS associates a type/creator code with a particular application (for an in-depth discussion have a look at http://www.tempel.org/macdev/#DTDB). Without it, documents will lose their application-specific icons and will have a generic icon instead. Double-clicking documents will also fail.
To allow the desktop database to be maintained correctly, any user who is likely to copy an application on to the share must have write access to this directory and all directories below it.
This file contains afpd internal volume specific information like $MAC_CHARSET/$VOL_CHARSET, AppleDouble scheme, CNID backend (including cnid_metad settings if applicable), dbpath and the like. The information in this file will be also used by tools like megatron(1) to correctly convert files to data exchange formats like MacBinary for example.
Icon\r and .AppleDouble/Icon\r
These files will exist in any folder, including the top level of a share, if it has a custom icon and has been created with MacOS versions prior to MacOS X. Make them writeable to any user who should be allowed to change that custom icon; make them read-only if you don't want the custom icon to be changeable.
MacOS X stores a custom volume icon into this file (this won't be displayed on Macs running MacOS versions < X)
This folder will exist eventually at the top level of each sharepoint driven by the cdb or dbd CNID-backends. When using cdb any user who has write access to any part of the share must have full write access to this directory and all the files within it otherwise the CNID-backend will not work properly. Please note that you can force a different location of this folder via the dbpath option in AppleVolumes.default.
Network Trash Folder/
This exists at the top level of each sharepoint. This is where files that are put in the Trash on clients (prior to MacOS X) go, until the Trash is emptied.
The permissions of items in this directory are a pretty complicated subject, but basically you should make this directory and everything in it world-writeable if you want the Trash can to work properly. If you don't make it writeable then users will get a message "That item cannot be put in the Trash. Do you want to delete it immediately?" if they try to put something in the Trash.
Unfortunately networked trash handling is broken in current versions of Mac OS X even if this directory is writeable.
This folder may exist at the top level of a sharepoint. This folder is used by certain applications (Adobe Photoshop among others) to store, well, temporary items. These programs may not work correctly if this folder is missing or not writeable, when a user tries to work on a document stored in that Netatalk share.
This folder is used by Sherlock 2 to store information use by its Find by Content feature. Make it writeable by users if you want to allow them to update the Find by Content index on a netatalk share. Otherwise, make it read-only.
This folder is created at the top level of each share point. It always appears to be empty. It would be wise to set its permissions the same as the top level of the sharepoint.
This appears in share points which have been accessed by a machine running Mac OS X and contains folder specific metadata as well as file specific like eg. file comments.
FBC = FindByContent. This File is generated by OS X is roughly equivalent to OS 9's "TheFindByContentFolder". Gets generated only if a search with activated indexing was performed. Make it writeable by users if you want to allow them to update the Find by Content index on a netatalk share. Otherwise, make it read-only.
contains the :2eFBCSemaphoreFile (.FBCSemaphoreFile) for OS X.