Home / server / Questions / 672950
In Process
Tobia
Asked: 2015-03-05 03:48:59 +0800 CST

Can I store OS X resource forks in a Samba share anywhere *else* than in dotbar files?

  • 772

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.

 
Xattr

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)

 
Depot

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:

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

    # PERFORMANCE TUNING
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
    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

    # DEFAULT OPTIONS FOR ALL SHARES
    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

[homes]
    browseable = no
mac-osx

2 Answers

  1. 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.

    • 2

  2. 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.

    • 0