Samba4, ZFS on Linux and Mac OS X clients

After quite a bit of testing last year, I got Samba 3.6.x to play pretty nicely with Mac OS X clients. Pretty nicely in this context means that the logon and permissions worked as needed, the performance was decent and office programs and adobe programs worked with files on the share.

After reading about some new things coming to samba4 (thank you Ralph for your comments on the macenterprise email list), especially in terms of support for Mac clients, I decided that some upgrades were needed.

I have used Debian as my primary Linux platform for some time now. The tools provided by the repositories are solid, and I can always build my own when I need something more cutting edge. In this case, I have been using debian stable 7.7.

ZFS on Linux has been rock solid for me, and provided many incredibly useful tools (autosnapshot, zfs send/receive, growing a FS by replacing drives with bigger disks etc.). I use the one I get from the zfsonlinux repositories for debian. At the time of writing, I am using the following:

root@fileserver:~# dmesg | grep -E 'SPL:|ZFS:'
SPL: Loaded module v0.6.3-295_ga9d5f15
ZFS: Loaded module v0.6.3-763_ge883253, ZFS pool version 5000, ZFS filesystem version 5
The version samba4 I am using for the setup below is [samba 4.2.0 rc2](https://download.samba.org/pub/samba/rc/WHATSNEW-4.2.0rc2.txt), together with a specific patch extracted from [https://github.com/slowfranklin/samba/commits/aapl](https://github.com/slowfranklin/samba/commits/aapl) to enable the vfs_fruit functionality.

The samba team recentely released samba 4.2. RC3, which has all the vfs_fruit and aapl extensions built in.

After a lot of testing I have managed to come up with the following setup which seems to do all the stuff I want it to:

[global]
    workgroup = WORKGROUP
    realm = EXAMPLE.COM
    netbios name = SHARENAME
    server role = active directory domain controller
    dns forwarder = 192.168.0.1
    idmap_ldb:use rfc2307 = yes
    unix extensions = no
    inherit permissions = yes
    printcap name = /dev/null
    load printers = no
    cache directory = /var/cache/samba/runlocks
    log level = 3
    max log size = 0
    log file = /var/log/samba/log.%I
    debug hires timestamp = yes
    inherit acls = yes

[netlogon]
    path = /var/lib/samba/sysvol/example.com/scripts
    read only = No
    browseable = no
[sysvol]
    path = /var/lib/samba/sysvol
    read only = No
    browseable = no

[fileshare]
    comment = Fileshare for example.com
    path = /zfs_filesystem/sharedfolder
    read only = no
    writeable = yes
    oplocks = yes
    level2 oplocks = yes
    kernel oplocks = yes
    dos filemode = no
    dos filetime resolution = yes
    dos filetimes = yes
    fake directory create times = yes
    browseable = yes
    csc policy = manual
    veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
    nt acl support = no
    create mask = 664
    force create mode = 664
    directory mask = 2775
    force directory mode = 2775
    guest ok = no
    vfs objects = fruit streams_xattr recycle
    fruit:resource = file
    fruit:metadata = netatalk
    fruit:locking = none
    fruit:encoding = private
    acl_xattr:ignore system acls = yes
    vfs objects = recycle
    recycle:repository = /files/jako/trash
    recycle:versions = true
    recycle:keeptree = yes
    recycle:directory_mode = 660

There is still some wonkiness with this setup:

There are some settings on the ZFS side I found helpful:

files   compression    off            default
files  xattr      on         default
files  acltype        posixacl   local

The zfs support for posixacls seems solid, and makes managing the acls a breeze.

There is an option of storing the xattrs with the inodes, instead of a seprate tree (http://www.nerdblog.com/2013/10/zfs-xattr-tuning-on-linux.html). I just have no idea how this would effect the vfs_fruit extension above or the Adobe programs that use xattrs to store all kinds of stuff, and might result in very big xattrs. Much more lab work is required to sort this out...

There must a ton of things I could do better, and I will appreciate any and all feedback. Testing something like this just tends to be very time consuming, as there are so many moving parts. I just hope this post helps other macadmins to test the open source samba. Special thanks to Ralph Böhme from SerNet for his pointers and patches.

comments powered by Disqus