Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running a netatalk server process on my linux server that serves files up to Mac client machines. Whenever you use Mac's Finder to access foreign filesystems over netatalk, it creates '.DS_Store' files to store information about the folder.

Normally, these files would be hidden by default, and I wouldn't care. Unfortunately, netatalk doesn't allow access to local hidden files, so when the Mac writes and reads these, it renames them :2eDS_Store on the local filesystem. When you have a deep tree, you end up with these littered all over the place, and other Windows and Linux clients have to deal with them.

How do I make these available to Mac clients and hidden from everyone else?

share|improve this question
Has your question been answered here or somewhere else? How about marking an answer... – Bennett Dill May 25 '10 at 15:23
It wasn't answered until just now... – Douglas Mayle Jun 17 '10 at 10:30
up vote 2 down vote accepted

For each share in /etc/netatalk/AppleVolumes.default add options:usedots to make Netatalk create .DS_Store instead of :2eDS_Store. The files will still be there, but as dot-files they'll be invisible.

share|improve this answer
This is what I ended up doing... – Douglas Mayle Jun 17 '10 at 10:30

One workaround is to use TinkerTool or BlueHarvest on each Mac to disable the creation of .DS_Store files on non-local disks.

share|improve this answer

Here is a guide on how to disable it's creation on Macintosh based clients: (With out third party tools)

share|improve this answer

Haven't tried this one. (just brainstorming)

However, does anyone know whether unionfs can do the trick?

I mean, could we write those files to a specific tree? Where Linux and Windows clients would not see them.

Regards Mike

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.