Special folders created inside Netatalk shares
(Originally by firstname.lastname@example.org 2001-10-20)
(Amended by Sebastian Rittau 2001-11-03)
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 I 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 the resource fork, or creator/type 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.
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. 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.
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. 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.
These will exist at the top level of each sharepoint on servers that run
netatalk compiled with the new CNID DB code. Any user who has write access
to any part of the share must have full write access to this directory /
file and all the files within it otherwise the CNID DB code will not work
Network\ Trash\ Folder/
This exists at the top level of each sharepoint. This is where files that
are put in the Trash on clients 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. Apple is aware of this problem
and is working on a solution.
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
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 file may appear in share points which have been accessed by a
machine running Mac OS X. Its permissions should be set to match
those of the enclosing directory.
For more info on how this file could pose a potential security risk
if you are sharing the same folder by HTTP, see: