OS X resource forks are alternate streams of data attached to regular files. They may contain the file's custom icon, colored label, keywords, or any other metadata set by the user or by applications.

They are natively supported by OS X's HFS+ filesystem, but whenever OS X mounts another filesystem, whether local (FAT32) or remote (NFS, SMB) they are stored in so-called "dotbar" files: the resource fork for the regular file name.ext is stored in another regular but hidden file ._name.ext. (They are not to be confused with .DS_Store files, which store a directory's view settings, such as icon vs. column view, or the position of its window.)

The problem with dotbar ._ files is that they are actual regular files, in the target filesystem, with the same extension as the original file, therefore wreaking havoc in a number of ways. For example, Ant and Maven will see ._MyClass.java as yet another Java file to compile.

I see that OS X can be configured to store resource forks in SMB named streams and that Samba can be configured to store named streams in POSIX extended attributes or, alternatively, in a depot directory somewhere else.

Both solutions would solve the problem of dotbar files polluting the target filesystem, but I cannot get either to work.


First I tried with xattr:

vfs objects = streams_xattr
kernel oplocks = no

The latter option is due to this bug. I told OS X to use it, by doing this in the root of the share, before mounting it:

touch .com.apple.smb.streams.on

But when I tried to copy a file over with Finder, I got this error:

The Finder can’t complete the operation because some data in “hello.java” can’t be read or written.
(Error code -36)


Then I tried with depot:

vfs objects = streams_depot

leaving .com.apple.smb.streams.on in the root of the share. Trying to copy the same file with Finder, I got another error:

The operation can’t be completed because an unexpected error occurred
(error code -50)

How can I make OS X work with either of these two options? My purpose is to get those nasty ._ out of the shared directories.

I tried simply veto'ing dotbar files:

veto files = /._*/
delete veto files = yes

But that causes some applications to fail, for example Mercurial when run from OS X over a mounted SMB share.

I'm using OS X 10.9.5 as the client; Samba 3.6.6 from Debian Wheezy as the server.

Edit: here's my configuration as requested:

    security = user
    invalid users = root
    workgroup = COMPANY_NAME
    encrypt passwords = true
    panic action = /usr/share/samba/panic-action %d
    syslog = yes
    syslog only = yes

    read raw = true
    write raw = true
    use sendfile = true
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384
    max xmit = 131072
    getwd cache = true

    writeable = true
    force group = company_group

    create mask = 664
    security mask = 664
    force create mode = 664
    force security mode = 664

    directory mask = 2775
    directory security mask = 2775
    force directory mode = 2775
    force directory security mode = 2775

    # solve problem where OS X clients remove mode 0100
    map archive = no

    browseable = no
  • Did you tried to change the unix extensions directive into the [global] session to see if solves your case? Can you update your question with the output from testparm command?
    – fgbreel
    Mar 18, 2015 at 17:57
  • @fgbreel Added configuration to my question. I haven't tried changing unix extensions, because it's enabled by default (and I kind of need to map symbolic links and stuff.) Do you think I should disable it?
    – Tobia
    Mar 19, 2015 at 9:40
  • Yes, don't make sense :(
    – fgbreel
    Mar 19, 2015 at 11:58

2 Answers 2


It looks like you might be able to do this with the new vfs_fruit module, stacked with the vfs_streams_xattr VFS module.

See, for example, this mailing list thread. You need an underlying filesystem that supports extended attributes, and you have to have it mounted with them enabled.

However, according to the Samba wiki, this is a new feature in Samba 4.2, so you're going to need to upgrade. (As of right now, even Debian Sid [experimental] doesn't have 4.2 yet.)

If you're not interested in ditching the Debian package and building a new version of Samba (or upgrading to Jessie and waiting for 4.2 to show up in jessie-backports), you can hide dot files from the clients.

You could have two different shares that point to the same directory, one of which hides the ._files, for example. Perhaps not optimal, but might be workable.


I don't know if it's possible with native Mac preferences, but you can use a tool like Asepsis to assist with that problem. It'll move all Mac droppings to their own folders.

  • Last time I checked, Asepsis only removes .DS_Store files, not the "dotbar" ._* files which cause the most problems in network shares
    – Tobia
    Apr 27, 2015 at 18:37
  • @Tobia: You raise a good point. In that case, I found BlueHarvest as well, but it's not free. Looks like BlueHarvest uses real-time monitoring whereas Asepsis uses passive re-direction (via patching a system file). Apr 27, 2015 at 18:45
  • Thanks. But I'll wait for a solution on the Samba side, since I believe it's just a matter of configuration.
    – Tobia
    Apr 28, 2015 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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