Native SMB/CIFS through ZFS or Samba Instead

In my experience the kernel mode server out performed samba with my clients. If performance is your number one concern, skip samba. That said, there are a number of limitations to the Solaris kernel-mode SMB/CIFS server, most notably:

• Only runs in the global zone. Samba can run in multiple isolated zones and/or the global zone simultaneously.
• Sharing happens at the filesystem level, not the directory level. So for new shares, zfs create pool/fs a new zfs filesystem, copy data over and share it (instead of sharing an existing directory)
• No following symlinks in shares, unless they are on the same filesystem.
• No child mounts. If you share a filesystem, sub filesystems are not shared. (e.g. two filesystems, pool/fs and pool/fs/subfs. If you share pool/fs, you won't be able to access the contents of pool/fs/subfs without sharing it separately. It'll show up as a directory via SMB, but will be inaccessible.
• None of the Domain controller/AD Master, WINS Server and other niceties of Samba

Of course doesn't do cross-protocol locking (a file locked via SMB is also locked via NFS when nbmand=on is set with the in-kernel server) and doesn't do VSS integration so snapshots show up in the Windows 'Previous Versions' tab in the properties window.

If you can live with the limitations of the kernel mode server and you don't need zone-level isolation, I think it's the way to go. If you're a heavy Linux/Samba user now and like some of it's unique features, feel free to stick with it. Also of note, if you're running SmartOS the choice has been made for you, they make it nearly impossible to run stuff in the global zone (with good reason) so you'll have to use OmniOS, OpenIndiana or Oracle Solaris if you hate Samba.

Another issue with the native SMB server: it won't share remote filesystems mounted via NFS. Now that may sound like a bad idea at the best of times, but it was an easy way for us to, for example, make some web development areas accessible to folks. We didn't worry about the file locking issues because the web developers were (a) mostly using Dreamweaver, which uses its own file based check in/check out methods; (b) a fairly small close-knit group; and (c) generally responsible for areas without much overlap. I can't think of more than a handful of times that developers overwrote each others files (and generally file locking wouldn't have helped).

So, finding out that the shiny new server wouldn't happily share these files was a bit of a surprise, especially because this point didn't seem really emphasized in the various sites discussing the new SMB server. Ah, well, if there's one thing I've learned about Solaris it's that: "things change". :)

And, I concur that, unless these needs are critical for your shop, the native SMB server is the way to go. It lacks the flexibility of Samba, but it does seem to "just work" once it's set up, and it does seem to have pretty good performance.