[lpi-discuss] Re: LPIC-3 core exam -- NFS _and_ SMB (not "versus")

Bryan J. Smith b.j.smith at ieee.org
Wed Dec 6 13:02:20 EST 2006

Steve Holdoway <steve at greengecko.co.nz> wrote:
> In a situation where both products will provide the same
> functionality, one is used *in preference* to the other. That's
> what the word means. 

But they do _not_ provide the same functionality.  SMB services
present _different_ meta-data to the client than NFS.

SMB presents clearly Windows client-centric meta-data and filesystem
organization, especially FAT blocks.  NFS presents clearly UNIX
client-centric meta-data and filesystem organization, especially
inode blocks.

Now if you're just using them to copy files, that's fine.  But we
have other, non-filesystem protocols for that.  Hence why these
protocols are often use as a "local-like filesystem" with the
applications directly accessing them.  And that's when things break.


Serve (and emulate on the _server_, if necessary) the filesystem that
the mapping/mounting _client_ expects.  If your client is Windows,
serve SMB (including emulating SMB on the UNIX/Linux server).  If
your client is Linux, serve NFS (including emulating NFS on the
UNIX/Linux server).  If your client is UNIX, SMB is often _not_ an
option at all.

It's much easier for a servers to emulate a network filesystem
protocol in a user-space service than it is for a client to translate
a non-native protocol at its virtual filesystem (VFS) level, if it
has one at all (or adds one).  That's because all the server is doing
is "sharing" the data, providing any locking or RPC mechanisms,
etc...  It's not running any "apps" in the emulation, any "apps"
would be local and work on the "native" filesystem.  But the client,
on the other hand, _is_ running "apps" on the "translated"

Now in the case of SMB to Linux, you are _emulating_ on the server,
then _translating_ on the client.  Nuts!  First off the SMBfs VFS
layer has to "translate" inode functions into FAT, then it sends it
up to the server, which "translates" it back from FAT to inode.  Now
Samba has some extensions to do this, but it's still not as "native"
as NFS' inode-to-inode reality.  In fact, Tridge & co. has constantly
stated they need a native SMB kernel module for the _server_ to "hook
into" filesystem operations like kernel NFS does.

If you're SMB is Windows, which doesn't have the Samba extensions,
and you're running SMBfs on the Linux client -- countless things
"just break" (just like user-space NFS does versus kernel-space NFS).
 That's why _enterprise_ who have Linux workstations _must_ use NFS. 
And if you have UNIX workstations, well then, SMB is _not_ even an

So unless you believe LPI should only cover Linux server-only
environments, unlike HP, Red Hat, Sun and virtually every other
UNIX/Linux certification program, NFS is a reality.  The driver for
NFSv4's augmented RPC capabilities are so massive by virtually every
enterprise that it has been OSDL's major, non-Linux integration
focuses for quite awhile now.  Why?  Because SMB is not even an
option for virtually all non-Linux platforms.

You want more Linux adopting in the enterprise?  You show enterprises
that Linux can really "serve it all" -- including replacing countless
AIX, HP/UX and Solaris capabilities, or at least integrating natively
with them.


Many NFSv4 concepts and configurations are _concurrent_ with
"advanced" Samba usage.

E.g., with NFSv4, IDMAP is a _standard_ RPC service.  It's the same
service which Samba also uses -- whether it's connecting to ADS or an
open LDAP tree (possibly with NSS capabilities, like Fedora DS).  In
fact, _unlike_ NFSv4 (which uses the _native_ GLibC functions), Samba
requires an extra user-space service in Winbindd to handle several

Same deal for authentication.  NFSv4 offer a _standard_ RPC service
to GSSAPI, a very flexible tie-in for authentication.  Samba actually
does as well.  We can "tie-down" to common implementations, such as
either Kerberos, or authentication against a LDAP tree (e.g., NSS). 
So when we do that for Samba, we do it for NFSv4 as well with just a
few, added concepts to the objective.

In a nutshell, these concepts are more "native" between Linux
(kernel/GLibC) and NFSv4 and related RPC service than Samba's RPC
services!  That's why when you cover Samba authentication and object
mapping, you basically cover the Linux capabilities that serve
NFSv4's RPCs too.

Now lastly, when it comes to Access Control Entries (ACEs), it's a
little more murky.  Unlike authentication and object mapping, where
NFSv4 RPC and core Linux (kernel/GLibC) capabilities match, NFSv4 has
its own, richer ACL (Access Control List) controls and ACE meta-data
than the POSIX ACLs built into the Linux kernel (since 2.5.3+
development).  The IETF is working on NFSv4 to POSIX ACLs mapping. 
So I stated unless a concept or configuration in NFSv4 RPC capability
is directly shared with the underlying ACL support in the Ext3 (or
XFS) filesystems, or a Samba ACL support configuration also addresses
it, we should leave it for now.

> In this case, samba can provide file sharing services to far more
> clients than NFS, so is functionally (not technically!) a superset
> of it.

Please point me to the SMB _client_ support in several UNIX

> And, because it grew up having learned the lessons of the
> early versions NFS, people who suffered greatly through them are (
> with reason IMHO - remember what it was like 15 years ago??? )
> biased against it.

Listen to yourself.  Now apply the same to SMB.

Ask yourself:  
  Where was Server Message Block (SMB) 15 years ago?  

Now ask yourself:  
  Where was SMB 10 years ago?  

And ask yourself one more question:    
  Where was Samba's SMB support just 5 years ago?  

Ten (10) years ago Linux's NFSv2 implementation _sucked_, and
_sucked_ hard.  I will full admit that.  It wasn't until the SGI
Trond+Higgen patches in 2000 that started to address many things (and
finally put in kernel 2.4.18 by Red Hat's Cox, although rather

At the same time, ten (10) years ago, Sun Solaris had NFSv3 support,
including NIS+ tie-ins and other capabilities, but that wasn't Linux.

Furthermore, just five (5) years ago, NFSv3 wasn't well implemented
on Linux as other platforms, and there was a darth of specific
implentations to address IETF options such as authentication,
authorization, mapping and other real-time (RPC-time) services.  Few
Linux vendors, like Red Hat, only offered mount-time or initial user
access-time Kerberos authentication.

Linux was still not "on-par" with even Solaris, and most other
commercial implementations.  And Sun even offered it's Sun One
network infrastructure, including NSS LDAP at its core.

Which is why, five (5) years ago, Sun got serious about making a true
UNIX-Linux infrastructure with true, UNIX-Linux native network file
services.  It _knew_ the key to that was Linux.  Almost three (3)
years ago, we got NFSv4 for the GPL Linux kernel with GPL user-space
services.  Leveraging existing GSSAPI, the same IDMAP services that
Samba 3.0 was also leveraging, etc...

In fact, OSDL's efforts are more about non-Linux than Linux.  SMB
does _not_ solve the network filesystem need for most UNIX platforms.
 Linux is already the "concentration point" for Windows servers, and
the _key_ to open enterprises is a Linux platform that addresses
*ALL* enterprise platform needs.

> Stop jumping down everyone's throats.

I'm sorry if I'm "jumping down everyone's throats" with the reality
of what _enterprises_ are actually deploying!

> Do you think your .sig allows you to do that?

Yes!  I am a "professional, technical annoyance."  That's because I
point out the obviousness of the truth of enterprises.

Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
     Fission Power:  An Inconvenient Solution

More information about the lpi-discuss mailing list