[NTLUG:Discuss] Re: SAMBA Problem (I Think) -- understanding SMB (it helps tremendously ;-)

[Bryan J. Smith]

On Tue, 2004-12-28 at 11:24, Terry Henderson wrote:
> I agree with Brian, NFS just seems so much easier and more stable to
> use.  You can use it in addition to samba and, well just makes more
> sense to use it.  Anyway, just my 2 cents.

Bliss is achieved by mounting/mapping with the _native_ protocol of the
_client_.  That's because the client is actually running programs on
that remotely mounted filesystem, so the server has to present all the
meta-interfaces and remote procedure calls (RPCs) the client expects.

If you do not, expect to have issues.  Samba does a decent job with its
"UNIX/Linux extensions" for SMB.  But for smbfs to native Windows
servers, I've never experienced bliss.  Microsoft offers Services for
UNIX (SFU) with NFS (that has lineage to Sun PC-NFS) for a reason. 
Samba is on UNIX/Linux for a reason.

If you still want something else, then look into Andrew Filesystem
(AFS).  AFS is a virtualized network filesystem -- i.e., there is no
local file access -- it _always_ comes through a service.  OpenAFS has
Freedomware clients for Windows, and Freedomware clients/servers for
UNIX, Linux, MacOS X, etc...  The server is 100% user-space like Samba.


On Tue, 2004-12-28 at 13:06, Scott Hollomon wrote: 
> I also agree with everyone about NFS vs SMB,

It isn't a matter of "NFS vs SMB" at all.  Each protocol was written for
different clients.  As such, the protocol caters to their more "native
client" platforms.  Outside of Linux, there is _no_ "smbfs" support in
the UNIX world.  That tells you how "native" it is to UNIX.  It's a series
of hacks to the Linux VFS.

> but I have to share it once with Samba for the windows machines on my
> home network and thought I would save a step and use the same shares
> and manage them all in one place.

I have been doing that on Solaris since 1995, and Linux since 1998 on
_production_ corporate networks.  And I'm not talking basic office
applications, I'm talking serious engineering networks where we were
using 1000Base-SX the second it came out because we needed the bandwidth.

It's fine as long as you _know_ what you are doing.  If you don't
accommodate various details, then you'll have issues.  But nothing an
experience network filesystem expert would not know.

> Although I must say that since the files in the shares are designed to be
> used by several people and not just the owner I usually run into permission 
> problems using NFS (although I appear to have had some with samba as well).

You must accompany network filesystem capability _with_ network authentication
and network directory information.  If anything, you'll want this for automounter
maps.  I.e., you define AFS/NFS/SMB shares in _one_ place for _all_ UNIX/Linux
clients.

Because _unlike_ Windows, you don't let your individual nodes "announce"
resources to the world.  You let your network administrator maintain them in a
_centralized_ and _controlled_ place -- like NIS/LDAP automounter maps.

There are dozens of ways to do this, from simple NIS w/optional Kerberos (either
NISGINA/pGINA on the Windows client, or SFU/Kerberos trust on the Windows server
side), LDAP w/Kerberos (ADS-based, OpenLDAP/Netscape LDAP w/AcctSync, etc...),
etc...

The latest NFS v4 in kernel 2.6 comes with a suite of accompaning GSSAPI/IDMap 
utilities/daemons.  So you don't have to setup a formal network authentication
system.  In fact, if you know what you are doing as a network administrator,
it really doesn't matter if you are ADS or LDAP -- or even NDS for that matter.

> Also while I know you can share directories with Samba and NFS at the same 
> time if the permissions are not identical will you not run into problems that 
> way?

I don't care what OS/server/protocol you have, if you don't do that, you _deserve_
what you get.  I don't care if you are just using Samba or NFS on their own, if you
have ownership/permission issues between Samba and NFS -- then you're going to have
them _period_ on their own.

If you unify your network authentication/directory, you don't have such an issue.

> How about Oplocks?  I've heard you should turn them off in samba if you 
> are going to also share the directory with NFS?

First off, you have just told me you don't understand Oplocks.  You _need_ to
understand how and why Oplocks work, and why Samba's per-share, various oplocks
settings are the #1 reason why Samba is preferred over native SMB servers.  I
expect a MCSA/MCSE to know about them, and I lambast them when they don't (most
do not, and they get an earful from me when they run into major data loss ;-).

Secondly, Oplocks are a hack so non-client/server programs can run faster.
I.e., SMB clients use local consistency checking, and in combination with oplocks,
allow peer-clients to share files.  Byte-level locking is also offered.  Just
FYI, NFS v4 _also_ supports byte-level locking, but NFS still _always_ uses
server-based locking (not client-based).  This is largely because UNIX world will
_never_ offer an equivalent for Access-Jet and for sound reasons.

Third, if you _know_ what you are doing, oplocks are very _easily_ handled on
dual-shared NFS and SMB -- or even just when doing _local_ access at the same
time as SMB (i.e., it is _not_ a NFS issue).  UNIX has a standard lockd interface,
one that the overwhelming majority of kernel NFS implementations honor.  Irix,
Linux 2.4 and other UNIX flavors have kernel oplock support for SMB, so Samba 2+
supports safe oplocks with standard UNIX/Linux kernel lockd support -- including
for both local and NFS access.

And even when there is not kernel Oplocks support, there are options you can use
to mitigate any risk.

By far Windows clients are going to be more of a danger to each other
with oplocks than local UNIX or NFS access.  In fact, you _should_ know when to
enable oplocks, when not to, and when to _segment_ shares to avoid those issues.
This is only an option with Samba, because native SMB servers don't officially
support disabling oplocks (and allow it _server_-wide with a registry hack).

Although it is aged (written December 1999), Appendix A "Samba on
Solaris [and SunOS 4]" in the book "Samba Unleashed" covers many
standard Samba 2+ options for dual-shared NFS/Samba: 
  http://www.amazon.com/exec/obidos/tg/detail/-/0672318628/  

Please read up on Oplocks and how they are easily accommodated alongside
UNIX/Linux lockd for local access (which also applies to NFS lockd).

  

-- 
Bryan J. Smith                                    b.j.smith at 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.