Re: NFS + Win XP -- NFS for UNIX/Linux clients, SMB for Windows

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Sat, Jan 01, 2005 at 04:21:33PM -0600, NZG wrote:
> Originally I was thinking of using NFS, serving from the Debian box.
> The only problem being that XP doesn't appear to have native NFS support.
> Is this the best route?

On Sat, 2005-01-01 at 14:55, Steven Pritchard wrote:
> No.  Use Samba.  That's what is is for.

Agreed.

Some people make it a NFS v. SMB argument, and get keep into it.  Many
state that NFS is insecure, but SMB can (and _is_ by default) just as
insecure -- especially if you are providing legacy services for NT4 and,
worse yet, DOS7 (95/98/ME).  The "encrypted passwords" of SMB is a 100%
marketing and 100% false security implementation, as a replay is 100%
usable for login.

In a nutshell, NFS caters to inode filesystems.
SMB caters to file allocation table (FAT) filesystems.

Why is this important?  A server is a server, it serves out data.  But
the client, it not only receives the data, but presents it in a form the
_programs_ expect.  If the programs don't like the meta-data of the
filesystem it is accessing, especially a network filesystem, that could
be a problem.  So if it's only presenting local data and interfaces
remotely, and not running programs on that data remotely, it is much
easier for the server to translate for the client than vice-versa.

For a UNIX/Linux client, it natively wants an inode filesystem.  As
such, you should run NFS from your server, be it native UNIX, or
something like the _free_ Services for UNIX (SFU) from a native Windows
Server.  The lineage of the Intergraph AccessNFS licensed in SFU goes
back to Sun's PC-NFS, basically the creator of NFS (among other
technologies/code Linux owes much gratitude to ;-).  It's not perfect,
but it's much better for the UNIX/Linux client than the UNIX/Linux
client-ignorant stream in SMB.  Now there _are_ different
versions/features of NFS, and Linux has had a history of _poor_ NFS
support prior to 2.2.x with the SGI/Trond patches.  But for the most
part, the NFS v3 implementation in kernel 2.4 is much better, and NFS v4
in 2.6 fairly ideal (thanx to help from SGI and Sun).  But there are
still some limitations with the Linux NFS implementation that one should
know about (especially when using non-Linux UNIX implementations).

For a Windows client, be it DOS or NT, it natively wants a FAT
filesystem approach.  Many Windows programs also rely on unstable
approaches such as peer-concurrency (server-less concurrency) where
clients must trust one another.  These facilities only work best over
the SMB.  Ironically, Samba offers far more SMB features than native
Windows Servers -- especially for pre-NT5.1 clients using Samba 3 versus
native NT5.1 (2003).  But SMB is _still_ the protocol you want the
server presenting to the Windows client.

Now newer NFSv4 offers many extensions that are SMB-like, such as byte
locking, although it's not for unstable server-less concurrency as is
required in typical Windows clients.  And the new NT5.1 SMB
implementation offers some more stateful facilities for disconnects,
security and other features.  It's a long debate, but there is
absolutely no "better" argument that can be made between the two
protocols -- because they serve different purposes.

So with that said, we come back to the "most compatible" argument:  
  NFS for UNIX/Linux clients
  SMB for Windows clients

Now another major network filesystem is Andrew Filesystem (AFS).  I
won't go into it because it is very different than NFS or SMB.  In a
nutshell, NFS and SMB still allow _local_ access, AFS does not.  In
other words, AFS is a virtual filesystem that you cannot access locally,
not even on the server itself, but only over the protocol.  The free
OpenAFS server/clients are still lacking some capabilities, such as some
32-bit/2-4GB filesize limitations and no byte-locking facilities (at
least not in all OpenAFS clients/servers yet).


-- 
Bryan J. Smith                                    b.j.smith@ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.




-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.