summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorSamba Release Account <samba-bugs@samba.org>1996-05-04 07:50:46 +0000
committerSamba Release Account <samba-bugs@samba.org>1996-05-04 07:50:46 +0000
commit0db2ec0e94c6849202a2aa6e9965bfef0acb4e7a (patch)
treea07fdef481e206a89917895bd3dbe2eda0f25ee3 /docs
parentce9f59147274357ef0ab7ae968564fb804430cdc (diff)
parent0e8fd3398771da2f016d72830179507f3edda51b (diff)
downloadsamba-0db2ec0e94c6849202a2aa6e9965bfef0acb4e7a.tar.gz
samba-0db2ec0e94c6849202a2aa6e9965bfef0acb4e7a.tar.bz2
samba-0db2ec0e94c6849202a2aa6e9965bfef0acb4e7a.zip
This commit was generated by cvs2svn to compensate for changes in r4,
which included commits to RCS files with non-trunk default branches. (This used to be commit c8a46aca039f16b00bcd177ac2bb9962fdfff529)
Diffstat (limited to 'docs')
-rw-r--r--docs/THANKS119
-rw-r--r--docs/announce129
-rw-r--r--docs/history165
-rw-r--r--docs/htmldocs/wfw_slip.htm175
-rw-r--r--docs/manpages/nmbd.8491
-rw-r--r--docs/manpages/samba.7190
-rw-r--r--docs/manpages/smb.conf.52719
-rw-r--r--docs/manpages/smbclient.11133
-rw-r--r--docs/manpages/smbd.8407
-rw-r--r--docs/manpages/smbrun.170
-rw-r--r--docs/manpages/smbstatus.152
-rw-r--r--docs/manpages/smbtar.1167
-rw-r--r--docs/manpages/testparm.1104
-rw-r--r--docs/manpages/testprns.1107
-rw-r--r--docs/samba.lsm26
-rw-r--r--docs/textdocs/BROWSING.txt145
-rw-r--r--docs/textdocs/BUGS.txt123
-rw-r--r--docs/textdocs/DIAGNOSIS.txt237
-rw-r--r--docs/textdocs/DNIX.txt69
-rw-r--r--docs/textdocs/DOMAIN.txt68
-rw-r--r--docs/textdocs/ENCRYPTION.txt333
-rw-r--r--docs/textdocs/HINTS.txt202
-rw-r--r--docs/textdocs/INSTALL.sambatar27
-rw-r--r--docs/textdocs/PROJECTS96
-rw-r--r--docs/textdocs/Passwords.txt42
-rw-r--r--docs/textdocs/README.DCEDFS79
-rw-r--r--docs/textdocs/README.jis124
-rw-r--r--docs/textdocs/README.sambatar15
-rw-r--r--docs/textdocs/SCO.txt12
-rw-r--r--docs/textdocs/SMBTAR.notes40
-rw-r--r--docs/textdocs/Speed.txt272
-rw-r--r--docs/textdocs/Support.txt376
-rw-r--r--docs/textdocs/UNIX-SMB.txt220
-rw-r--r--docs/textdocs/WinNT.txt56
34 files changed, 8590 insertions, 0 deletions
diff --git a/docs/THANKS b/docs/THANKS
new file mode 100644
index 0000000000..6405da3f9f
--- /dev/null
+++ b/docs/THANKS
@@ -0,0 +1,119 @@
+=====================================================================
+This file is for thanks to individuals or organisations who have
+helped with the development of Samba, other than by coding or bug
+reports. Their contributions are gratefully acknowledged.
+
+Please refer to the manual pages and change-log for a list of those
+who have contributed in the form of patches, bug fixes or other
+direct changes to the package.
+
+Contributions of any kind are welcomed. If you want to help then
+please contact Andrew.Tridgell@anu.edu.au, or via normal mail at
+
+ Andrew Tridgell
+ 3 Ballow Crescent
+ Macgregor, A.C.T
+ 2615 Australia
+=====================================================================
+
+
+Lee Fisher (leefi@microsoft.com)
+Charles Fox (cfox@microsoft.com)
+Dan Perry (danp@exchnge.microsoft.com)
+
+ These Microsoft people have been very helpful and supportive of
+ the development of Samba.
+
+ Lee very kindly supplied me with a copy of the X/Open SMB
+ specs. These have been invaluable in getting the details of the
+ implementation right. They will become even more important as we move
+ towards a Lanman 2.1 compliant server. Lee has provided very
+ useful advice on several aspects of the server.
+ Lee has also provided me with copies of Windows NTAS 3.1, Visual C
+ and a developers CD-ROM. Being able to run NT at home is a
+ great help.
+
+ Charles has helped out in numerous ways with the provision of SMB
+ specifications and helpful advice. He has been following the
+ discussion of Samba on the mailing list and has stepped in
+ regularly to clarify points and to offer help.
+
+ Dan has put me in touch with NT developers to help sort out bugs and
+ compatability issues. He has also supplied me with a copy of the
+ NT browsing spec, which will help a lot in the development of the
+ Samba browser code.
+
+
+Bruce Perens (bruce@pixar.com)
+
+ In appreciation of his effort on Samba we have sent Andrew copies of
+ various Pixar computer-graphics software products. Pixar is best known
+ for its "Renderman" product, the 3-D renderer used by ILM to make special
+ effects for "Terminator II" and "Jurassic Park". We won the first Oscar
+ given to a computer graphic animated feature for our short film "Tin Toy".
+ Our retail products "Typestry" and "Showplace", incorporate the same
+ renderer used on the films, and are available on Windows and the
+ Macintosh.
+
+
+
+Henry Lee (hyl@microplex.co)
+
+ Henry sent me a M202 ethernet print server, making my little lan
+ one of the few home networks to have it's own print server!
+
+ ``Microplex Systems Ltd. is a manufacturer of local and wide area
+ network communications equipment based in beautiful Vancouver, British
+ Columbia, Canada. Microplex's first products were synchronous wide
+ area network devices used in the mainframe communication networks. In
+ August 1991 Microplex introduced its first LAN product, the M200 print
+ server, the first high performance print server under US$1,000.''
+
+
+Tom Haapanen (tomh@metrics.com)
+
+ Tom sent me two 16 bit SMC ethernet cards to replace my ancient 8
+ bit ones. The performance is much better!
+
+ Software Metrics Inc. is a small custom software development and
+ consulting firm located in Waterloo, Ontario, Canada. We work
+ with a variety of environments (such as Windows, Windows NT and
+ Unix), tools and application areas, and can provide assistance for
+ development work ranging from a few days to to multiple man-year
+ projects. You can find more information at http://www.metrics.com/.
+
+
+Steve Kennedy (steve@gbnet.net)
+
+ Steve sent me 16Mb of ram so that I could install/test
+ NT3.5. I previous had only 8Mb ram in my test machine, which
+ wasn't enough to install a properly functioning copy of
+ NTAS. Being able to directly test NT3.5 allowed me to solve
+ several long standing NT<->Samba problems. Thanks Steve!
+
+John Terpstra (jht@aquasoft.com.au)
+
+ Aquasoft are a speciaist consulting company whose Samba using
+ customers span the world.
+
+ Aquasoft have been avid supporters of the Samba project. As a
+ token of appreciation Aquasoft have donated a 486DX2/66 PC with
+ a 540MB EIDE drive and 20MB RAM.
+
+ John has helped to isolate quite a few little glitches over time
+ and has managed to implement some very interesting installations
+ of Samba.
+
+ The donation of the new PC will make it possible to more fully
+ diagnose and observe the behaviour of Samba in conjuction with
+ other SMB protocol utilising systems.
+
+
+Timothy F. Sipples (tsipple@vnet.IBM.COM)
+Steve Withers (swithers@vnet.IBM.COM)
+
+ Tim and Steve from IBM organised a copy of the OS/2 developers
+ connection CD set for me, and gave lots of help in getting
+ OS/2 Warp installed. I hope this will allow me to finally fix
+ up those annoying OS/2 related Samba bugs that I have been
+ receiving reports of.
diff --git a/docs/announce b/docs/announce
new file mode 100644
index 0000000000..f761320f43
--- /dev/null
+++ b/docs/announce
@@ -0,0 +1,129 @@
+ Announcing Samba version 1.9
+ ============================
+
+What is Samba?
+--------------
+
+Samba is a Unix based SMB file server. This allows a Unix host to
+act as a file and print server for SMB clients. This includes
+Lan-Manager compatible clients such as LanManager for DOS, Windows for
+Workgroups, Windows NT, Windows 95, OS/2, Pathworks and many more.
+
+The package also includes a Unix SMB client and a netbios nameserver.
+
+What can it do for me?
+----------------------
+
+If you have any PCs running SMB clients, such as a PC running Windows
+for Workgroups, then you can mount file space or printers from a unix
+host, so that directories, files and printers on the unix host are
+available on the PC.
+
+The client part of the package will also allow you to attach to other
+SMB-based servers (such as windows NT and windows for workgroups) so
+that you can copy files to and from your unix host. The client also
+allows you to access a SMB printer (such as one attached to an OS/2 or
+WfWg server) from Unix, using an entry in /etc/printcap, or by
+explicitly specifying the command used to print files.
+
+What are it's features?
+------------------------
+
+Samba supports many features that are not supported in other SMB
+implementations (all of which are commercial). Some of it's features
+include host as well as username/password security, a unix client,
+automatic home directory exporting, automatic printer exporting, dead
+connection timeouts, umask support, guest connections, name mangling
+and hidden and system attribute mapping. Look at the man pages
+included with the package for a full list of features.
+
+What's new since 1.8?
+---------------------
+
+Lots of stuff. See the change log and man pages for details.
+
+Where can I get a client for my PC?
+-----------------------------------
+
+There is a free client for MS-DOS based PCs available from
+ftp.microsoft.com in the directory bussys/Clients/MSCLIENT/. Please
+read the licencing information before downloading. The built in
+Windows for Workgroups client is also very good.
+
+What network protocols are supported?
+-------------------------------------
+
+Currently only TCP/IP is supported. There has been some discussion
+about ports to other protocols but nothing is yet available.
+
+There is a free TCP/IP implementation for Windows for Workgroups
+available from ftp.microsoft.com (it's small, fast and quite reliable).
+
+How much does it cost?
+----------------------
+
+Samba software is free software. It is available under the
+GNU Public licence in source code form at no cost. Please read the
+file COPYING that comes with the package for more information.
+
+What flavours of unix does it support?
+---------------------------------------
+
+The code has been written to be as portable as possible. It has been
+"ported" to many unixes, which mostly required changing only a few
+lines of code. It has been run (to my knowledge) on at least these
+unixes:
+
+Linux, SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD,
+Sequent, HP-UX, SGI, FreeBSD, NeXT, ISC, A/UX, SCO, Intergraph,
+Domain/OS and DGUX.
+
+Some of these have received more testing than others. If it doesn't
+work with your unix then it should be easy to fix.
+
+Who wrote it?
+-------------
+
+Many people on the internet have contributed to the development of
+Samba. The maintainer and original author is Andrew Tridgell, but
+large parts of the package were contributed by several people from all
+over the world. Please look at the file `change-log' for information
+on who did what bits.
+
+Where can I get it?
+-------------------
+
+The package is available via anonymous ftp from nimbus.anu.edu.au in
+the directory pub/tridge/samba/.
+
+What about SMBServer?
+---------------------
+
+Samba used to be known as SMBServer, until it was pointed out that
+Syntax, who make a commercial Unix SMB based server, have trademarked
+that name. The name was then changed to Samba. Also, in 1992 a very
+early incarnation of Samba was distributed as nbserver.
+
+If you see any copies of nbserver or smbserver on ftp sites please let
+me or the ftp archive maintainer know, as I want to get them deleted.
+
+Where can I get more info?
+---------------------------
+
+Please join the mailing list if you want to discuss the development or
+use of Samba. To join the mailing list send mail to
+listproc@listproc.anu.edu.au with a body of "subscribe samba Your
+Name".
+
+There is also an announcement mailing list for new version
+announcements. Subscribe as above but with "subscribe samba-announce
+Your Name".
+
+There is also often quite a bit of discussion about Samba on the
+newsgroup comp.protocols.smb.
+
+A WWW site with lots of Samba info can be found at
+http://lake.canberra.edu.au/pub/samba/
+
+Andrew Tridgell (Contact: samba-bugs@anu.edu.au)
+January 1995
diff --git a/docs/history b/docs/history
new file mode 100644
index 0000000000..83761e23b8
--- /dev/null
+++ b/docs/history
@@ -0,0 +1,165 @@
+Note: This file is now quite out of date - but perhaps that's
+appropriate?
+
+
+=========
+
+This is a short history of this project. It's not supposed to be
+comprehensive, just enough so that new users can get a feel for where
+this project has come from and maybe where it's going to.
+
+The whole thing really started in December 1991. I was (and still am)
+a PhD student in the Computer Sciences Laboratory at the Australian
+Netional University, in Canberra, Australia. We had just got a
+beta copy of eXcursion from Digital, and I was testing it on my PC. At
+this stage I was a MS-DOS user, dabbling in windows.
+
+eXcursion ran (at the time) only with Dec's `Pathworks' network for
+DOS. I had up till then been using PC-NFS to connect to our local sun
+workstations, and was reasonably happy with it. In order to run
+pathworks I had to stop using PC-NFS and try using pathworks to mount
+disk space. Unfortunately pathworks was only available for digital
+workstations running VMS or Ultrix so I couldn't mount from the suns
+anymore.
+
+I had access to a a decstation 3100 running Ultrix that I used to
+administer, and I got the crazy notion that the protocol that
+pathworks used to talk to ultrix couldn't be that hard, and maybe I
+could work it out. I had never written a network program before, and
+certainly didn't know what a socket was.
+
+In a few days, after looking at some example code for sockets, I
+discovered it was pretty easy to write a program to "spy" on the file
+sharing protocol. I wrote and installed this program (the sockspy.c
+program supplied with this package) and captured everything that the
+pathworks client said to the pathworks server.
+
+I then tried writing short C programs (using Turbo C under DOS) to do
+simple file operations on the network drive (open, read, cd etc) and
+looked at the packets that the server and client exchanged. From this
+I worked out what some of the bytes in the packets meant, and started
+to write my own program to do the same thing on a sun.
+
+After a day or so more I had my first successes and actually managed
+to get a connection and to read a file. From there it was all
+downhill, and a week later I was happily (if a little unreliably)
+mounting disk space from a sun to my PC running pathworks. The server
+code had a lot of `magic' values in it, which seemed to be always
+present with the ultrix server. It was not till 2 years later that I
+found out what all these values meant.
+
+Anyway, I thought other people might be interested in what I had done,
+so I asked a few people at uni, and noone seemed much interested. I
+also spoke to a person at Digital in Canberra (the person who had
+organised a beta test of eXcursion) and asked if I could distribute
+what I'd done, or was it illegal. It was then that I first heard the
+word "netbios" when he told me that he thought it was all covered by a
+spec of some sort (the netbios spec) and thus what I'd done was not
+only legal, but silly.
+
+I found the netbios spec after asking around a bit (the RFC1001 and
+RFC1002 specs) and found they looked nothing like what I'd written, so
+I thought maybe the Digital person was mistaken. I didn't realise RFCs
+referred to the name negotiation and packet encapsulation over TCP/IP,
+and what I'd written was really a SMB implementation.
+
+Anyway, he encouraged me to release it so I put out "Server 0.1" in
+January 1992. I got quite a good response from people wanting to use
+pathworks with non-digital unix workstations, and I soon fixed a few
+bugs, and released "Server 0.5" closely followed by "Server 1.0". All
+three releases came out within about a month of each other.
+
+At this point I got an X Terminal on my desk, and I no longer needed eXcursion
+and I prompty forgot about the whole project, apart from a few people
+who e-mailed me occasionally about it.
+
+Nearly two years then passed with just occasional e-mails asking about
+new versions and bugs. I even added a note to the ftp site asking for
+a volunteer to take over the code as I no longer used it. No one
+volunteered.
+
+During this time I did hear from a couple of people who said it should
+be possible to use my code with Lanmanager, but I never got any
+definite confirmation.
+
+One e-mail I got about the code did, however, make an impression. It
+was from Dan Shearer at the university of South Australia, and he said
+this:
+
+
+ I heard a hint about a free Pathworks server for Unix in the
+ Net channel of the Linux list. After quite a bit of chasing
+ (and lots of interested followups from other Linux people) I
+ got hold of a release news article from you, posted in Jan 92,
+ from someone in the UK.
+
+ Can you tell me what the latest status is? I think you might
+ suddenly find a whole lot of interested hackers in the Linux
+ world at least, which is a place where things tend to happen
+ fast (and even some reliable code gets written, BION!)
+
+I asked him what Linux was, and he told me it was a free Unix for PCs.
+This was in November 1992 and a few months later I was a Linux
+convert! I still didn't need a pathworks server though, so I didn't do
+the port, but I think Dan did.
+
+At about this time I got an e-mail from Digital, from a person working
+on the Alpha software distribution. He asked if I would mind if they
+included my server with the "contributed" cd-rom. This was a bit of a
+shock to me as I never expected Dec to ask me if they could use my
+code! I wrote back saying it was OK, but never heard from him again. I
+don't know if it went on the cd-rom.
+
+Anyway, the next big event was in December 1993, when Dan again sent
+me an e-mail saying my server had "raised it's ugly head" on
+comp.protocols.tcpip.ibmpc. I had a quick look on the group, and was
+surprised to see that there were people interested in this thing.
+
+At this time a person from our computer center offered me a couple of
+cheap ethernet cards (3c505s for $15 each) and coincidentially someone
+announced on one of the Linux channels that he had written a 3c505
+driver for Linux. I bought the cards, hacked the driver a little and
+setup a home network between my wifes PC and my Linux box. I then
+needed some way to connect the two, and I didn't own PC-NFS at home,
+so I thought maybe my server could be useful. On the newsgroup among
+the discussions of my server someone had mentioned that there was a
+free client that might work with my server that Microsoft had put up
+for ftp. I downloaded it and found to my surprise that it worked first
+time with my `pathworks' server!
+
+Well, I then did a bit of hacking, asked around a bit and found (I
+think from Dan) that the spec I needed was for the "SMB" protocol, and
+that it was available via ftp. I grabbed it and started removing all
+those ugly constants from the code, now that all was explained.
+
+On December 1st 1993 I announced the start of the "Netbios for Unix"
+project, seeding the mailing list with all the people who had e-mailed
+me over the years asking about the server.
+
+About 35 versions (and two months) later I wrote a short history of
+the project, which you have just read. There are now over a hundred
+people on the mailing list, and lots of people report that they use
+the code and like it. In a few days I will be announcing the release
+of version 1.6 to some of the more popular (and relevant) newsgroups.
+
+
+Andrew Tridgell
+6th February 1994
+
+---------------------
+
+It is now May 1995 and there are about 1400 people on the mailing
+list. I got downloads from the main Samba ftp site from around 5000
+unique hosts in a two month period. There are several mirror
+sites as well. The current version number is 1.9.13.
+
+---------------------
+
+
+---------------------
+It's now March 1996 and version 1.9.16alpha1 has just been
+released. There have been lots of changes recently with master browser
+support and the ability to do domain logons etc. Samba has also been
+ported to OS/2, the amiga and NetWare. There are now 3000 people on
+the samba mailing list.
+---------------------
diff --git a/docs/htmldocs/wfw_slip.htm b/docs/htmldocs/wfw_slip.htm
new file mode 100644
index 0000000000..5b4a0a5e53
--- /dev/null
+++ b/docs/htmldocs/wfw_slip.htm
@@ -0,0 +1,175 @@
+<HTML>
+<HEAD>
+<TITLE>Peter Karrer Announces SLIP for WFW</TITLE>
+</HEAD>
+<BODY>
+<H1><I>Winserve</I></H1>
+<HR>
+<H2><I>Peter Karrer Announces SLIP for WFW</I></H2>
+[NEW 03-22-95)
+<HR>
+<B>Hello,</B>
+<P>
+I've discovered a way to run WfW's TCP/IP-32 over a SLIP packet driver. This
+allows WfW users to do Windows networking over dialup lines just like it is
+possible with NT and the Windows 95 beta!
+<P>
+For instance, you can mount Microsoft's FTP server as a network drive in File
+Manager or connect to an MS Mail post office over the Internet. Of course,
+the usual Internet stuff works as well. Another interesting site is
+WINSERVE.001; check out www.winserve.com.
+<HR>
+This method should work with any class 1 (Ethernet II) packet driver. However,
+I'm not in a position to try anything else than SLIPPER/CSLIPPER.
+<HR>
+<H3>Files you need:</H3>
+<B>WFWT32.EXE:</B> ftp://ftp.microsoft.com/bussys/msclient/wfw/wfwt32.exe
+<P>
+ Microsoft's free TCP/IP for WfW. It's a self-extracting archive which
+ should be executed in an empty directory.
+<P>
+<B>SLIPPER.EXE:</B> ftp://biocserver.bioc.cwru.edu/pub/dos/slipper/slippr15.zip
+<P>
+ Peter Tattam's SLIP packet driver. CSLIPPER.EXE is a variant which supports
+ VJ header compression.
+<P>
+<B>PDETHER.EXE:</B> ftp://sjf-lwp.idz.sjf.novell.com/odi/pdether/pde105.zip
+<P>
+ Don Provan's ODI-over-Packet Driver shim. This *must* be version 1.05 (or
+ above).
+<P>
+<B>LSL.COM:</B>
+<P>
+ Novell's LAN Support Layer. If you're an owner of Windows 3.10, you'll
+ have it on one of your install disks. Use "expand a:lsl.co_ lsl.com" to
+ expand it. Microsoft has stopped bundling LSL.COM with WfW 3.11, though.
+ The newest version of LSL.COM can be downloaded as part of
+ ftp://ftp.novell.com/pub/netware/nwos/dosclnt12/vlms/vlmup2.exe.
+ However, it's not clear if this one may be legally used outside Netware
+ environments.
+<P>
+<B>NET.CFG:</B>
+<P>
+ A configuration file for LSL and PDETHER. It should contain the following
+ text:
+<P>
+<PRE>
+Link Support
+ Buffers 8 1600
+Link Driver PDETHER
+ Int 60
+ Frame Ethernet_II
+ Protocol IP 800 Ethernet_II
+ Protocol ARP 806 Ethernet_II
+ Protocol RARP 8035 Ethernet_II
+</PRE>
+<P>
+<B>DISCOMX.COM:</B>
+<P>
+ A little hack of mine to disable the COM port used by the SLIP packet driver.
+ Usage is e.g. "discomx 2" to disable COM2. This should be run before
+ starting WfW, otherwise you'll get "device conflict" messages. Here it is:
+<P><PRE>
+begin 644 discomx.com
+F,=N)V8H.@`"P(+^!`/.N3XH="=MT!DN`XP/1XS')!R:)CP`$S2``
+`
+end
+ </PRE>
+ (Save this text to disk as <I>filename</I>, then run "uudecode <I>filename</I>".
+ uudecode can be found, for instance, at
+ ftp://ftp.switch.ch/mirror/simtel/msdos/starter/uudecode.com )
+<P>
+<B>LMHOSTS:</B>
+ <P>
+ An optional file which should be stored in your Windows subdirectory. It is
+ used to map NetBIOS computer names to IP addresses. Example:
+<P>
+<PRE>
+198.105.232.1 ftp #PRE # ftp.microsoft.com
+204.118.34.11 winserve.001 #PRE # Winserve
+</PRE>
+<HR>
+<H3>How to install it:</H3>
+<P>
+<UL>
+<LI>Put the files mentioned above into a directory, e.g. C:\SLIP.
+<P>
+<LI>Put the following lines into AUTOEXEC.BAT:
+<P><PRE>
+ cd \slip
+ slipper com1 vec=60 baud=57600 ether (may vary with your modem setup)
+ lsl
+ pdether
+ discomx 1 (must correspond to SLIPPER's COM port)
+</PRE>
+ (If you use another vec= setting, you must update that in NET.CFG as well.)
+ Use CSLIPPER instead of SLIPPER if your SLIP provider supports VJC.
+<P>
+<LI>Start WfW.
+<UL>
+<LI>Under Windows Setup, choose "Change Network Settings".
+<LI>Select "Install Microsoft Windows Network".
+<LI>In "Drivers...", choose "Add Adapter"
+ and install the "IPXODI Support driver (Ethernet) [ODI/NDIS3]".
+<LI>In "Add Protocols...", select "Unlisted or Updated Protocol". When asked for a
+ driver disk, enter the directory where you expanded WFWT32.EXE.
+<LI>Configure TCP/IP (IP address, enable LMHOSTS lookup, try 204.118.34.11 as primary
+ WINS server). Remove all other protocols (NetBEUI, IPX/SPX).
+</UL>
+<P>
+<LI>Windows will probably update the first lines of AUTOEXEC.BAT with
+<P>
+<PRE>
+ c:\windows\net start
+ c:\windows\odihlp.exe.
+</PRE>
+ The "odihlp" line must be moved behind the "pdether" line.
+<P>
+<LI>Windows will also update NET.CFG with some "Frame" lines. These must
+ be removed (except "Frame Ethernet_II").
+<P>
+<LI>Somehow, you will have to dial in to your SLIP provider. I do it manually
+ before slipper (or cslipper) gets loaded, using a DOS-based terminal program.
+ But there are some automatic dialers around. I've seen recommendations for
+ ftp://mvmpc9.ciw.uni-karlsruhe.de/x-slip/slip_it.exe.
+<P>
+<LI>To connect to Microsoft's FTP server (or Winserve) go into File Manager,
+ choose "Connect Network drive" and enter "\\ftp" or "\\winserve.001" into
+ the "Path:" field.
+</UL>
+<HR>
+<H3>How it works:</H3>
+<P>
+Microsoft's TCP/IP-32 requires an NDIS3 interface. NDIS is Microsoft's way
+to interface with a network.
+<P>
+WfW also contains an NDIS3-over-ODI "shim", whose real mode component is
+ODIHLP.EXE. ODI is Novell's way to interface with a network.
+<P>
+SLIPPER is a Packet Driver (PD) for use over serial lines. PDs are everybody
+else's way to interface with a network. SLIPPER's "ether" option makes it
+look like an Ethernet PD to applications using it.
+<P>
+A "shim" is a program which simulates a network application programming
+interface on top of another.
+<P>
+There is no NDIS SLIP driver which would work with WfW.
+<P>
+There is no NDIS-over-PD shim.
+<P>
+However, there's an ODI-over-PD shim (PDETHER) and an NDIS-over-ODI shim
+(ODIHLP etc.)
+<P>
+OK, so let's do NDIS-over-ODI-over-PD!
+ <P>
+This should have worked all the time; however, a non-feature in PDETHER
+versions < 1.05 has prevented the method from functioning until now.
+<HR>
+<B>Questions, suggestions etc. please to
+<P>
+<PRE>
+Peter Karrer pkarrer@ife.ee.ethz.ch
+</PRE>
+</B>
+</BODY>
+</HTML>
diff --git a/docs/manpages/nmbd.8 b/docs/manpages/nmbd.8
new file mode 100644
index 0000000000..e42f194cde
--- /dev/null
+++ b/docs/manpages/nmbd.8
@@ -0,0 +1,491 @@
+.TH NMBD 8 17/1/1995 nmbd nmbd
+.SH NAME
+nmbd \- provide netbios nameserver support to clients
+.SH SYNOPSIS
+.B nmbd
+[
+.B -B
+.I broadcast address
+] [
+.B -I
+.I IP address
+] [
+.B -D
+] [
+.B -C comment string
+] [
+.B -G
+.I group name
+] [
+.B -H
+.I netbios hosts file
+] [
+.B -N
+.I netmask
+] [
+.B -d
+.I debuglevel
+] [
+.B -l
+.I log basename
+] [
+.B -n
+.I netbios name
+] [
+.B -p
+.I port number
+] [
+.B -s
+.I config file name
+]
+
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B nmbd
+is a server that understands and can reply to netbios
+name service requests, like those produced by LanManager
+clients. It also controls browsing.
+
+LanManager clients, when they start up, may wish to locate a LanManager server.
+That is, they wish to know what IP number a specified host is using.
+
+This program simply listens for such requests, and if its own name is specified
+it will respond with the IP number of the host it is running on. "Its own name"
+is by default the name of the host it is running on, but this can be overriden
+with the
+.B -n
+option (see "OPTIONS" below). Using the
+.B -S
+option (see "OPTIONS" below), it can also be instructed to respond with IP
+information about other hosts, provided they are locatable via the
+gethostbyname() call, or they are in a netbios hosts file.
+
+Nmbd can also be used as a WINS (Windows Internet Name Server)
+server. It will do this automatically by default. What this basically
+means is that it will respond to all name requests that it receives
+that are not broadcasts, as long as it can resolve the name.
+.SH OPTIONS
+.B -B
+
+.RS 3
+On some systems, the server is unable to determine the broadcast address to
+use for name registration requests. If your system has this difficulty, this
+parameter may be used to specify an appropriate broadcast address. The
+address should be given in standard "a.b.c.d" notation.
+
+Only use this parameter if you are sure that the server cannot properly
+determine the proper broadcast address.
+
+The default broadcast address is determined by the server at run time. If it
+encounters difficulty doing so, it makes a guess based on the local IP
+number.
+.RE
+.B -I
+
+.RS 3
+On some systems, the server is unable to determine the correct IP
+address to use. This allows you to override the default choice.
+.RE
+
+.B -D
+
+.RS 3
+If specified, this parameter causes the server to operate as a daemon. That is,
+it detaches itself and runs in the background, fielding requests on the
+appropriate port.
+
+By default, the server will NOT operate as a daemon.
+.RE
+
+.B -C comment string
+
+.RS 3
+This allows you to set the "comment string" that is shown next to the
+machine name in browse listings.
+
+A %v will be replaced with the Samba version number.
+
+A %h will be replaced with the hostname.
+
+It defaults to "Samba %v".
+.RE
+
+.B -G
+
+.RS 3
+This option allows you to specify a netbios group (also known as
+lanmanager domain) that the server should be part of. You may include
+several of these on the command line if you like. Alternatively you
+can use the -H option to load a netbios hosts file containing domain names.
+
+At startup, unless the -R switch has been used, the server will
+attempt to register all group names in the hosts file and on the
+command line (from the -G option).
+
+The server will also respond to queries on this name.
+.RE
+
+.B -H
+
+.RS 3
+It may be useful in some situations to be able to specify a list of
+netbios names for which the server should send a reply if
+queried. This option allows that. The syntax is similar to the
+standard /etc/hosts file format, but has some extensions.
+
+The file contains three columns. Lines beginning with a # are ignored
+as comments. The first column is an IP address, or a hostname. If it
+is a hostname then it is interpreted as the IP address returned by
+gethostbyname() when read. Any IP address of 0.0.0.0 will be
+interpreted as the servers own IP address.
+
+The second column is a netbios name. This is the name that the server
+will respond to. It must be less than 20 characters long.
+
+The third column is optional, and is intended for flags. Currently the
+only flags supported are G, S and M. A G indicates that the name is a
+group (also known as domain) name.
+
+At startup all groups known to the server (either from this file or
+from the -G option) are registered on the network (unless the -R
+option has been selected).
+
+A S or G means that the specified address is a broadcast address of a
+network that you want people to be able to browse you from. Nmbd will
+search for a master browser in that domain and will send host
+announcements to that machine, informing it that the specifed somain
+is available.
+
+A M means that this name is the default netbios name for this
+machine. This has the same affect as specifying the -n option to nmbd.
+
+After startup the server waits for queries, and will answer queries to
+any name known to it. This includes all names in the netbios hosts
+file (if any), it's own name, and any names given with the -G option.
+
+The primary intention of the -H option is to allow a mapping from
+netbios names to internet domain names, and to allow the specification
+of groups that the server should be part of.
+
+.B Example:
+
+ # This is a sample netbios hosts file
+
+ # DO NOT USE THIS FILE AS-IS
+ # YOU MAY INCONVENIENCE THE OWNERS OF THESE IPs
+ # if you want to include a name with a space in it then
+ # use double quotes.
+
+ # first put ourselves in the group LANGROUP
+ 0.0.0.0 LANGROUP G
+
+ # next add a netbios alias for a faraway host
+ arvidsjaur.anu.edu.au ARVIDSJAUR
+
+ # finally put in an IP for a hard to find host
+ 130.45.3.213 FREDDY
+
+ # now we want another subnet to be able to browse
+ # us in the workgroup UNIXSERV
+ 192.0.2.255 UNIXSERV G
+
+.RE
+
+.B -M
+.I workgroup name
+
+.RS 3
+If this parameter is given, the server will look for a master browser
+for the specified workgroup name, report success or failure, then
+exit. If successful, the IP address of the name located will be
+reported.
+
+If you use the workgroup name "-" then nmbd will search for a master
+browser for any workgroup by using the name __MSBROWSE__.
+
+This option is meant to be used interactively on the command line, not
+as a daemon or in inetd.
+
+.RE
+.B -N
+
+.RS 3
+On some systems, the server is unable to determine the netmask. If
+your system has this difficulty, this parameter may be used to specify
+an appropriate netmask. The mask should be given in standard
+"a.b.c.d" notation.
+
+Only use this parameter if you are sure that the server cannot properly
+determine the proper netmask.
+
+The default netmask is determined by the server at run time. If it
+encounters difficulty doing so, it makes a guess based on the local IP
+number.
+.RE
+
+.B -d
+.I debuglevel
+.RS 3
+
+debuglevel is an integer from 0 to 5.
+
+The default value if this parameter is not specified is zero.
+
+The higher this value, the more detail will be logged to the log files about
+the activities of the server. At level 0, only critical errors and serious
+warnings will be logged. Level 1 is a reasonable level for day to day running
+- it generates a small amount of information about operations carried out.
+
+Levels above 1 will generate considerable amounts of log data, and should
+only be used when investigating a problem. Levels above 3 are designed for
+use only by developers and generate HUGE amounts of log data, most of which
+is extremely cryptic.
+.RE
+
+.B -l
+.I log file
+
+.RS 3
+If specified,
+.I logfile
+specifies a base filename into which operational data from the running server
+will be logged.
+
+The default base name is specified at compile time.
+
+The base name is used to generate actual log file names. For example, if the
+name specified was "log", the following files would be used for log data:
+
+.RS 3
+log.nmb (containing debugging information)
+
+log.nmb.in (containing inbound transaction data)
+
+log.nmb.out (containing outbound transaction data)
+.RE
+
+The log files generated are never removed by the server.
+.RE
+.RE
+
+.B -n
+.I netbios name
+
+.RS 3
+This parameter tells the server what netbios name to respond with when
+queried. The same name is also registered on startup unless the -R
+parameter was specified.
+
+The default netbios name used if this parameter is not specified is the
+name of the host on which the server is running.
+.RE
+
+.B -p
+.I port number
+.RS 3
+
+port number is a positive integer value.
+
+The default value if this parameter is not specified is 137.
+
+This number is the port number that will be used when making connections to
+the server from client software. The standard (well-known) port number for the
+server is 137, hence the default. If you wish to run the server as an ordinary
+user rather than as root, most systems will require you to use a port number
+greater than 1024 - ask your system administrator for help if you are in this
+situation.
+
+Note that the name server uses UDP, not TCP!
+
+This parameter is not normally specified except in the above situation.
+.RE
+.SH FILES
+
+.B /etc/inetd.conf
+
+.RS 3
+If the server is to be run by the inetd meta-daemon, this file must contain
+suitable startup information for the meta-daemon. See the section
+"INSTALLATION" below.
+.RE
+
+.B /etc/rc.d/rc.inet2
+
+.RS 3
+(or whatever initialisation script your system uses)
+
+If running the server as a daemon at startup, this file will need to contain
+an appropriate startup sequence for the server. See the section "Installation"
+below.
+.RE
+
+.B /etc/services
+
+.RS 3
+If running the server via the meta-daemon inetd, this file must contain a
+mapping of service name (eg., netbios-ns) to service port (eg., 137) and
+protocol type (eg., udp). See the section "INSTALLATION" below.
+.RE
+.RE
+
+.SH ENVIRONMENT VARIABLES
+Not applicable.
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the server software be installed under the /usr/local
+hierarchy, in a directory readable by all, writeable only by root. The server
+program itself should be executable by all, as users may wish to run the
+server themselves (in which case it will of course run with their privileges).
+The server should NOT be setuid or setgid!
+
+The server log files should be put in a directory readable and writable only
+by root, as the log files may contain sensitive information.
+
+The remaining notes will assume the following:
+
+.RS 3
+nmbd (the server program) installed in /usr/local/smb
+
+log files stored in /var/adm/smblogs
+.RE
+
+The server may be run either as a daemon by users or at startup, or it may
+be run from a meta-daemon such as inetd upon request. If run as a daemon, the
+server will always be ready, so starting sessions will be faster. If run from
+a meta-daemon some memory will be saved and utilities such as the tcpd
+TCP-wrapper may be used for extra security.
+
+When you've decided, continue with either "Running the server as a daemon" or
+"Running the server on request".
+.SH RUNNING THE SERVER AS A DAEMON
+To run the server as a daemon from the command line, simply put the "-D" option
+on the command line. There is no need to place an ampersand at the end of the
+command line - the "-D" option causes the server to detach itself from the
+tty anyway.
+
+Any user can run the server as a daemon (execute permissions permitting, of
+course). This is useful for testing purposes.
+
+To ensure that the server is run as a daemon whenever the machine is started,
+you will need to modify the system startup files. Wherever appropriate (for
+example, in /etc/rc.d/rc.inet2), insert the following line, substituting
+values appropriate to your system:
+
+.RS 3
+/usr/local/smb/nmbd -D -l/var/adm/smblogs/log
+.RE
+
+(The above should appear in your initialisation script as a single line.
+Depending on your terminal characteristics, it may not appear that way in
+this man page. If the above appears as more than one line, please treat any
+newlines or indentation as a single space or TAB character.)
+
+If the options used at compile time are appropriate for your system, all
+parameters except the desired debug level and "-D" may be omitted. See the
+section on "Options" above.
+.SH RUNNING THE SERVER ON REQUEST
+If your system uses a meta-daemon such as inetd, you can arrange to have the
+SMB name server started whenever a process attempts to connect to it. This
+requires several changes to the startup files on the host machine. If you are
+experimenting as an ordinary user rather than as root, you will need the
+assistance of your system administrator to modify the system files.
+
+First, ensure that a port is configured in the file /etc/services. The
+well-known port 137 should be used if possible, though any port may be used.
+
+Ensure that a line similar to the following is in /etc/services:
+
+.RS 3
+netbios-ns 137/udp
+.RE
+
+Note for NIS/YP users: You may need to rebuild the NIS service maps rather
+than alter your local /etc/services file.
+
+Next, put a suitable line in the file /etc/inetd.conf (in the unlikely event
+that you are using a meta-daemon other than inetd, you are on your own). Note
+that the first item in this line matches the service name in /etc/services.
+Substitute appropriate values for your system in this line (see
+.B inetd(8)):
+
+.RS 3
+netbios-ns dgram udp wait root /usr/local/smb/nmbd -l/var/adm/smblogs/log
+.RE
+
+(The above should appear in /etc/inetd.conf as a single line. Depending on
+your terminal characteristics, it may not appear that way in this man page.
+If the above appears as more than one line, please treat any newlines or
+indentation as a single space or TAB character.)
+
+Note that there is no need to specify a port number here, even if you are
+using a non-standard port number.
+.SH TESTING THE INSTALLATION
+If running the server as a daemon, execute it before proceeding. If
+using a meta-daemon, either restart the system or kill and restart the
+meta-daemon. Some versions of inetd will reread their configuration tables if
+they receive a HUP signal.
+
+To test whether the name server is running, start up a client
+.I on a different machine
+and see whether the desired name is now present. Alternatively, run
+the nameserver
+.I on a different machine
+specifying "-L netbiosname", where "netbiosname" is the name you have
+configured the test server to respond with. The command should respond
+with success, and the IP number of the machine using the specified netbios
+name. You may need the -B parameter on some systems. See the README
+file for more information on testing nmbd.
+
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the server has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B inetd(8),
+.B smbd(8),
+.B smb.conf(5),
+.B smbclient(1),
+.B testparm(1),
+.B testprns(1)
+
+.SH DIAGNOSTICS
+[This section under construction]
+
+Most diagnostics issued by the server are logged in the specified log file. The
+log file name is specified at compile time, but may be overridden on the
+command line.
+
+The number and nature of diagnostics available depends on the debug level used
+by the server. If you have problems, set the debug level to 3 and peruse the
+log files.
+
+Most messages are reasonably self-explanatory. Unfortunately, at time of
+creation of this man page the source code is still too fluid to warrant
+describing each and every diagnostic. At this stage your best bet is still
+to grep the source code and inspect the conditions that gave rise to the
+diagnostics you are seeing.
+
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+This man page written by Karl Auer (Karl.Auer@anu.edu.au)
+
+See
+.B smb.conf(5) for a full list of contributors and details on how to
+submit bug reports, comments etc.
+
+
+
+
+
diff --git a/docs/manpages/samba.7 b/docs/manpages/samba.7
new file mode 100644
index 0000000000..0c81f736b6
--- /dev/null
+++ b/docs/manpages/samba.7
@@ -0,0 +1,190 @@
+.TH SAMBA 7 29/3/95 Samba Samba
+.SH NAME
+Samba \- a LanManager like fileserver for Unix
+.SH SYNOPSIS
+.B Samba
+.SH DESCRIPTION
+The
+.B Samba
+software suite is a collection of programs that implements the SMB
+protocol for unix systems. This protocol is sometimes also referred to
+as the LanManager or Netbios protocol.
+
+.SH COMPONENTS
+
+The Samba suite is made up of several components. Each component is
+described in a separate manual page. It is strongly recommended that
+you read the documentation that comes with Samba and the manual pages
+of those components that you use. If the manual pages aren't clear
+enough then please send me a patch!
+
+The smbd(8) daemon provides the file and print services to SMB clents,
+such as Windows for Workgroups, Windows NT or LanManager. The
+configuration file for this daemon is described in smb.conf(5).
+
+The nmbd(8) daemon provides Netbios nameserving and browsing
+support. It can also be run interactively to query other name service
+daemons.
+
+The smbclient(1) program implements a simple ftp-like client. This is
+useful for accessing SMB shares on other compatible servers (such as
+WfWg), and can also be used to allow a unix box to print to a printer
+attached to any SMB server (such as a PC running WfWg).
+
+The testparm(1) utility allows you to test your smb.conf(5)
+configuration file.
+
+The smbstatus(1) utility allows you to tell who is currently using the
+smbd(8) server.
+
+.SH AVAILABILITY
+
+The Samba software suite is licensed under the Gnu Public License. A
+copy of that license should have come with the package. You are
+encouraged to distribute copies of the Samba suite, but please keep it
+intact.
+
+The latest version of the Samba suite can be obtained via anonymous
+ftp from nimbus.anu.edu.au in the directory pub/tridge/samba/. It is
+also available on several mirror sites worldwide.
+
+You may also find useful information about Samba on the newsgroup
+comp.protocols.smb and the Samba mailing list. Details on how to join
+the mailing list are given in the README file that comes with Samba.
+
+If you have access to a WWW viewer (such as Netscape or Mosaic) then
+you will also find lots of useful information, including back issues
+of the Samba mailing list, at http://lake.canberra.edu.au/pub/samba/
+
+.SH AUTHOR
+
+The main author of the Samba suite is Andrew Tridgell. He may be
+contacted via e-mail at samba-bugs@anu.edu.au.
+
+There have also been an enourmous number of contributors to Samba from
+all over the world. A partial list of these contributors is included
+in the CREDITS section below. The list is, however, badly out of
+date. More up to date info may be obtained from the change-log that
+comes with the Samba source code.
+
+.SH CONTRIBUTIONS
+
+If you wish to contribute to the Samba project, then I suggest you
+join the Samba mailing list.
+
+If you have patches to submit or bugs to report then you may mail them
+directly to samba-bugs@anu.edu.au. Note, however, that due to the
+enourmous popularity of this package I may take some time to repond to
+mail. I prefer patches in "diff -u" format.
+
+.SH CREDITS
+
+Contributors to the project are (in alphabetical order by email address):
+
+(NOTE: This list is very out of date)
+
+ Adams, Graham
+ (gadams@ddrive.demon.co.uk)
+ Allison, Jeremy
+ (jeremy@netcom.com)
+ Andrus, Ross
+ (ross@augie.insci.com)
+ Auer, Karl
+ (Karl.Auer@anu.edu.au)
+ Bogstad, Bill
+ (bogstad@cs.jhu.edu)
+ Boreham, Bryan
+ (Bryan@alex.com)
+ Boreham, David
+ (davidb@ndl.co.uk)
+ Butler, Michael
+ (imb@asstdc.scgt.oz.au)
+ ???
+ (charlie@edina.demon.co.uk)
+ Chua, Michael
+ (lpc@solomon.technet.sg)
+ Cochran, Marc
+ (mcochran@wellfleet.com)
+ Dey, Martin N
+ (mnd@netmgrs.co.uk)
+ Errath, Maximilian
+ (errath@balu.kfunigraz.ac.at)
+ Fisher, Lee
+ (leefi@microsoft.com)
+ Foderaro, Sean
+ (jkf@frisky.Franz.COM)
+ Greer, Brad
+ (brad@cac.washington.edu)
+ Griffith, Michael A
+ (grif@cs.ucr.edu)
+ Grosen, Mark
+ (MDGrosen@spectron.COM)
+ ????
+ (gunjkoa@dep.sa.gov.au)
+ Haapanen, Tom
+ (tomh@metrics.com)
+ Hench, Mike
+ (hench@cae.uwm.edu)
+ Horstman, Mark A
+ (mh2620@sarek.sbc.com)
+ Hudson, Tim
+ (tim.hudson@gslmail.mincom.oz.au)
+ Hulthen, Erik Magnus
+ (magnus@axiom.se)
+ ???
+ (imb@asstdc.scgt.oz.au)
+ Iversen, Per Steinar
+ (iversen@dsfys1.fi.uib.no)
+ Kaara, Pasi
+ (ppk@atk.tpo.fi)
+ Karman, Merik
+ (merik@blackadder.dsh.oz.au)
+ Kiff, Martin
+ (mgk@newton.npl.co.uk)
+ Kiick, Chris
+ (cjkiick@flinx.b11.ingr.com)
+ Kukulies, Christoph
+ (kuku@acds.physik.rwth-aachen.de)
+ ???
+ (lance@fox.com)
+ Lendecke, Volker
+ (lendecke@namu01.gwdg.de)
+ ???
+ (lonnie@itg.ti.com)
+ Mahoney, Paul Thomas
+ (ptm@xact1.xact.com)
+ Mauelshagen, Heinz
+ (mauelsha@ez.da.telekom.de)
+ Merrick, Barry G
+ (bgm@atml.co.uk)
+ Mol, Marcel
+ (marcel@fanout.et.tudeflt.nl)
+ ???
+ (njw@cpsg.com.au)
+ ???
+ (noses@oink.rhein.de)
+ Owens, John
+ (john@micros.com)
+ Pierson, Jacques
+ (pierson@ketje.enet.dec.com)
+ Powell, Mark
+ (mark@scot1.ucsalf.ac.uk)
+ Reiz, Steven
+ (sreiz@aie.nl)
+ Schlaeger, Joerg
+ (joergs@toppoint.de)
+ S{rkel{, Vesa
+ (vesku@rankki.kcl.fi)
+ Tridgell, Andrew
+ (samba-bugs@anu.edu.au)
+ Troyer, Dean
+ (troyer@saifr00.ateng.az.honeywell.com)
+ Wakelin, Ross
+ (rossw@march.co.uk)
+ Wessels, Stefan
+ (SWESSELS@dos-lan.cs.up.ac.za)
+ Young, Ian A
+ (iay@threel.co.uk)
+ van der Zwan, Paul
+ (paulzn@olivetti.nl)
+
diff --git a/docs/manpages/smb.conf.5 b/docs/manpages/smb.conf.5
new file mode 100644
index 0000000000..933d71ff0c
--- /dev/null
+++ b/docs/manpages/smb.conf.5
@@ -0,0 +1,2719 @@
+.TH SMB.CONF 5 11/10/94 smb.conf smb.conf
+.SH NAME
+smb.conf \- configuration file for smbd
+.SH SYNOPSIS
+.B smb.conf
+.SH DESCRIPTION
+The
+.B smb.conf
+file is a configuration file for the Samba suite.
+
+.B smb.conf
+contains runtime configuration information for the
+.B smbd
+program. The
+.B smbd
+program provides LanManager-like services to clients
+using the SMB protocol.
+
+.SH FILE FORMAT
+The file consists of sections and parameters. A section begins with the
+name of the section in square brackets and continues until the next
+section begins. Sections contain parameters of the form 'name = value'.
+
+The file is line-based - that is, each newline-terminated line represents
+either a comment, a section name or a parameter.
+
+Section and parameter names are not case sensitive.
+
+Only the first equals sign in a parameter is significant. Whitespace before
+or after the first equals sign is discarded. Leading, trailing and internal
+whitespace in section and parameter names is irrelevant. Leading and
+trailing whitespace in a parameter value is discarded. Internal whitespace
+within a parameter value is retained verbatim.
+
+Any line beginning with a semicolon is ignored, as are lines containing
+only whitespace.
+
+Any line ending in a \\ is "continued" on the next line in the
+customary unix fashion.
+
+The values following the equals sign in parameters are all either a string
+(no quotes needed) or a boolean, which may be given as yes/no, 0/1 or
+true/false. Case is not significant in boolean values, but is preserved
+in string values. Some items such as create modes are numeric.
+.SH SERVICE DESCRIPTIONS
+Each section in the configuration file describes a service. The section name
+is the service name and the parameters within the section define the service's
+attributes.
+
+There are three special sections, [global], [homes] and [printers], which are
+described under 'special sections'. The following notes apply to ordinary
+service descriptions.
+
+A service consists of a directory to which access is being given plus a
+description of the access rights which are granted to the user of the
+service. Some housekeeping options are also specifiable.
+
+Services are either filespace services (used by the client as an extension of
+their native file systems) or printable services (used by the client to access
+print services on the host running the server).
+
+Services may be guest services, in which case no password is required to
+access them. A specified guest account is used to define access privileges
+in this case.
+
+Services other than guest services will require a password to access
+them. The client provides the username. As many clients only provide
+passwords and not usernames, you may specify a list of usernames to
+check against the password using the "user=" option in the service
+definition.
+
+Note that the access rights granted by the server are masked by the access
+rights granted to the specified or guest user by the host system. The
+server does not grant more access than the host system grants.
+
+The following sample section defines a file space service. The user has write
+access to the path /home/bar. The service is accessed via the service name
+"foo":
+
+ [foo]
+ path = /home/bar
+ writable = true
+
+The following sample section defines a printable service. The service is
+readonly, but printable. That is, the only write access permitted is via
+calls to open, write to and close a spool file. The 'guest ok' parameter
+means access will be permitted as the default guest user (specified elsewhere):
+
+ [aprinter]
+ path = /usr/spool/public
+ read only = true
+ printable = true
+ public = true
+
+.SH SPECIAL SECTIONS
+
+.SS The [global] section
+.RS 3
+Parameters in this section apply to the server as a whole, or are defaults
+for services which do not specifically define certain items. See the notes
+under 'Parameters' for more information.
+.RE
+
+.SS The [homes] section
+.RS 3
+If a section called 'homes' is included in the configuration file, services
+connecting clients to their home directories can be created on the fly by the
+server.
+
+When the connection request is made, the existing services are scanned. If a
+match is found, it is used. If no match is found, the requested service name is
+treated as a user name and looked up in the local passwords file. If the
+name exists and the correct password has been given, a service is created
+by cloning the [homes] section.
+
+Some modifications are then made to the newly created section:
+
+.RS 3
+The service name is changed from 'homes' to the located username
+
+If no path was given, the path is set to the user's home directory.
+.RE
+
+If you decide to use a path= line in your [homes] section then you may
+find it useful to use the %S macro. For example path=/data/pchome/%S
+would be useful if you have different home directories for your PCs
+than for unix access.
+
+This is a fast and simple way to give a large number of clients access to
+their home directories with a minimum of fuss.
+
+A similar process occurs if the requested service name is "homes", except that
+the service name is not changed to that of the requesting user. This method
+of using the [homes] section works well if different users share a client PC.
+
+The [homes] section can specify all the parameters a normal service section
+can specify, though some make more sense than others. The following is a
+typical and suitable [homes] section:
+
+ [homes]
+ writable = yes
+
+An important point:
+
+.RS 3
+If guest access is specified in the [homes] section, all home directories will
+be accessible to all clients
+.B without a password.
+In the very unlikely event
+that this is actually desirable, it would be wise to also specify read only
+access.
+.RE
+.RE
+
+Note that the browseable flag for auto home directories will be
+inherited from the global browseable flag, not the [homes] browseable
+flag. This is useful as it means setting browseable=no in the [homes]
+section will hide the [homes] service but make any auto home
+directories visible.
+
+.SS The [printers] section
+.RS 3
+This section works like [homes], but for printers.
+
+If a [printers] section occurs in the configuration file, users are able
+to connect to any printer specified in the local host's printcap file.
+
+When a connection request is made, the existing services are scanned. If a
+match is found, it is used. If no match is found, but a [homes] section
+exists, it is used as described above. Otherwise, the requested service name is
+treated as a printer name and the appropriate printcap file is scanned to
+see if the requested service name is a valid printer name. If a match is
+found, a new service is created by cloning the [printers] section.
+
+A few modifications are then made to the newly created section:
+
+.RS 3
+The service name is set to the located printer name
+
+If no printer name was given, the printer name is set to the located printer
+name
+
+If the service does not permit guest access and no username was given, the
+username is set to the located printer name.
+.RE
+
+Note that the [printers] service MUST be printable - if you specify otherwise,
+the server will refuse to load the configuration file.
+
+Typically the path specified would be that of a world-writable spool directory
+with the sticky bit set on it. A typical [printers] entry would look like this:
+
+ [printers]
+ path = /usr/spool/public
+ writable = no
+ public = yes
+ printable = yes
+
+All aliases given for a printer in the printcap file are legitimate printer
+names as far as the server is concerned. If your printing subsystem doesn't
+work like that, you will have to set up a pseudo-printcap. This is a file
+consisting of one or more lines like this:
+
+ alias|alias|alias|alias...
+
+Each alias should be an acceptable printer name for your printing
+subsystem. In the [global] section, specify the new file as your printcap.
+The server will then only recognise names found in your pseudo-printcap,
+which of course can contain whatever aliases you like. The same technique
+could be used simply to limit access to a subset of your local printers.
+
+An alias, by the way, is defined as any component of the first entry of a
+printcap record. Records are separated by newlines, components (if there are
+more than one) are separated by vertical bar symbols ("|").
+.SH PARAMETERS
+Parameters define the specific attributes of services.
+
+Some parameters are specific to the [global] section (eg., security).
+Some parameters are usable in all sections (eg., create mode). All others are
+permissible only in normal sections. For the purposes of the following
+descriptions the [homes] and [printers] sections will be considered normal.
+The letter 'G' in parentheses indicates that a parameter is specific to the
+[global] section. The letter 'S' indicates that a parameter can be
+specified in a secvice specific section. Note that all S parameters
+can also be specified in the [global] section - in which case they
+will define the default behaviour for all services.
+
+Parameters are arranged here in alphabetical order - this may not create
+best bedfellows, but at least you can find them! Where there are synonyms,
+the preferred synonym is described, others refer to the preferred synonym.
+
+.SS VARIABLE SUBSTITUTIONS
+
+Many of the strings that are settable in the config file can take
+substitutions. For example the option "path = /tmp/%u" would be
+interpreted as "path = /tmp/john" if the user connected with the
+username john.
+
+These substitutions are mostly noted in the descriptions below, but
+there are some general substitions which apply whenever they might be
+relevant. These are:
+
+%S = the name of the current service, if any
+
+%P = the root directory of the current service, if any
+
+%u = user name of the current service, if any
+
+%g = primary group name of %u
+
+%U = session user name (the user name that the client wanted, not
+necessarily the same as the one they got)
+
+%G = primary group name of %U
+
+%H = the home directory of the user given by %u
+
+%v = the Samba version
+
+%h = the hostname that Samba is running on
+
+%m = the netbios name of the client machine (very useful)
+
+%L = the netbios name of the server. This allows you to change your
+config based on what the client calls you. Your server can have a "dual
+personality".
+
+%M = the internet name of the client machine
+
+%d = The process id of the current server process
+
+%a = the architecture of the remote machine. Only some are recognised,
+and those may not be 100% reliable. It currently recognises Samba,
+WfWg, WinNT and Win95. Anything else will be known as "UNKNOWN". If it
+gets it wrong then sending me a level 3 log should allow me to fix it.
+
+%I = The IP address of the client machine
+
+%T = the current date and time
+
+There are some quite creative things that can be done with these
+substitutions and other smb.conf options.
+
+.SS NAME MANGLING
+
+Samba supports "name mangling" so that Dos and Windows clients can use
+files that don't conform to the 8.3 format. It can also be set to adjust
+the case of 8.3 format filenames.
+
+There are several options that control the way mangling is performed,
+and they are grouped here rather than listed separately. For the
+defaults look at the output of the testparm program.
+
+All of these options can be set separately for each service (or
+globally, of course).
+
+The options are:
+
+"mangle case = yes/no" controls if names that have characters that
+aren't of the "default" case are mangled. For example, if this is yes
+then a name like "Mail" would be mangled. Default no.
+
+"case sensitive = yes/no" controls whether filenames are case
+sensitive. If they aren't then Samba must do a filename search and
+match on passed names. Default no.
+
+"default case = upper/lower" controls what the default case is for new
+filenames. Default lower.
+
+"preserve case = yes/no" controls if new files are created with the
+case that the client passes, or if they are forced to be the "default"
+case. Default no.
+
+"short preserve case = yes/no" controls if new files which conform to 8.3
+syntax, that is all in upper case and of suitable length, are created
+upper case, or if they are forced to be the "default" case. This option can
+be use with "preserve case = yes" to permit long filenames to retain their
+case, while short names are lowered. Default no.
+
+.SS COMPLETE LIST OF GLOBAL PARAMETER
+
+Here is a list of all global parameters. See the section of each
+parameter for details. Note that some are synonyms.
+
+auto services
+
+config file
+
+deadtime
+
+debuglevel
+
+default
+
+default service
+
+dfree command
+
+encrypt passwords
+
+getwd cache
+
+hosts equiv
+
+include
+
+keepalive
+
+lock dir
+
+load printers
+
+lock directory
+
+log file
+
+log level
+
+lpq cache time
+
+mangled stack
+
+max log size
+
+max packet
+
+max xmit
+
+message command
+
+null passwords
+
+os level
+
+packet size
+
+passwd chat
+
+passwd program
+
+password level
+
+password server
+
+preferred master
+
+preload
+
+printing
+
+printcap name
+
+protocol
+
+read bmpx
+
+read prediction
+
+read raw
+
+read size
+
+root
+
+root dir
+
+root directory
+
+security
+
+server string
+
+smbrun
+
+socket options
+
+status
+
+strip dot
+
+time offset
+
+username map
+
+use rhosts
+
+valid chars
+
+workgroup
+
+write raw
+
+.SS COMPLETE LIST OF SERVICE PARAMETER
+
+Here is a list of all service parameters. See the section of each
+parameter for details. Note that some are synonyms.
+
+admin users
+
+allow hosts
+
+alternate permissions
+
+available
+
+browseable
+
+case sensitive
+
+case sig names
+
+copy
+
+create mask
+
+create mode
+
+comment
+
+default case
+
+deny hosts
+
+directory
+
+dont descend
+
+exec
+
+force group
+
+force user
+
+guest account
+
+guest ok
+
+guest only
+
+hide dot files
+
+hosts allow
+
+hosts deny
+
+invalid users
+
+locking
+
+lppause command
+
+lpq command
+
+lpresume command
+
+lprm command
+
+magic output
+
+magic script
+
+mangle case
+
+mangled names
+
+mangling char
+
+map archive
+
+map hidden
+
+map system
+
+max connections
+
+min print space
+
+only guest
+
+only user
+
+path
+
+postexec
+
+postscript
+
+preserve case
+
+print command
+
+print ok
+
+printable
+
+printer
+
+printer name
+
+public
+
+read only
+
+read list
+
+revalidate
+
+root postexec
+
+root preexec
+
+set directory
+
+share modes
+
+short preserve case
+
+strict locking
+
+sync always
+
+user
+
+username
+
+users
+
+valid users
+
+volume
+
+wide links
+
+writable
+
+write ok
+
+writeable
+
+write list
+
+.SS EXPLANATION OF EACH PARAMETER
+.RS 3
+
+.SS admin users (G)
+
+This is a list of users who will be granted administrative privilages
+on the share. This means that they will do all file operations as the
+super-user (root).
+
+You should use this option very carefully, as any user in this list
+will be able to do anything they like on the share, irrespective of
+file permissions.
+
+.B Default:
+ no admin users
+
+.B Example:
+ admin users = jason
+
+.SS auto services (G)
+This is a list of services that you want to be automatically added to
+the browse lists. This is most useful for homes and printers services
+that would otherwise not be visible.
+
+Note that if you just want all printers in your printcap file loaded
+then the "load printers" option is easier.
+
+.B Default:
+ no auto services
+
+.B Example:
+ auto services = fred lp colorlp
+
+
+.SS allow hosts (S)
+A synonym for this parameter is 'hosts allow'.
+
+This parameter is a comma delimited set of hosts which are permitted to access
+a services. If specified in the [global] section, matching hosts will be
+allowed access to any service that does not specifically exclude them from
+access. Specific services my have their own list, which override those
+specified in the [global] section.
+
+You can specify the hosts by name or IP number. For example, you could
+restrict access to only the hosts on a Class C subnet with something like
+"allow hosts = 150.203.5.". The full syntax of the list is described in
+the man page
+.B hosts_access(5).
+
+You can also specify hosts by network/netmask pairs and by netgroup
+names if your system supports netgroups. The EXCEPT keyword can also
+be used to limit a wildcard list. The following examples may provide
+some help:
+
+Example 1: allow all IPs in 150.203.*.* except one
+
+ hosts allow = 150.203. EXCEPT 150.203.6.66
+
+Example 2: allow hosts that match the given network/netmask
+
+ hosts allow = 150.203.15.0/255.255.255.0
+
+Example 3: allow a couple of hosts
+
+ hosts allow = lapland, arvidsjaur
+
+Example 4: allow only hosts in netgroup "foonet" or localhost, but
+deny access from one particular host
+
+ hosts allow = @foonet, localhost
+ hosts deny = pirate
+
+Note that access still requires suitable user-level passwords.
+
+See testparm(1) for a way of testing your host access to see if it
+does what you expect.
+
+.B Default:
+ none (ie., all hosts permitted access)
+
+.B Example:
+ allow hosts = 150.203.5. myhost.mynet.edu.au
+
+.SS alternate permissions (S)
+
+This option affects the way the "read only" DOS attribute is produced
+for unix files. If this is false then the read only bit is set for
+files on writeable shares which the user cannot write to.
+
+If this is true then it is set for files whos user write bit is not set.
+
+The latter behaviour of useful for when users copy files from each
+others directories, and use a file manager that preserves
+permissions. Without this option they may get annoyed as all copied
+files will have the "read only" bit set.
+
+.B Default:
+ alternate permissions = no
+
+.B Example:
+ alternate permissions = yes
+
+.SS available (S)
+This parameter lets you 'turn off' a service. If 'available = no', then
+ALL attempts to connect to the service will fail. Such failures are logged.
+
+.B Default:
+ available = yes
+
+.B Example:
+ available = no
+.SS browseable (S)
+This controls whether this share is seen in the list of available
+shares in a net view and in the browse list.
+
+.B Default:
+ browseable = Yes
+
+.B Example:
+ browseable = No
+
+.SS case sig names (G)
+See "case sensitive"
+
+.SS comment (S)
+This is a text field that is seen when a client does a net view to
+list what shares are available. It will also be used when browsing is
+fully supported.
+
+.B Default:
+ No comment string
+
+.B Example:
+ comment = Fred's Files
+
+.SS config file (G)
+
+This allows you to override the config file to use, instead of the
+default (usually smb.conf). There is a chicken and egg problem here as
+this option is set in the config file!
+
+For this reason, if the name of the config file has changed when the
+parameters are loaded then it will reload them from the new config
+file.
+
+This option takes the usual substitutions, which can be very useful.
+
+If thew config file doesn't exist then it won't be loaded (allowing
+you to special case the config files of just a few clients).
+
+.B Example:
+ config file = /usr/local/samba/smb.conf.%m
+
+.SS copy (S)
+This parameter allows you to 'clone' service entries. The specified
+service is simply duplicated under the current service's name. Any
+parameters specified in the current section will override those in the
+section being copied.
+
+This feature lets you set up a 'template' service and create similar
+services easily. Note that the service being copied must occur earlier
+in the configuration file than the service doing the copying.
+
+.B Default:
+ none
+
+.B Example:
+ copy = otherservice
+.SS create mask (S)
+A synonym for this parameter is 'create mode'.
+
+This parameter is the octal modes which are used when converting DOS modes
+to Unix modes.
+
+Note that Samba will or this value with 0700 as you must have at least
+user read, write and execute for Samba to work properly.
+
+.B Default:
+ create mask = 0755
+
+.B Example:
+ create mask = 0775
+.SS create mode (S)
+See
+.B create mask.
+.SS dead time (G)
+The value of the parameter (a decimal integer) represents the number of
+minutes of inactivity before a connection is considered dead, and it
+is disconnected. The deadtime only takes effect if the number of open files
+is zero.
+
+This is useful to stop a server's resources being exhausted by a large
+number of inactive connections.
+
+Most clients have an auto-reconnect feature when a connection is broken so
+in most cases this parameter should be transparent to users.
+
+Using this parameter with a timeout of a few minutes is recommended
+for most systems.
+
+A deadtime of zero indicates that no auto-disconnection should be performed.
+
+.B Default:
+ dead time = 0
+
+.B Example:
+ dead time = 15
+.SS debug level (G)
+The value of the parameter (an integer) allows the debug level
+(logging level) to be specified in the smb.conf file. This is to give
+greater flexibility in the configuration of the system.
+
+The default will be the debug level specified on the command line.
+
+.B Example:
+ debug level = 3
+.SS default (G)
+See
+.B default service.
+.SS default case (S)
+
+See the section on "NAME MANGLING" Also note the addition of "short
+preserve case"
+
+.SS default service (G)
+A synonym for this parameter is 'default'.
+
+This parameter specifies the name of a service which will be connected to
+if the service actually requested cannot be found. Note that the square
+brackets are NOT given in the parameter value (see example below).
+
+There is no default value for this parameter. If this parameter is not given,
+attempting to connect to a nonexistent service results in an error.
+
+Typically the default service would be a public, read-only service.
+
+Also not that s of 1.9.14 the apparent service name will be changed to
+equal that of the requested service, this is very useful as it allows
+you to use macros like %S to make a wildcard service.
+
+Note also that any _ characters in the name of the service used in the
+default service will get mapped to a /. This allows for interesting
+things.
+
+
+.B Example:
+ default service = pub
+
+ [pub]
+ path = /%S
+
+
+.SS deny hosts (S)
+A synonym for this parameter is 'hosts deny'.
+
+The opposite of 'allow hosts' - hosts listed here are NOT permitted
+access to services unless the specific services have their own lists to
+override this one. Where the lists conflict, the 'allow' list takes precedence.
+
+.B Default:
+ none (ie., no hosts specifically excluded)
+
+.B Example:
+ deny hosts = 150.203.4. badhost.mynet.edu.au
+.SS dfree command (G)
+The dfree command setting should only be used on systems where a
+problem occurs with the internal disk space calculations. This has
+been known to happen with Ultrix, but may occur with other operating
+systems. The symptom that was seen was an error of "Abort Retry
+Ignore" at the end of each directory listing.
+
+This setting allows the replacement of the internal routines to
+calculate the total disk space and amount available with an external
+routine. The example below gives a possible script that might fulfill
+this function.
+
+The external program will be passed a single parameter indicating a
+directory in the filesystem being queried. This will typically consist
+of the string "./". The script should return two integers in ascii. The
+first should be the total disk space in blocks, and the second should
+be the number of available blocks. An optional third return value
+can give the block size in bytes. The default blocksize is 1024 bytes.
+
+Note: Your script should NOT be setuid or setgid and should be owned by
+(and writable only by) root!
+
+.B Default:
+ By default internal routines for determining the disk capacity
+and remaining space will be used.
+
+.B Example:
+ dfree command = /usr/local/smb/dfree
+
+ Where the script dfree (which must be made executable) could be
+
+ #!/bin/sh
+ df $1 | tail -1 | awk '{print $2" "$4}'
+
+ or perhaps (on Sys V)
+
+ #!/bin/sh
+ /usr/bin/df -k $1 | tail -1 | awk '{print $3" "$5}'
+
+
+ Note that you may have to replace the command names with full
+path names on some systems.
+.SS directory (S)
+See
+.B path.
+.SS dont descend (S)
+There are certain directories on some systems (eg., the /proc tree under
+Linux) that are either not of interest to clients or are infinitely deep
+(recursive). This parameter allows you to specify a comma-delimited list
+of directories that the server should always show as empty.
+
+Note that Samba can be very fussy about the exact format of the "dont
+descend" entries. For example you ma need "./proc" instead of just
+"/proc". Experimentation is the best policy :-)
+
+.B Default:
+ none (ie., all directories are OK to descend)
+
+.B Example:
+ dont descend = /proc,/dev
+
+.SS encrypt passwords (G)
+
+This boolean controls whether encrypted passwords will be negotiated
+with the cient. Note that this option has no effect if you haven't
+compiled in the necessary des libraries and encryption code. It
+defaults to no.
+
+.SS exec (S)
+
+This is an alias for preexec
+
+
+.SS force group (S)
+This specifies a group name that all connections to this service
+should be made as. This may be useful for sharing files.
+
+.B Default:
+ no forced group
+
+.B Example:
+ force group = agroup
+
+.SS force user (S)
+This specifies a user name that all connections to this service
+should be made as. This may be useful for sharing files. You should
+also use it carefully as using it incorrectly can cause security
+problems.
+
+This user name only gets used once a connection is established. Thus
+clients still need to connect as a valid user and supply a valid
+password. Once connected, all file operations will be performed as the
+"forced user", not matter what username the client connected as.
+
+.B Default:
+ no forced user
+
+.B Example:
+ force user = auser
+
+.SS guest account (S)
+This is a username which will be used for access to services which are
+specified as 'guest ok' (see below). Whatever privileges this user has
+will be available to any client connecting to the guest
+service. Typically this user will exist in the password file, but will
+not have a valid login. If a username is specified in a given service,
+the specified username overrides this one.
+
+One some systems the account "nobody" may not be able to print. Use
+another account in this case. You should test this by trying to log in
+as your guest user (perhaps by using the "su -" command) and trying to
+print using lpr.
+
+Note that as of version 1.9 of Samba this option may be set
+differently for each service.
+
+.B Default:
+ specified at compile time
+
+.B Example:
+ guest account = nobody
+.SS getwd cache (G)
+This is a tuning option. When this is enabled a cacheing algorithm will
+be used to reduce the time taken for getwd() calls. This can have a
+significant impact on performance, especially when widelinks is False.
+
+.B Default:
+ getwd cache = No
+
+.B Example:
+ getwd cache = Yes
+.SS guest ok (S)
+See
+.B public.
+.SS guest only (S)
+If this parameter is 'yes' for a service, then only guest connections to the
+service are permitted. This parameter will have no affect if "guest ok" or
+"public" is not set for the service.
+
+See the section below on user/password validation for more information about
+this option.
+
+.B Default:
+ guest only = no
+
+.B Example:
+ guest only = yes
+.SS hide dot files (S)
+This is a boolean parameter that controls whether files starting with
+a dot appear as hidden files.
+
+.B Default:
+ hide dot files = yes
+
+.B Example:
+ hide dot files = no
+.SS hosts allow (S)
+See
+.B allow hosts.
+.SS hosts deny (S)
+See
+.B deny hosts.
+
+.SS group (S)
+This is an alias for "force group" and is only kept for compatability
+with old versions of Samba. It may be removed in future versions.
+
+.SS hosts equiv (G)
+If this global parameter is a non-null string, it specifies the name of
+a file to read for the names of hosts and users who will be allowed access
+without specifying a password.
+
+This is not be confused with
+.B allow hosts
+which is about hosts access to services and is more useful for guest services.
+.B hosts equiv
+may be useful for NT clients which will not supply passwords to samba.
+
+NOTE: The use of hosts.equiv can be a major security hole. This is
+because you are trusting the PC to supply the correct username. It is
+very easy to get a PC to supply a false username. I recommend that the
+hosts.equiv option be only used if you really know what you are doing,
+or perhaps on a home network where you trust your wife and kids :-)
+
+.B Default
+ No host equivalences
+
+.B Example
+ hosts equiv = /etc/hosts.equiv
+
+.SS invalid users (S)
+This is a list of users that should not be allowed to login to this
+service. This is really a "paranoid" check to absolutely ensure an
+improper setting does not breach your security.
+
+A name starting with @ is interpreted as a unix group.
+
+The current servicename is substituted for %S. This is useful in the
+[homes] section.
+
+See also "valid users"
+
+.B Default
+ No invalid users
+
+.B Example
+ invalid users = root fred admin @wheel
+
+.SS include (G)
+
+This allows you to inlcude one config file inside another. the file is
+included literally, as though typed in place.
+
+It takes the standard substitutions, except %u, %P and %S
+
+.SS keep alive (G)
+The value of the parameter (an integer) represents the number of seconds
+between 'keepalive' packets. If this parameter is zero, no keepalive packets
+will be sent. Keepalive packets, if sent, allow the server to tell whether a
+client is still present and responding.
+
+Keepalives should, in general, not be needed if the socket being used
+has the SO_KEEPALIVE attribute set on it (see "socket
+options"). Basically you should only use this option if you strike
+difficulties.
+
+.B Default:
+ keep alive = 0
+
+.B Example:
+ keep alive = 60
+.SS load printers (G)
+A boolean variable that controls whether all printers in the printcap
+will be loaded for browsing by default.
+
+.B Default:
+ load printers = no
+
+.B Example:
+ load printers = yes
+
+.SS lock directory (G)
+This options specifies the directory where lock files will be placed.
+The lock files are used to implement the "max connections" option.
+
+.B Default:
+ lock directory = /tmp/samba
+
+.B Example:
+ lock directory = /usr/local/samba/locks
+.SS locking (S)
+This controls whether or not locking will be performed by the server in
+response to lock requests from the client.
+
+If "locking = no", all lock and unlock requests will appear to succeed and
+all lock queries will indicate that the queried lock is clear.
+
+If "locking = yes", real locking will be performed by the server.
+
+This option may be particularly useful for read-only filesystems which
+do not need locking (such as cdrom drives).
+
+Be careful about disabling locking either globally or in a specific
+service, as lack of locking may result in data corruption.
+
+.B Default:
+ locking = yes
+
+.B Example:
+ locking = no
+
+.SS log file (G)
+
+This options allows you to override the name of the Samba log file
+(also known as the debug file).
+
+This option takes the standard substitutions, allowing you to have
+separate log files for each user or machine.
+
+.B Example:
+ log file = /usr/local/samba/log.%m
+
+.SS log level (G)
+see "debug level"
+
+.SS lppause command (S)
+This parameter specifies the command to be executed on the server host in
+order to stop printing or spooling a specific print job.
+
+This command should be a program or script which takes a printer name and
+job number to pause the print job. Currently I don't know of any print
+spooler system that can do this with a simple option, except for the PPR
+system from Trinity College (ppr\-dist.trincoll.edu/pub/ppr). One way
+of implementing this is by using job priorities, where jobs having a too
+low priority wont be sent to the printer. See also the lppause command.
+
+If a %p is given then the printername is put in it's place. A %j is
+replaced with the job number (an integer).
+On HPUX (see printing=hpux), if the -p%p option is added to the lpq
+command, the job will show up with the correct status, i.e. if the job
+priority is lower than the set fence priority it will have the PAUSED
+status, whereas if the priority is equal or higher it will have the
+SPOOLED or PRINTING status.
+
+Note that it is good practice to include the absolute path in the lppause
+command as the PATH may not be available to the server.
+
+.B Default:
+ Currently no default value is given to this string
+
+.B Example for HPUX:
+ lppause command = /usr/bin/lpalt %p-%j -p0
+
+.SS lpq cache time (G)
+
+This controls how long lpq info will be cached for to prevent the lpq
+command being called too often. A separate cache is kept for each
+variation of the lpq command used by the system, so if you use
+different lpq commands for different users then they won't share cache
+information.
+
+The cache files are stored in /tmp/lpq.xxxx where xxxx is a hash
+of the lpq command in use.
+
+The default is 10 seconds, meaning that the cached results of a
+previous identical lpq command will be used if the cached data is less
+than 10 seconds old. A large value may be advisable if your lpq
+command is very slow.
+
+A value of 0 will disable cacheing completely.
+
+.B Default:
+ lpq cache time = 10
+
+.B Example:
+ lpq cache time = 30
+
+.SS lpq command (S)
+This parameter specifies the command to be executed on the server host in
+order to obtain "lpq"-style printer status information.
+
+This command should be a program or script which takes a printer name
+as its only parameter and outputs printer status information.
+
+Currently four styles of printer status information are supported;
+BSD, SYSV, AIX and HPUX. This covers most unix systems. You control
+which type is expected using the "printing =" option.
+
+Some clients (notably Windows for Workgroups) may not correctly send the
+connection number for the printer they are requesting status information
+about. To get around this, the server reports on the first printer service
+connected to by the client. This only happens if the connection number sent
+is invalid.
+
+If a %p is given then the printername is put in it's place. Otherwise
+it is placed at the end of the command.
+
+Note that it is good practice to include the absolute path in the lpq
+command as the PATH may not be available to the server.
+
+.B Default:
+ depends on the setting of "printing ="
+
+.B Example:
+ lpq command = /usr/bin/lpq %p
+
+.SS lpresume command (S)
+This parameter specifies the command to be executed on the server host in
+order to restart or continue printing or spooling a specific print job.
+
+This command should be a program or script which takes a printer name and
+job number to resume the print job. See also the lppause command.
+
+If a %p is given then the printername is put in it's place. A %j is
+replaced with the job number (an integer).
+
+Note that it is good practice to include the absolute path in the lpresume
+command as the PATH may not be available to the server.
+
+.B Default:
+ Currently no default value is given to this string
+
+.B Example for HPUX:
+ lpresume command = /usr/bin/lpalt %p-%j -p2
+
+.SS lprm command (S)
+This parameter specifies the command to be executed on the server host in
+order to delete a print job.
+
+This command should be a program or script which takes a printer name
+and job number, and deletes the print job.
+
+Currently four styles of printer control are supported; BSD, SYSV, AIX
+and HPUX. This covers most unix systems. You control which type is
+expected using the "printing =" option.
+
+If a %p is given then the printername is put in it's place. A %j is
+replaced with the job number (an integer).
+
+Note that it is good practice to include the absolute path in the lprm
+command as the PATH may not be available to the server.
+
+.B Default:
+ depends on the setting of "printing ="
+
+.B Example 1:
+ lprm command = /usr/bin/lprm -P%p %j
+
+.B Example 2:
+ lprm command = /usr/bin/cancel %p-%j
+
+.SS magic output (S)
+This parameter specifies the name of a file which will contain output
+created by a magic script (see
+.I magic script
+below).
+
+Warning: If two clients use the same magic script in the same directory the
+output file content is undefined.
+.B Default:
+ magic output = <magic script name>.out
+
+.B Example:
+ magic output = myfile.txt
+.SS magic script (S)
+This parameter specifies the name of a file which, if opened, will be
+executed by the server when the file is closed. This allows a Unix script
+to be sent to the Samba host and executed on behalf of the connected user.
+
+Scripts executed in this way will be deleted upon completion, permissions
+permitting.
+
+If the script generates output, output will be sent to the file specified by
+the
+.I magic output
+parameter (see above).
+
+Note that some shells are unable to interpret scripts containing
+carriage-return-linefeed instead of linefeed as the end-of-line
+marker. Magic scripts must be executable "as is" on the host, which
+for some hosts and some shells will require filtering at the DOS end.
+
+Magic scripts are EXPERIMENTAL and should NOT be relied upon.
+.B Default:
+ None. Magic scripts disabled.
+
+.B Example:
+ magic script = user.csh
+.SS mangled map (S)
+This is for those who want to directly map UNIX file names which are
+not representable on DOS. The mangling of names is not always what is
+needed. In particular you may have documents with file extensiosn
+that differ between dos and unix. For example, under unix it is common
+to use .html for HTML files, whereas under dos .htm is more commonly
+used.
+
+So to map 'html' to 'htm' you put:
+
+ mangled map = (*.html *.htm)
+
+One very useful case is to remove the annoying ;1 off the ends of
+filenames on some CDROMS (only visible under some unixes). To do this
+use a map of (*;1 *)
+
+.B default:
+ no mangled map
+
+.B Example:
+ mangled map = (*;1 *)
+
+.SS mangle case (S)
+
+See the section on "NAME MANGLING"
+
+.SS mangled names (S)
+This controls whether non-DOS names under Unix should be mapped to
+DOS-compatible names ("mangled") and made visible, or whether non-DOS names
+should simply be ignored.
+
+See the section on "NAME MANGLING" for details on how to control the
+mangling process.
+
+If mangling is used then the mangling algorithm is as follows:
+.RS
+- the first (up to) five alphanumeric characters before the rightmost dot of
+the filename are preserved, forced to upper case, and appear as the first (up
+to) five characters of the mangled name.
+
+- a tilde ("~") is appended to the first part of the mangled name, followed
+by a two-character unique sequence, based on the origonal root name
+(i.e., the original filename minus its final extension). The final
+extension is included in the hash calculation only if it contains any upper
+case characters or is longer than three characters.
+
+Note that the character to use may be specified using the "mangling
+char" option, if you don't like ~.
+
+- the first three alphanumeric characters of the final extension are preserved,
+forced to upper case and appear as the extension of the mangled name. The
+final extension is defined as that part of the original filename after the
+rightmost dot. If there are no dots in the filename, the mangled name will
+have no extension (except in the case of hidden files - see below).
+
+- files whose Unix name begins with a dot will be presented as DOS hidden
+files. The mangled name will be created as for other filenames, but with the
+leading dot removed and "___" as its extension regardless of actual original
+extension (that's three underscores).
+.RE
+
+The two-digit hash value consists of upper case alphanumeric characters.
+
+This algorithm can cause name collisions only if files in a directory share
+the same first five alphanumeric characters. The probability of such a clash
+is 1/1300.
+
+The name mangling (if enabled) allows a file to be copied between Unix
+directories from DOS while retaining the long Unix filename. Unix files can
+be renamed to a new extension from DOS and will retain the same basename.
+Mangled names do not change between sessions.
+
+.B Default:
+ mangled names = yes
+
+.B Example:
+ mangled names = no
+.SS mangling char (S)
+This controls what character is used as the "magic" character in name
+mangling. The default is a ~ but this may interfere with some
+software. Use this option to set it to whatever you prefer.
+
+.B Default:
+ mangling char = ~
+
+.B Example:
+ mangling char = ^
+
+.SS max log size (G)
+
+This option (an integer in kilobytes) specifies the max size the log
+file should grow to. Samba periodically checks the size and if it is
+exceeded it will rename the file, adding a .old extension.
+
+A size of 0 means no limit.
+
+.B Default:
+ max log size = 5000
+
+.B Example:
+ max log size = 1000
+
+.SS max xmit (G)
+
+This option controls the maximum packet size that will be negotiated
+by Samba. The default is 65535, which is the maximum. In some cases
+you may find you get better performance with a smaller value. A value
+below 2048 is likely to cause problems.
+
+.B Default:
+ max xmit = 65535
+
+.B Example:
+ max xmit = 8192
+
+.SS mangled stack (G)
+This parameter controls the number of mangled names that should be cached in
+the Samba server.
+
+This stack is a list of recently mangled base names (extensions are only
+maintained if they are longer than 3 characters or contains upper case
+characters).
+
+The larger this value, the more likely it is that mangled names can be
+successfully converted to correct long Unix names. However, large stack
+sizes will slow most directory access. Smaller stacks save memory in the
+server (each stack element costs 256 bytes).
+
+It is not possible to absolutely guarantee correct long file names, so
+be prepared for some surprises!
+
+.B Default:
+ mangled stack = 50
+
+.B Example:
+ mangled stack = 100
+
+.SS map archive (S)
+This controls whether the DOS archive attribute should be mapped to Unix
+execute bits. The DOS archive bit is set when a file has been modified
+since its last backup. One motivation for this option it to keep Samba/your
+PC from making any file it touches from becoming executable under UNIX.
+This can be quite annoying for shared source code, documents, etc...
+
+.B Default:
+ map archive = yes
+
+.B Example:
+ map archive = no
+
+.SS map hidden (S)
+This controls whether DOS style hidden files should be mapped to Unix
+execute bits.
+
+.B Default:
+ map hidden = no
+
+.B Example:
+ map hidden = yes
+.SS map system (S)
+This controls whether DOS style system files should be mapped to Unix
+execute bits.
+
+.B Default:
+ map system = no
+
+.B Example:
+ map system = yes
+.SS max connections (S)
+This option allows the number of simultaneous connections to a
+service to be limited. If "max connections" is greater than 0 then
+connections will be refused if this number of connections to the
+service are already open. A value of zero mean an unlimited number of
+connections may be made.
+
+Record lock files are used to implement this feature. The lock files
+will be stored in the directory specified by the "lock directory" option.
+
+.B Default:
+ max connections = 0
+
+.B Example:
+ max connections = 10
+.SS only user (S)
+This is a boolean option that controls whether connections with
+usernames not in the user= list will be allowed. By default this
+option is disabled so a client can supply a username to be used by
+the server.
+
+Note that this also means Samba won't try to deduce usernames from the
+service name. This can be annoying for the [homes] section. To get
+around this you could use "user = %S" which means your "user" list
+will be just the service name, which for home directories is the name
+of the user.
+
+.B Default:
+ only user = False
+
+.B Example:
+ only user = True
+
+.SS message command (G)
+
+This specifies what command to run when the server receives a WinPopup
+style message.
+
+This would normally be a command that would deliver the message
+somehow. How this is to be done is up to your imagination.
+
+What I use is:
+
+ message command = csh -c 'xedit %s;rm %s' &
+
+This delivers the message using xedit, then removes it
+afterwards. NOTE THAT IT IS VERY IMPORTANT THAT THIS COMMAND RETURN
+IMMEDIATELY. That's why I have the & on the end. If it doesn't return
+immediately then your PCs may freeze when sending messages (they
+should recover after 30secs, hopefully).
+
+All messages are delivered as the global guest user. The command takes
+the standard substitutions, although %u won't work (%U may be better
+in this case).
+
+Apart from the standard substitutions, some additional ones apply. In
+particular:
+
+%s = the filename containing the message
+
+%t = the destination that the message was sent to (probably the server
+name)
+
+%f = who the message is from
+
+You could make this command send mail, or whatever else takes your
+fancy. Please let me know of any really interesting ideas you have.
+
+Here's a way of sending the messages as mail to root:
+
+message command = /bin/mail -s 'message from %f on %m' root < %s; rm %s
+
+If you don't have a message command then the message won't be
+delivered and Samba will tell the sender there was an
+error. Unfortunately WfWg totally ignores the error code and carries
+on regardless, saying that the message was delivered.
+
+If you want to silently delete it then try "message command = rm %s".
+
+For the really adventurous, try something like this:
+
+message command = csh -c 'csh < %s |& /usr/local/samba/smbclient \\
+ -M %m; rm %s' &
+
+this would execute the command as a script on the server, then give
+them the result in a WinPopup message. Note that this could cause a
+loop if you send a message from the server using smbclient! You better
+wrap the above in a script that checks for this :-)
+
+.B Default:
+ no message command
+
+.B Example:
+ message command = csh -c 'xedit %s;rm %s' &
+
+.SS min print space (S)
+
+This sets the minimum amount of free disk space that must be available
+before a user will be able to spool a print job. It is specified in
+kilobytes. The default is 0, which means no limit.
+
+.B Default:
+ min print space = 0
+
+.B Example:
+ min print space = 2000
+
+.SS null passwords (G)
+Allow or disallow access to accounts that have null passwords.
+
+.B Default:
+ null passwords = no
+
+.B Example:
+ null passwords = yes
+
+.SS os level (G)
+This integer value controls what level Samba advertises itself as for
+browse elections. See BROWSING.txt for details.
+
+.SS packet size (G)
+The maximum transmit packet size during a raw read. This option is no
+longer implemented as of version 1.7.00, and is kept only so old
+configuration files do not become invalid.
+
+.SS passwd chat (G)
+This string coontrols the "chat" conversation that takes places
+between smbd and the local password changing program to change the
+users password. The string describes a sequence of response-receive
+pairs that smbd uses to determine what to send to the passwd program
+and what to expect back. If the expected output is not received then
+the password is not changed.
+
+This chat sequence is often quite site specific, deppending on what
+local methods are used for password control (such as NIS+ etc).
+
+The string can contain the macros %o and %n which are substituted for
+the old and new passwords respectively. It can aso contain the
+standard macros \\n \\r \\t and \\s to give line-feed, carriage-return,
+tab and space.
+
+The string can also contain a * which matches any sequence of
+characters.
+
+Double quotes can be used to collect strings with spaces in them into
+a single string.
+
+If the send string in any part of the chat sequence is a fullstop "."
+then no string is sent. Similarly, is the expect string is a fullstop
+then no string is expected.
+
+.B Example:
+ passwd chat = "*Enter OLD password*" %o\\n "*Enter NEW password*" %n\\n \\
+ "*Reenter NEW password*" %n\\n "*Password changed*"
+
+.B Default:
+ passwd chat = *old*password* %o\\n *new*password* %n\\n *new*password* %n\\n *changed*
+
+.SS passwd program (G)
+The name of a program that can be used to set user passwords.
+
+This is only necessary if you have enabled remote password changing at
+compile time. Any occurances of %u will be replaced with the user
+name.
+
+Also note that many passwd programs insist in "reasonable" passwords,
+such as a minimum length, or the inclusion of mixed case chars and
+digits. This can pose a problem as some clients (such as Windows for
+Workgroups) uppercase the password before sending it.
+
+.B Default:
+ passwd program = /bin/passwd
+
+.B Example:
+ passwd program = /sbin/passwd %u
+
+.SS password level (G)
+Some client/server conbinations have difficulty with mixed-case passwords.
+One offending client is Windows for Workgroups, which for some reason forces
+passwords to upper case when using the LANMAN1 protocol, but leaves them alone
+when using COREPLUS!
+
+This parameter defines the maximum number of characters that may be upper case
+in passwords.
+
+For example, say the password given was "FRED". If
+.B password level
+is set to 1 (one), the following combinations would be tried if "FRED" failed:
+"Fred", "fred", "fRed", "frEd", "freD". If
+.B password level was set to 2 (two), the following combinations would also be
+tried: "FRed", "FrEd", "FreD", "fREd", "fReD", "frED". And so on.
+
+The higher value this parameter is set to the more likely it is that a mixed
+case password will be matched against a single case password. However, you
+should be aware that use of this parameter reduces security and increases the
+time taken to process a new connection.
+
+A value of zero will cause only two attempts to be made - the password as is
+and the password in all-lower case.
+
+If you find the connections are taking too long with this option then
+you probably have a slow crypt() routine. Samba now comes with a fast
+"ufc crypt" that you can select in the Makefile. You should also make
+sure the PASSWORD_LENGTH option is correct for your system in local.h
+and includes.h. On most systems only the first 8 chars of a password
+are significant so PASSWORD_LENGTH should be 8, but on some longer
+passwords are significant. The inlcudes.h file tries to select the
+right length for your system.
+
+.B Default:
+ password level = 0
+
+.B Example:
+ password level = 4
+
+.SS password server (G)
+
+By specifying the name of another SMB server (such as a WinNT box)
+with this option, and using "security = server" you can get Samba to
+do all it's username/password validation via a remote server.
+
+This options sets the name of the password server to use. It must be a
+netbios name, so if the machines netbios name is different from it's
+internet name then you may have to add it's netbios name to
+/etc/hosts.
+
+The password server much be a machine capable of using the "LM1.2X002"
+or the "LM NT 0.12" protocol, and it must be in user level security
+mode.
+
+NOTE: Using a password server means your unix box (running Samba) is
+only as secure as your password server. DO NOT CHOOSE A PASSWORD
+SERVER THAT YOU DON'T COMPLETELY TRUST.
+
+Never point a Samba server at itself for password serving. This will
+cause a loop and could lock up your Samba server!
+
+The name of the password server takes the standard substitutions, but
+probably the only useful one is %m, which means the Samba server will
+use the incoming client as the password server. If you use this then
+you better trust your clients, and you better restrict them with hosts
+allow!
+
+If you list several hosts in the "password server" option then smbd
+will try each in turn till it finds one that responds. This is useful
+in case your primary server goes down.
+
+.SS path (S)
+A synonym for this parameter is 'directory'.
+
+This parameter specifies a directory to which the user of the service is to
+be given access. In the case of printable services, this is where print data
+will spool prior to being submitted to the host for printing.
+
+For a printable service offering guest access, the service should be readonly
+and the path should be world-writable and have the sticky bit set. This is not
+mandatory of course, but you probably won't get the results you expect if you
+do otherwise.
+
+Any occurances of %u in the path will be replaced with the username
+that the client is connecting as. Any occurances of %m will be
+replaced by the name of the machine they are connecting from. These
+replacements are very useful for setting up pseudo home directories
+for users.
+
+Note that this path will be based on 'root dir' if one was specified.
+.B Default:
+ none
+
+.B Example:
+ path = /home/fred+
+
+.SS postexec (S)
+
+This option specifies a command to be run whenever the service is
+disconnected. It takes the usual substitutions. The command may be run
+as the root on some systems.
+
+An interesting example may be do unmount server resources:
+
+postexec = /etc/umount /cdrom
+
+See also preexec
+
+.B Default:
+ none (no command executed)
+
+.B Example:
+ postexec = echo \"%u disconnected from %S from %m (%I)\" >> /tmp/log
+
+.SS postscript (S)
+This parameter forces a printer to interpret the print files as
+postscript. This is done by adding a %! to the start of print output.
+
+This is most useful when you have lots of PCs that persist in putting
+a control-D at the start of print jobs, which then confuses your
+printer.
+
+.B Default:
+ postscript = False
+
+.B Example:
+ postscript = True
+
+.SS preexec (S)
+
+This option specifies a command to be run whenever the service is
+connected to. It takes the usual substitutions.
+
+An interesting example is to send the users a welcome message every
+time they log in. Maybe a message of the day? Here is an example:
+
+preexec = csh -c 'echo \"Welcome to %S!\" | \
+ /usr/local/samba/smbclient -M %m -I %I' &
+
+Of course, this could get annoying after a while :-)
+
+See also postexec
+
+.B Default:
+ none (no command executed)
+
+.B Example:
+ preexec = echo \"%u connected to %S from %m (%I)\" >> /tmp/log
+
+.SS preferred master (G)
+This boolean parameter controls if Samba is a preferred master browser
+for its workgroup. Setting this gives it a slight edge in elections
+and also means it will automatically start an election when it starts
+up.
+
+It is on by default.
+
+.SS preload
+This is an alias for "auto services"
+
+.SS preserve case (S)
+
+This controls if new filenames are created with the case that the
+client passes, or if they are forced to be the "default" case.
+
+.B Default:
+ preserve case = no
+
+See the section on "NAME MANGLING" for a fuller discussion.
+
+.SS print command (S)
+After a print job has finished spooling to a service, this command will be
+used via a system() call to process the spool file. Typically the command
+specified will submit the spool file to the host's printing subsystem, but
+there is no requirement that this be the case. The server will not remove the
+spool file, so whatever command you specify should remove the spool file when
+it has been processed, otherwise you will need to manually remove old spool
+files.
+
+The print command is simply a text string. It will be used verbatim,
+with two exceptions: All occurrences of "%s" will be replaced by the
+appropriate spool file name, and all occurrences of "%p" will be
+replaced by the appropriate printer name. The spool file name is
+generated automatically by the server, the printer name is discussed
+below.
+
+The full path name will be used for the filename if %s is not preceded
+by a /. If you don't like this (it can stuff up some lpq output) then
+use %f instead. Any occurances of %f get replaced by the spool
+filename without the full path at the front.
+
+The print command MUST contain at least one occurrence of "%s" or %f -
+the "%p" is optional. At the time a job is submitted, if no printer
+name is supplied the "%p" will be silently removed from the printer
+command.
+
+If specified in the [global] section, the print command given will be used
+for any printable service that does not have its own print command specified.
+
+If there is neither a specified print command for a printable service nor a
+global print command, spool files will be created but not processed and (most
+importantly) not removed.
+
+Note that printing may fail on some unixes from the "nobody"
+account. If this happens then create an alternative guest account that
+can print and set the "guest account" in the [global] section.
+
+You can form quite complex print commands by realising that they are
+just passed to a shell. For example the following will log a print
+job, print the file, then remove it. Note that ; is the usual
+separator for command in shell scripts.
+
+print command = echo Printing %s >> /tmp/print.log; lpr -P %p %s; rm %s
+
+You may have to vary this command considerably depending on how you
+normally print files on your system.
+
+.B Default:
+ print command = lpr -r -P %p %s
+
+.B Example:
+ print command = /usr/local/samba/myprintscript %p %s
+.SS print ok (S)
+See
+.B printable.
+.SS printable (S)
+A synonym for this parameter is 'print ok'.
+
+If this parameter is 'yes', then clients may open, write to and submit spool
+files on the directory specified for the service.
+
+Note that a printable service will ALWAYS allow writing to the service path
+(user privileges permitting) via the spooling of print data. The 'read only'
+parameter controls only non-printing access to the resource.
+
+.B Default:
+ printable = no
+
+.B Example:
+ printable = yes
+
+.SS printing (G)
+This parameters controls how printer status information is interpreted
+on your system, and also affects the default values for the "print
+command", "lpq command" and "lprm command".
+
+Currently three printing styles are supported. They are "printing =
+bsd", "printing = sysv", "printing = hpux" and "printing = aix".
+
+To see what the defaults are for the other print commands when using
+these three options use the "testparm" program.
+
+
+.SS printcap name (G)
+This parameter may be used to override the compiled-in default printcap
+name used by the server (usually /etc/printcap). See the discussion of the
+[printers] section above for reasons why you might want to do this.
+
+For those of you without a printcap (say on SysV) you can just create a
+minimal file that looks like a printcap and set "printcap name =" in
+[global] to point at it.
+
+A minimal printcap file would look something like this:
+
+print1|My Printer 1
+print2|My Printer 2
+print3|My Printer 3
+print4|My Printer 4
+print5|My Printer 5
+
+where the | separates aliases of a printer. The fact that the second
+alias has a space in it gives a hint to Samba that it's a comment.
+
+NOTE: Under AIX the default printcap name is "/etc/qconfig". Samba
+will assume the file is in AIX "qconfig" format if the string
+"/qconfig" appears in the printcap filename.
+
+.B Default:
+ printcap name = /etc/printcap
+
+.B Example:
+ printcap name = /etc/myprintcap
+.SS printer (S)
+A synonym for this parameter is 'printer name'.
+
+This parameter specifies the name of the printer to which print jobs spooled
+through a printable service will be sent.
+
+If specified in the [global] section, the printer name given will be used
+for any printable service that does not have its own printer name specified.
+
+.B Default:
+ none (but may be 'lp' on many systems)
+
+.B Example:
+ printer name = laserwriter
+.SS printer name (S)
+See
+.B printer.
+.SS protocol (G)
+The value of the parameter (a string) is the highest protocol level that will
+be supported by the server.
+
+Possible values are CORE, COREPLUS, LANMAN1, LANMAN2 and NT1. The relative
+merits of each are discussed in the README file.
+
+.B Default:
+ protocol = NT1
+
+.B Example:
+ protocol = LANMAN1
+.SS public (S)
+A synonym for this parameter is 'guest ok'.
+
+If this parameter is 'yes' for a service, then no password is required
+to connect to the service. Privileges will be those of the guest
+account.
+
+See the section below on user/password validation for more information about
+this option.
+
+.B Default:
+ public = no
+
+.B Example:
+ public = yes
+.SS read list (S)
+This is a list of users that are given read-only access to a
+service. If the connecting user is in this list then they will
+not be given write access, no matter what the "read only" option
+is set to. The list can include group names using the @group syntax.
+
+See also the "write list" option
+
+.B Default:
+ read list =
+
+.B Example:
+ read list = mary, @students
+
+.SS read only (S)
+See
+.B writable
+and
+.B write ok.
+Note that this is an inverted synonym for writable and write ok.
+.SS read prediction (G)
+This options enables or disables the read prediction code used to
+speed up reads from the server. When enabled the server will try to
+pre-read data from the last accessed file that was opened read-only
+while waiting for packets.
+
+.SS Default:
+ read prediction = False
+
+.SS Example:
+ read prediction = True
+.SS read raw (G)
+This parameter controls whether or not the server will support raw reads when
+transferring data to clients.
+
+If enabled, raw reads allow reads of 65535 bytes in one packet. This
+typically provides a major performance benefit.
+
+However, some clients either negotiate the allowable block size incorrectly
+or are incapable of supporting larger block sizes, and for these clients you
+may need to disable raw reads.
+
+In general this parameter should be viewed as a system tuning tool and left
+severely alone. See also
+.B write raw.
+
+.B Default:
+ read raw = yes
+
+.B Example:
+ read raw = no
+.SS read size (G)
+
+The option "read size" affects the overlap of disk reads/writes with
+network reads/writes. If the amount of data being transferred in
+several of the SMB commands (currently SMBwrite, SMBwriteX and
+SMBreadbraw) is larger than this value then the server begins writing
+the data before it has received the whole packet from the network, or
+in the case of SMBreadbraw, it begins writing to the network before
+all the data has been read from disk.
+
+This overlapping works best when the speeds of disk and network access
+are similar, having very little effect when the speed of one is much
+greater than the other.
+
+The default value is 2048, but very little experimentation has been
+done yet to determine the optimal value, and it is likely that the best
+value will vary greatly between systems anyway. A value over 65536 is
+pointless and will cause you to allocate memory unnecessarily.
+
+.B Default:
+ read size = 2048
+
+.B Example:
+ read size = 8192
+
+.SS revalidate (S)
+
+This options controls whether Samba will allow a previously validated
+username/password pair to be used to attach to a share. Thus if you
+connect to \\\\server\\share1 then to \\\\server\\share2 it won't
+automatically allow the client to request connection to the second
+share as the same username as the first without a password.
+
+If "revalidate" is True then the client will be denied automatic
+access as the same username.
+
+.B Default:
+ revalidate = False
+
+.B Example:
+ revalidate = True
+
+.SS root (G)
+See
+.B root directory.
+.SS root dir (G)
+See
+.B root directory.
+.SS root directory (G)
+Synonyms for this parameter are 'root dir' and 'root'.
+
+The server will chroot() to this directory on startup. This is not
+strictly necessary for secure operation. Even without it the server
+will deny access to files not in one of the service entries. It may
+also check for, and deny access to, soft links to other parts of the
+filesystem, or attempts to use .. in file names to access other
+directories (depending on the setting of the "wide links" parameter).
+
+Adding a "root dir" entry other than "/" adds an extra level of security,
+but at a price. It absolutely ensures that no access is given to files not
+in the sub-tree specified in the "root dir" option, *including* some files
+needed for complete operation of the server. To maintain full operability
+of the server you will need to mirror some system files into the "root dir"
+tree. In particular you will need to mirror /etc/passwd (or a subset of it),
+and any binaries or configuration files needed for printing (if required).
+The set of files that must be mirrored is operating system dependent.
+
+.B Default:
+ root directory = /
+
+.B Example:
+ root directory = /homes/smb
+.SS security (G)
+This option does affects how clients respond to Samba.
+
+The option sets the "security mode bit" in replies to protocol negotiations
+to turn share level security on or off. Clients decide based on this bit
+whether (and how) to transfer user and password information to the server.
+
+The default is "security=SHARE", mainly because that was the only
+option at one stage.
+
+The alternatives are "security = user" or "security = server".
+
+If your PCs use usernames that are the same as their usernames on the
+unix machine then you will want to use "security = user". If you
+mostly use usernames that don't exist on the unix box then use
+"security = share".
+
+There is a bug in WfWg that may affect your decision. When in user
+level security a WfWg client will totally ignore the password you type
+in the "connect drive" dialog box. This makes it very difficult (if
+not impossible) to connect to a Samba service as anyone except the
+user that you are logged into WfWg as.
+
+If you use "security = server" then Samba will try to validate the
+username/password by passing it to another SMB server, such as an NT
+box. If this fails it will revert to "security = USER".
+
+See the "password server" option for more details.
+
+.B Default:
+ security = SHARE
+
+.B Example:
+ security = USER
+.SS server string (G)
+This controls what string will show up in the printer comment box in
+print manager and next to the IPC connection in "net view". It can be
+any string that you wish to show to your users.
+
+Note that it DOES NOT affect the string that appears in browse
+lists. That is controlled by a nmbd command line option instead.
+
+A %v will be replaced with the Samba version number.
+
+A %h will be replaced with the hostname.
+
+.B Default:
+ server string = Samba %v
+
+.B Example:
+ server string = University of GNUs Samba Server
+
+.SS smbrun (G)
+This sets the full path to the smbrun binary. This defaults to the
+value in the Makefile.
+
+You must get this path right for many services to work correctly.
+
+.B Default: taken from Makefile
+
+.B Example:
+ smbrun = /usr/local/samba/bin/smbrun
+
+.SS short preserve case (S)
+
+This controls if new short filenames are created with the case that
+the client passes, or if they are forced to be the "default" case.
+
+.B Default:
+ short preserve case = no
+
+See the section on "NAME MANGLING" for a fuller discussion.
+
+.SS root preexec (S)
+
+This is the same as preexec except that the command is run as
+root. This is useful for mounting filesystems (such as cdroms) before
+a connection is finalised.
+
+.SS root postexec (S)
+
+This is the same as postexec except that the command is run as
+root. This is useful for unmounting filesystems (such as cdroms) after
+a connection is closed.
+
+.SS set directory (S)
+If 'set directory = no', then users of the service may not use the setdir
+command to change directory.
+
+The setdir comand is only implemented in the Digital Pathworks client. See the
+Pathworks documentation for details.
+.B Default:
+ set directory = no
+
+.B Example:
+ set directory = yes
+
+.SS share modes (S)
+
+This enables or disables the honouring of the "share modes" during a
+file open. These modes are used by clients to gain exclusive read or
+write access to a file.
+
+These open modes are not directly supported by unix, so they are
+simulated using lock files in the "lock directory". The "lock
+directory" specified in smb.conf must be readable by all users.
+
+The share modes that are enabled by this option are DENY_DOS,
+DENY_ALL, DENY_READ, DENY_WRITE, DENY_NONE and DENY_FCB.
+
+Enabling this option gives full share compatability but may cost a bit
+of processing time on the unix server. They are enabled by default.
+
+.B Default:
+ share modes = yes
+
+.B Example:
+ share modes = no
+
+.SS socket options (G)
+This option (which can also be invoked with the -O command line
+option) allows you to set socket options to be used when talking with
+the client.
+
+Socket options are controls on the networking layer of the operating
+systems which allow the connection to be tuned.
+
+This option will typically be used to tune your Samba server for
+optimal performance for your local network. There is no way that Samba
+can know what the optimal parameters are for your net, so you must
+experiment and choose them yourself. I strongly suggest you read the
+appropriate documentation for your operating system first (perhaps
+"man setsockopt" will help).
+
+You may find that on some systems Samba will say "Unknown socket
+option" when you supply an option. This means you either mis-typed it
+or you need to add an include file to includes.h for your OS. If the
+latter is the case please send the patch to me
+(samba-bugs@anu.edu.au).
+
+Any of the supported socket options may be combined in any way you
+like, as long as your OS allows it.
+
+This is the list of socket options currently settable using this
+option:
+
+ SO_KEEPALIVE
+
+ SO_REUSEADDR
+
+ SO_BROADCAST
+
+ TCP_NODELAY
+
+ IPTOS_LOWDELAY
+
+ IPTOS_THROUGHPUT
+
+ SO_SNDBUF *
+
+ SO_RCVBUF *
+
+ SO_SNDLOWAT *
+
+ SO_RCVLOWAT *
+
+Those marked with a * take an integer argument. The others can
+optionally take a 1 or 0 argument to enable or disable the option, by
+default they will be enabled if you don't specify 1 or 0.
+
+To specify an argument use the syntax SOME_OPTION=VALUE for example
+SO_SNDBUF=8192. Note that you must not have any spaces before or after
+the = sign.
+
+If you are on a local network then a sensible option might be
+
+socket options = IPTOS_LOWDELAY
+
+If you have an almost unloaded local network and you don't mind a lot
+of extra CPU usage in the server then you could try
+
+socket options = IPTOS_LOWDELAY TCP_NODELAY
+
+If you are on a wide area network then perhaps try setting
+IPTOS_THROUGHPUT.
+
+Note that several of the options may cause your Samba server to fail
+completely. Use these options with caution!
+
+.B Default:
+ no socket options
+
+.B Example:
+ socket options = IPTOS_LOWDELAY
+
+
+
+
+.SS status (G)
+This enables or disables logging of connections to a status file that
+smbstatus can read.
+
+With this disabled smbstatus won't be able to tell you what
+connections are active.
+
+.B Default:
+ status = yes
+
+.B Example:
+ status = no
+
+.SS strip dot (G)
+This is a boolean that controls whether to strup trailing dots off
+filenames. This helps with some CDROMs that have filenames ending in a
+single dot.
+
+NOTE: This option is now obsolete, and may be removed in future. You
+should use the "mangled map" option instead as it is much more
+general.
+
+.SS strict locking (S)
+This is a boolean that controls the handling of file locking in the
+server. When this is set to yes the server will check every read and
+write access for file locks, and deny access if locks exist. This can
+be slow on some systems.
+
+When strict locking is "no" the server does file lock checks only when
+the client explicitly asks for them.
+
+Well behaved clients always ask for lock checks when it is important,
+so in the vast majority of cases "strict locking = no" is preferable.
+
+.B Default:
+ strict locking = no
+
+.B Example:
+ strict locking = yes
+
+.SS sync always (S)
+
+This is a boolean parameter that controls whether writes will always
+be written to stable storage before the write call returns. If this is
+false then the server will be guided by the clients request in each
+write call (clients can set a bit indicating that a particular write
+should be synchronous). If this is true then every write will be
+followed by a fsync() call to ensure the data is written to disk.
+
+.B Default:
+ sync always = no
+
+.B Example:
+ sync always = yes
+
+.SS time offset (G)
+This parameter is a setting in minutes to add to the normal GMT to
+local time conversion. This is useful if you are serving a lot of PCs
+that have incorrect daylight saving time handling.
+
+.B Default:
+ time offset = 0
+
+.B Example:
+ time offset = 60
+
+.SS user (S)
+See
+.B username.
+.SS username (S)
+A synonym for this parameter is 'user'.
+
+Multiple users may be specified in a comma-delimited list, in which case the
+supplied password will be tested against each username in turn (left to right).
+
+The username= line is needed only when the PC is unable to supply it's own
+username. This is the case for the coreplus protocol or where your
+users have different WfWg usernames to unix usernames. In both these
+cases you may also be better using the \\\\server\\share%user syntax
+instead.
+
+The username= line is not a great solution in many cases as it means Samba
+will try to validate the supplied password against each of the
+usernames in the username= line in turn. This is slow and a bad idea for
+lots of users in case of duplicate passwords. You may get timeouts or
+security breaches using this parameter unwisely.
+
+Samba relies on the underlying unix security. This parameter does not
+restrict who can login, it just offers hints to the Samba server as to
+what usernames might correspond to the supplied password. Users can
+login as whoever they please and they will be able to do no more
+damage than if they started a telnet session. The daemon runs as the
+user that they log in as, so they cannot do anything that user cannot
+do.
+
+To restrict a service to a particular set of users you can use the
+"valid users=" line.
+
+If any of the usernames begin with a @ then the name will be looked up
+in the groups file and will expand to a list of all users in the group
+of that name. Note that searching though a groups file can take quite
+some time, and some clients may time out during the search.
+
+See the section below on username/password validation for more information
+on how this parameter determines access to the services.
+
+.B Default:
+ The guest account if a guest service, else the name of the service.
+
+.B Examples:
+ username = fred
+ username = fred, mary, jack, jane, @users, @pcgroup
+
+.SS username map (G)
+
+This option allows you to to specify a file containing a mapping of
+usernames from the clients to the server. This can be used for several
+purposes. The most common is to map usernames that users use on dos or
+windows machines to those that the unix box uses. The other is to map
+multiple users to a single username so that they can more easily share
+files.
+
+The map file is parsed line by line. Each line should contain a single
+unix username on the left then a '=' followed by a list of usernames
+on the right. The list of usernames on the right may contain names of
+the form @group in which case they will match any unix username in
+that group. The special client name '*' is a wildcard and matches any
+name.
+
+The file is processed on each line by taking the supplied username and
+comparing it with each username on the right hand side of the '='
+signs. If the supplied name matrches any of the names on the right
+hand side then it is replaced with the name on the left. Processing
+then continues with the next line.
+
+If any line begins with a '#' or a ';' then it is ignored
+
+For example to map from he name "admin" or "administrator" to the unix
+name "root" you would use
+
+ root = admin administrator
+
+Or to map anyone in the unix group "system" to the unix name "sys" you
+would use
+
+ sys = @system
+
+You can have as many mappings as you like in a username map file.
+
+Note that the remapping is applied to all occurances of
+usernames. Thus if you connect to "\\\\server\\fred" and "fred" is
+remapped to "mary" then you will actually be connecting to
+"\\\\server\\mary" and will need to supply a password suitable for
+"mary" not "fred". The only exception to this is the username passwed
+to the "password server" (if you have one). The password server will
+receive whatever username the client supplies without modification.
+
+Also note that no reverse mapping is done. The main effect this has is
+with printing. Users who have been mapped may have trouble deleting
+print jobs as PrintManager under WfWg will think they don't own the
+print job.
+
+.B Default
+ no username map
+
+.B Example
+ username map = /usr/local/samba/lib/users.map
+
+.SS valid chars (S)
+
+The option allows you to specify additional characters that should be
+considered valid by the server in filenames. This is particularly
+useful for national character sets, such as adding u-umlaut or a-ring.
+
+The option takes a list of characters in either integer or character
+form with spaces between them. If you give two characters with a colon
+between them then it will be taken as an lowercase:uppercase pair.
+
+If you have an editor capable of entering the characters into the
+config file then it is probably easiest to use this method. Otherwise
+you can specify the characters in octal, decimal or hexidecimal form
+using the usual C notation.
+
+For example to add the single character 'Z' to the charset (which is a
+pointless thing to do as it's already there) you could do one of the
+following
+
+valid chars = Z
+valid chars = z:Z
+valid chars = 0132:0172
+
+The last two examples above actually add two characters, and alters
+the uppercase and lowercase mappings appropriately.
+
+.B Default
+ Samba defaults to using a reasonable set of valid characters
+ for english systems
+
+.B Example
+ valid chars = 0345:0305 0366:0326 0344:0304
+
+The above example allows filenames to have the swedish characters in
+them.
+
+.SS valid users (S)
+This is a list of users that should be allowed to login to this
+service. A name starting with @ is interpreted as a unix group.
+
+If this is empty (the default) then any user can login. If a username
+is in both this list and the "invalid users" list then access is
+denied for that user.
+
+The current servicename is substituted for %S. This is useful in the
+[homes] section.
+
+See also "invalid users"
+
+.B Default
+ No valid users list. (anyone can login)
+
+.B Example
+ valid users = greg, @pcusers
+
+.SS volume (S)
+This allows you to override the volume label returned for a
+share. Useful for CDROMs whos installation programs insist on a
+particular volume label.
+
+The default is the name of the share
+
+.SS wide links (S)
+This parameter controls whether or not links in the Unix file system may be
+followed by the server. Links that point to areas within the directory tree
+exported by the server are always allowed; this parameter controls access
+only to areas that are outside the directory tree being exported.
+
+.B Default:
+ wide links = yes
+
+.B Example:
+ wide links = no
+
+.SS workgroup (G)
+
+This controls what workgroup your server will appear to be in when
+queried by clients. This can be different to the workgroup specified
+in the nmbd configuration, but it is probably best if you set them to
+the same value.
+
+.B Default:
+ set in the Makefile
+
+.B Example:
+ workgroup = MYGROUP
+
+.SS write ok (S)
+See
+.B writable
+and
+.B read only.
+.SS writable (S)
+A synonym for this parameter is 'write ok'. An inverted synonym is 'read only'.
+
+If this parameter is 'no', then users of a service may not create or modify
+files in the service's directory.
+
+Note that a printable service ('printable = yes') will ALWAYS allow
+writing to the directory (user privileges permitting), but only via
+spooling operations.
+
+.B Default:
+ writable = no
+
+.B Examples:
+ read only = no
+ writable = yes
+ write ok = yes
+.SS write list (S)
+This is a list of users that are given read-write access to a
+service. If the connecting user is in this list then they will be
+given write access, no matter what the "read only" option is set
+to. The list can include group names using the @group syntax.
+
+Note that if a user is in both the read list and the write list then
+they will be given write access.
+
+See also the "read list" option
+
+.B Default:
+ write list =
+
+.B Example:
+ write list = admin, root, @staff
+
+.SS write raw (G)
+This parameter controls whether or not the server will support raw writes when
+transferring data from clients.
+
+.B Default:
+ write raw = yes
+
+.B Example:
+ write raw = no
+.SH NOTE ABOUT USERNAME/PASSWORD VALIDATION
+There are a number of ways in which a user can connect to a
+service. The server follows the following steps in determining if it
+will allow a connection to a specified service. If all the steps fail
+then the connection request is rejected. If one of the steps pass then
+the following steps are not checked.
+
+If the service is marked "guest only = yes" then steps 1 to 5 are skipped
+
+Step 1: If the client has passed a username/password pair and that
+username/password pair is validated by the unix systems password
+programs then the connection is made as that username. Note that this
+includes the \\\\server\\service%username method of passing a username.
+
+Step 2: If the client has previously registered a username with the
+system and now supplies a correct password for that username then the
+connection is allowed.
+
+Step 3: The clients netbios name and any previously used user names
+are checked against the supplied password, if they match then the
+connection is allowed as the corresponding user.
+
+Step 4: If the client has previously validated a username/password
+pair with the server and the client has passed the validation token
+then that username is used. This step is skipped if "revalidate = yes"
+for this service.
+
+Step 5: If a "user = " field is given in the smb.conf file for the
+service and the client has supplied a password, and that password
+matches (according to the unix systems password checking) with one of
+the usernames from the user= field then the connection is made as the
+username in the "user=" line. If one of the username in the user= list
+begins with a @ then that name expands to a list of names in the group
+of the same name.
+
+Step 6: If the service is a guest service then a connection is made as
+the username given in the "guest account =" for the service,
+irrespective of the supplied password.
+
+
+.SH WARNINGS
+Although the configuration file permits service names to contain spaces,
+your client software may not. Spaces will be ignored in comparisons anyway,
+so it shouldn't be a problem - but be aware of the possibility.
+
+On a similar note, many clients - especially DOS clients - limit service
+names to eight characters. Smbd has no such limitation, but attempts
+to connect from such clients will fail if they truncate the service names.
+For this reason you should probably keep your service names down to eight
+characters in length.
+
+Use of the [homes] and [printers] special sections make life for an
+administrator easy, but the various combinations of default attributes can be
+tricky. Take extreme care when designing these sections. In particular,
+ensure that the permissions on spool directories are correct.
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the server has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+
+Prior to version 1.5.21 of the Samba suite, the configuration file was
+radically different (more primitive). If you are using a version earlier than
+1.8.05, it is STRONGLY recommended that you upgrade.
+.SH OPTIONS
+Not applicable.
+
+.SH FILES
+Not applicable.
+
+.SH ENVIRONMENT VARIABLES
+Not applicable.
+
+.SH SEE ALSO
+.B smbd(8),
+.B smbclient(1),
+.B nmbd(8),
+.B testparm(1),
+.B testprns(1),
+.B lpq(1),
+.B hosts_access(5)
+.SH DIAGNOSTICS
+[This section under construction]
+
+Most diagnostics issued by the server are logged in a specified log file. The
+log file name is specified at compile time, but may be overridden on the
+smbd (see smbd(8)) command line.
+
+The number and nature of diagnostics available depends on the debug level used
+by the server. If you have problems, set the debug level to 3 and peruse the
+log files.
+
+Most messages are reasonably self-explanatory. Unfortunately, at time of
+creation of this man page the source code is still too fluid to warrant
+describing each and every diagnostic. At this stage your best bet is still
+to grep the source code and inspect the conditions that gave rise to the
+diagnostics you are seeing.
+
+.SH BUGS
+None known.
+
+Please send bug reports, comments and so on to:
+
+.RS 3
+.B samba-bugs@anu.edu.au (Andrew Tridgell)
+
+.RS 3
+or to the mailing list
+.RE
+
+.B samba@listproc.anu.edu.au
+
+.RE
+You may also like to subscribe to the announcement channel
+
+.RS 3
+samba-announce@listproc.anu.edu.au
+.RE
+
+To subscribe to these lists send a message to
+listproc@listproc.anu.edu.au with a body of "subscribe samba Your
+Name" or "subscribe samba-announce Your Name".
+
+Errors or suggestions for improvements to the Samba man pages should be
+mailed to:
+
+.RS 3
+.B samba-bugs@anu.edu.au (Andrew Tridgell)
+.RE
+
diff --git a/docs/manpages/smbclient.1 b/docs/manpages/smbclient.1
new file mode 100644
index 0000000000..5590e01296
--- /dev/null
+++ b/docs/manpages/smbclient.1
@@ -0,0 +1,1133 @@
+.TH SMBCLIENT 1 17/1/1995 smbclient smbclient
+.SH NAME
+smbclient \- ftp-like Lan Manager client program
+.SH SYNOPSIS
+.B smbclient
+.B servicename
+[
+.B password
+] [
+.B -A
+] [
+.B -E
+] [
+.B -L
+.I host
+] [
+.B -M
+.I host
+] [
+.B -I
+.I IP number
+] [
+.B -N
+] [
+.B -P
+] [
+.B -U
+.I username
+] [
+.B -d
+.I debuglevel
+] [
+.B -l
+.I log basename
+] [
+.B -n
+.I netbios name
+] [
+.B -O
+.I socket options
+] [
+.B -p
+.I port number
+.B -T
+.I tar options
+.B -D
+.I initial directory
+]
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B smbclient
+is a client that can 'talk' to a Lan Manager server. It offers
+an interface similar to that of the
+.B ftp
+program (see
+.B ftp(1)). Operations include things like getting files from the
+server to the local machine, putting files from the local machine to
+the server, retrieving directory information from the server and so on.
+
+.SH OPTIONS
+.B servicename
+.RS 3
+.B servicename
+is the name of the service you want to use on the server. A service
+name takes the form
+.B "\\\\\\\\server\\\\service"
+where
+.B server
+is the netbios name of the Lan Manager server offering the desired service and
+.B service
+is the name of the service offered. Thus to connect to the service "printer"
+on the Lan Manager server "lanman", you would use the servicename
+
+.RS 10
+.B "\\\\\\\\lanman\\\\printer"
+.RE
+
+Note that the server name required is NOT necessarily the host name of the
+server! The name required is a Lan Manager server name, which may or may not
+be the same as the hostname of the machine running the server.
+.RE
+
+.B password
+.RS 3
+.B
+password
+is the password required to access the specified service on the
+specified server. If supplied, the
+.B -N
+option (suppress password prompt) is assumed.
+
+There is no default password. If no password is supplied on the command line
+(either here or using the
+.B -U
+option (see below)) and
+.B -N
+is not specified, the client will prompt for a password, even if the desired
+service does not require one. (If prompted for a password and none is
+required, simply press ENTER to provide a null password.)
+
+Note: Some servers (including OS/2 and Windows for Workgroups) insist
+on an uppercase password. Lowercase or mixed case passwords may be
+rejected by these servers.
+
+Be cautious about including passwords in scripts.
+.RE
+
+.B -A
+
+.RS 3
+This parameter, if specified, causes the maximum debug level to be selected.
+Be warned that this generates prodigious amounts of debug data. There is also
+a security issue involved, as at the maximum debug level cleartext passwords
+may be written to some log files.
+.RE
+
+.B -L
+
+.RS 3
+This option allows you to look at what services are available on a
+server. You use it as "smbclient -L host" and a list should appear.
+The -I option may be useful if your netbios names don't match your
+tcp/ip host names or if you are trying to reach a host on another
+network. For example:
+
+smbclient -L ftp -I ftp.microsoft.com
+
+will list the shares available on microsofts public server.
+.RE
+
+.B -M
+
+.RS 3
+This options allows you to send messages, using the "WinPopup"
+protocol, to another computer. Once a connection is established you
+then type your message, pressing ^D (control-D) to end.
+
+If the receiving computer is running WinPopup the user will receive
+the message and probably a beep. If they are not running WinPopup the
+message will be lost, and no error message will occur.
+
+The message is also automatically truncated if the message is over
+1600 bytes, as this is the limit of the protocol.
+
+One useful trick is to cat the message through smbclient. For example:
+
+cat mymessage.txt | smbclient -M FRED
+
+will send the message in the file "mymessage.txt" to the machine FRED.
+
+You may also find the -U and -I options useful, as they allow you to
+control the FROM and TO parts of the message.
+
+Samba currently has no way of receiving WinPopup messages.
+
+Note: Copy WinPopup into the startup group on your WfWg PCs if you
+want them to always be able to receive messages.
+.RE
+
+.B -E
+
+.RS 3
+This parameter, if specified, causes the client to write messages to the
+standard error stream (stderr) rather than to the standard output stream.
+
+By default, the client writes messages to standard output - typically the
+user's tty.
+.RE
+
+.B -I
+.I IP number
+
+.RS 3
+.I IP number
+represents the IP number of the server to connect to. It should
+be specified in standard "a.b.c.d" notation.
+
+Normally the client will attempt to locate the specified Lan Manager server
+by looking it up - that is, broadcasting a request for the given server to
+identify itself. Using this parameter will force the client to assume that
+the server is on the machine with the specified IP number.
+
+There is no default for this parameter. If not supplied, it will be determined
+automatically by the client as described above.
+.RE
+
+.B -N
+
+.RS 3
+If specified, this parameter suppresses the normal password prompt from the
+client to the user. This is useful when accessing a service that does not
+require a password.
+
+Unless a password is specified on the command line or this parameter is
+specified, the client will request a password.
+.RE
+
+.B -O
+.I socket options
+.RS 3
+
+See the socket options section of smb.conf(5) for details
+
+.RE
+.B -P
+
+.RS 3
+If specified, the service requested will be connected to as a printer service
+rather than as a normal filespace service. Operations such as put and get
+will not be applicable for such a connection.
+
+By default, services will be connected to as NON-printer services.
+.RE
+
+.B -U
+.I username
+
+.RS 3
+.I username
+is the user name that will be used by the client to make a connection,
+assuming your server is running a protocol that allows for usernames.
+
+Some servers are fussy about the case of this name, and some insist
+that it must be a valid netbios name.
+
+If no
+.I username
+is supplied, it will default to an uppercase version of the
+environment variable
+.B USER
+or
+.B LOGNAME
+in that order.
+If no
+.I username
+is supplied and neither environment variable exists the user name will
+be empty.
+
+If the service you are connecting to requires a password, it can be supplied
+using the
+.B -U
+option, by appending a percent symbol ("%") then the password to
+.I username.
+For example, to attach to a service as user "fred" with password "secret", you
+would specify
+.B -U
+.I fred%secret
+on the command line. Note that there are no spaces around the percent symbol.
+
+If you specify the password as part of
+.I username
+then the
+.B -N
+option (suppress password prompt) is assumed.
+
+If you specify the password as a parameter AND as part of
+.I username
+then the password as part of
+.I username
+will take precedence. Putting nothing before or nothing after the percent
+symbol will cause an empty username or an empty password to be used,
+respectively.
+
+Note: Some servers (including OS/2 and Windows for Workgroups) insist
+on an uppercase password. Lowercase or mixed case passwords may be
+rejected by these servers.
+
+Be cautious about including passwords in scripts.
+.RE
+
+.B -d
+.I debuglevel
+.RS 3
+
+debuglevel is an integer from 0 to 5.
+
+The default value if this parameter is not specified is zero.
+
+The higher this value, the more detail will be logged to the log files about
+the activities of the client. At level 0, only critical errors and serious
+warnings will be logged. Level 1 is a reasonable level for day to day running
+- it generates a small amount of information about operations carried out.
+
+Levels above 1 will generate considerable amounts of log data, and should
+only be used when investigating a problem. Levels above 3 are designed for
+use only by developers and generate HUGE amounts of log data, most of which
+is extremely cryptic.
+.RE
+
+.B -l
+.I log basename
+
+.RS 3
+If specified,
+.I log basename
+specifies a base filename into which operational data from the running client
+will be logged.
+
+The default base name is specified at compile time.
+
+The base name is used to generate actual log file names. For example, if the
+name specified was "log", the following files would be used for log data:
+
+.RS 3
+log.client.debug (containing debugging information)
+
+log.client.in (containing inbound transaction data)
+
+log.client.out (containing outbound transaction data)
+.RE
+
+The log files generated are never removed by the client.
+.RE
+.RE
+
+.B -n
+.I netbios name
+
+.RS 3
+By default, the client will use the local machine's hostname (in
+uppercase) as its netbios name. This parameter allows you to override
+the host name and use whatever netbios name you wish.
+.RE
+
+.B -p
+.I port number
+.RS 3
+
+port number is a positive integer value.
+
+The default value if this parameter is not specified is 139.
+
+This number is the port number that will be used when making connections to
+the server. The standard (well-known) port number for the server is 139,
+hence the default.
+
+This parameter is not normally specified.
+
+.B -T
+.I tar options
+.RS3
+
+where tar options are one or more of c,x,I,X,b,g,N or a; used as:
+.LP
+smbclient
+.B "\\\\\\\\server\\\\share"
+\-TcxIXbgNa
+[
+.IR blocksize
+]
+[
+.IR newer-file
+]
+.IR tarfile
+[
+.IR filenames....
+]
+
+.RS3
+.B c
+Create a tar file on UNIX. Must be followed by the name of a tar file,
+tape device or "-" for standard output. (May be useful to set debugging
+low (-d0)) to avoid corrupting your tar file if using "-"). Mutually
+exclusive with the x flag.
+
+.B x
+Extract (restore) a local tar file back to a share. Unless the -D
+option is given, the tar files will be restored from the top level of
+the share. Must be followed by the name of the tar file, device or "-"
+for standard input. Mutually exclusive with the c flag.
+
+.B I
+Include files and directories. Is the default behaviour when
+.IR filenames
+are specified above. Causes tar files to be included in an extract or create
+(and therefore everything else to be excluded). See example below.
+Filename globbing does not work for included files for extractions (yet).
+
+.B X
+Exclude files and directories. Causes tar files to be excluded from
+an extract or create. See example below.
+Filename globbing does not work for excluded files (yet).
+
+.B b
+Blocksize. Must be followed by a valid (greater than zero) blocksize.
+Causes tar file to be written out in blocksize*TBLOCK (usually 512 byte)
+blocks.
+
+.B g
+Incremental. Only back up files that have the archive bit set. Useful
+only with the c flag.
+
+.B N
+Newer than. Must be followed by the name of a file whose date is
+compared against files found on the share during a create. Only files
+newer than the file specified are backed up to the tar file. Useful
+only with the c flag.
+
+.B a
+Set archive bit. Causes the archive bit to be reset when a file is backed
+up. Useful with the g (and c) flags.
+.LP
+
+.B Examples
+
+smbclient \\\\mypc\\myshare "" -N -Tx backup.tar
+
+Restore from tar file backup.tar into myshare on mypc (no password on share).
+
+smbclient \\\\mypc\\myshare "" -N -TXx backup.tar users/docs
+
+Restore everything except users/docs
+
+smbclient \\\\mypc\\myshare "" -N -Tc backup.tar users/docs
+
+Create a tar file of the files beneath users/docs.
+
+.RE
+
+.B -D
+.I initial directory
+
+.RS3
+
+Change to initial directory before starting. Probably only of any use
+with the tar (\-T) option.
+
+
+.RE
+
+.SH OPERATIONS
+Once the client is running, the user is presented with a prompt, "smb: \\>".
+The backslash ("\\") indicates the current working directory on the server,
+and will change if the current working directory is changed.
+
+The prompt indicates that the client is ready and waiting to carry out a user
+command. Each command is a single word, optionally followed by parameters
+specific to that command. Command and parameters are space-delimited unless
+these notes specifically state otherwise. All commands are case-insensitive.
+Parameters to commands may or may not be case sensitive, depending on the
+command.
+
+You can specify file names which have spaces in them by quoting the
+name with double quotes, for example "a long file name".
+
+Parameters shown in square brackets (eg., "[parameter]") are optional. If not
+given, the command will use suitable defaults. Parameters shown in angle
+brackets (eg., "<parameter>") are required.
+
+Note that all commands operating on the server are actually performed by
+issuing a request to the server. Thus the behaviour may vary from server to
+server, depending on how the server was implemented.
+
+The commands available are given here in alphabetical order.
+
+.B ?
+.RS 3
+.B Parameters:
+.RS 3
+.I [command]
+
+.RE
+.B Description:
+.RS 3
+If
+.I command
+is specified, the
+.B ?
+command will display a brief informative message about the specified command.
+
+If no command is specified, a list of available commands will be displayed.
+.RE
+.RE
+
+.B !
+.RS 3
+.B Parameters:
+.RS 3
+.I [shell command]
+
+.RE
+.B Description:
+.RS 3
+If
+.I shell command
+is specified, the
+.B !
+command will execute a shell locally and run the specified shell command. If
+no command is specified, a shell will be run.
+.RE
+.RE
+
+.B cd
+.RS 3
+.B Parameters:
+.RS 3
+.I [directory name]
+
+.RE
+.B Description:
+.RS 3
+If
+.I directory name
+is specified, the current working directory
+.B on the server
+will be changed to the directory specified. This operation will fail if for
+any reason the specified directory is inaccessible.
+
+If no directory name is specified, the current working directory
+.B on the server
+will be reported.
+.RE
+.RE
+
+.B del
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+The client will request that the server attempt to delete all files matching
+.I mask
+from the current working directory
+.B on the server.
+.RE
+.RE
+
+.B dir
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+A list of the files matching
+.I mask
+in the current working directory
+.B on the server
+will be retrieved from the server and displayed.
+.RE
+.RE
+
+.B exit
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+Terminate the connection with the server and exit from the program.
+.RE
+.RE
+
+.B get
+.RS 3
+.B Parameters:
+.RS 3
+.I <remote file name> [local file name]
+
+.RE
+.B Description:
+.RS 3
+Copy the file called
+.I remote file name
+from the server to the machine running the client. If specified, name the
+local copy
+.I local file name.
+Note that all transfers in smbclient are binary. See also the
+.B lowercase
+command.
+.RE
+.RE
+
+.B help
+.RS 3
+.B Parameters:
+.RS 3
+.I [command]
+
+.RE
+.B Description:
+.RS 3
+See the
+.B ?
+command above.
+.RE
+.RE
+
+.B lcd
+.RS 3
+.B Parameters:
+.RS 3
+.I [directory name]
+
+.RE
+.B Description:
+.RS 3
+If
+.I directory name
+is specified, the current working directory
+.B on the local machine
+will be changed to the directory specified. This operation will fail if for
+any reason the specified directory is inaccessible.
+
+If no directory name is specified, the name of the current working directory
+.B on the local machine
+will be reported.
+.RE
+.RE
+
+.B lowercase
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+Toggle lowercasing of filenames for the
+.B get
+and
+.B mget
+commands.
+
+When lowercasing is toggled ON, local filenames are converted to lowercase
+when using the
+.B get
+and
+.B mget
+commands. This is often useful when copying (say) MSDOS files from a server,
+because lowercase filenames are the norm on Unix systems.
+.RE
+.RE
+
+.B ls
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+See the
+.B dir
+command above.
+.RE
+.RE
+
+.B mask
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+This command allows the user to set up a mask which will be used during
+recursive operation of the
+.B mget
+and
+.B mput
+commands.
+
+The masks specified to the
+.B mget
+and
+.B mput
+commands act as filters for directories
+rather than files when recursion is toggled ON.
+
+The mask specified with the
+.B mask
+command is necessary to filter files within those directories. For example,
+if the mask specified in an
+.B mget
+command is "source*"
+.I and
+the mask specified with the
+.B mask
+command is "*.c"
+.I and
+recursion is toggled ON, the
+.B mget
+command will retrieve all files matching "*.c" in all directories below
+and including all directories matching "source*" in the current working
+directory.
+
+Note that the value for
+.I mask
+defaults to blank (equivalent to "*") and remains so until the
+.B mask
+command is used to change it. It retains the most recently specified value
+indefinitely. To avoid unexpected results it would be wise to change the
+value of
+.I mask
+back to "*" after using the
+.B mget
+or
+.B mput
+commands.
+.RE
+.RE
+
+.B md
+.RS 3
+.B Parameters:
+.RS 3
+.I <directory name>
+
+.RE
+.B Description:
+.RS 3
+See the
+.B mkdir
+command.
+.RE
+.RE
+
+.B mget
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+Copy all files matching
+.I mask
+from the server to the machine running the client.
+
+Note that
+.I mask
+is interpreted differently during recursive operation and non-recursive
+operation - refer to the
+.B recurse
+and
+.B mask
+commands for more information. Note that all transfers in smbclient are
+binary. See also the
+.B lowercase
+command.
+.RE
+.RE
+
+.B mkdir
+.RS 3
+.B Parameters:
+.RS 3
+.I <directory name>
+
+.RE
+.B Description:
+.RS 3
+Create a new directory
+.B on the server
+(user access privileges permitting) with the specified name.
+.RE
+.RE
+
+.B mput
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+Copy all files matching
+.I mask
+in the current working directory
+.B on the local machine
+to the current working directory on the server.
+
+Note that
+.I mask
+is interpreted differently during recursive operation and non-recursive
+operation - refer to the
+.B recurse
+and
+.B mask
+commands for more information. Note that all transfers in smbclient are
+binary.
+.RE
+.RE
+
+.B print
+.RS 3
+.B Parameters:
+.RS 3
+.I <file name>
+
+.RE
+.B Description:
+.RS 3
+Print the specified file
+.B from the local machine
+through a printable service on the server.
+
+See also the
+.B printmode
+command.
+.RE
+.RE
+
+.B printmode
+.RS 3
+.B Parameters:
+.RS 3
+.I <graphics or text>
+
+.RE
+.B Description:
+.RS 3
+Set the print mode to suit either binary data (such as graphical information)
+or text. Subsequent
+.B print
+commands will use the currently set print mode.
+.RE
+.RE
+
+.B prompt
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+Toggle prompting for filenames during operation of the
+.B mget
+and
+.B mput
+commands.
+
+When toggled ON, the user will be prompted to confirm the transfer of each
+file during these commands. When toggled OFF, all specified files will be
+transferred without prompting.
+.RE
+.RE
+
+.B put
+.RS 3
+.B Parameters:
+.RS 3
+.I <local file name> [remote file name]
+
+.RE
+.B Description:
+.RS 3
+Copy the file called
+.I local file name
+from the machine running the client to the server. If specified, name the
+remote copy
+.I remote file name.
+Note that all transfers in smbclient are binary. See also the
+.B lowercase
+command.
+.RE
+.RE
+
+.B queue
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+Displays the print queue, showing the job id, name, size and current status.
+.RE
+.RE
+
+.B quit
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+See the
+.B exit
+command.
+.RE
+.RE
+
+.B rd
+.RS 3
+.B Parameters:
+.RS 3
+.I <directory name>
+
+.RE
+.B Description:
+.RS 3
+See the
+.B rmdir
+command.
+.RE
+.RE
+
+.B recurse
+.RS 3
+.B Parameters:
+.RS 3
+None.
+
+.RE
+.B Description:
+.RS 3
+Toggle directory recursion for the commands
+.B mget
+and
+.B mput
+.
+
+When toggled ON, these commands will process all directories in the source
+directory (ie., the directory they are copying
+.I from
+) and will recurse into any that match the mask specified to the command. Only
+files that match the mask specified using the
+.B mask
+command will be retrieved. See also the
+.mask
+command.
+
+When recursion is toggled OFF, only files from the current working
+directory on the source machine that match the mask specified to the
+.B mget
+or
+.B mput
+commands will be copied, and any mask specified using the
+.B mask
+command will be ignored.
+.RE
+.RE
+
+.B rm
+.RS 3
+.B Parameters:
+.RS 3
+.I <mask>
+
+.RE
+.B Description:
+.RS 3
+Remove all files matching
+.I mask
+from the current working directory
+.B on the server.
+.RE
+.RE
+
+.B rmdir
+.RS 3
+.B Parameters:
+.RS 3
+.I <directory name>
+
+.RE
+.B Description:
+.RS 3
+Remove the specified directory (user access privileges permitting)
+.B from the server.
+.RE
+.RE
+
+.B tar
+.RS 3
+.B Parameters:
+.RS 3
+.I <c|x>[IXbgNa]
+
+.RE
+.B Description:
+.RS 3
+Performs a tar operation - see -T command line option above. Behaviour
+may be affected by the
+.B tarmode
+command (see below). Using the g (incremental) and N (newer) will affect
+tarmode settings. Note that using the "-" option with tar x may not
+work - use the command line option instead.
+.RE
+.RE
+
+.B blocksize
+.RS 3
+.B Parameters
+.RS 3
+.I <blocksize>
+
+.RE
+.B Description
+.RS 3
+Blocksize. Must be followed by a valid (greater than zero) blocksize.
+Causes tar file to be written out in blocksize*TBLOCK (usually 512 byte)
+blocks.
+.RE
+.RE
+
+.B tarmode
+.RS 3
+.B Parameters
+.RS 3
+.I <full|inc|reset|noreset>
+
+.RE
+.B Description
+.RS 3
+Changes tar's behaviour with regard to archive bits. In full mode,
+tar will back up everything regardless of the archive bit setting (this
+is the default mode). In incremental mode, tar will only back up files
+with the archive bit set. In reset mode, tar will reset the archive bit
+on all files it backs up (implies read/write share).
+.RE
+.RE
+
+.B setmode
+.RS 3
+.B Parameters
+.RS 3
+.I <filename> <perm=[+|-]rsha>
+
+.RE
+.B Description
+.RS 3
+A version of the DOS attrib command to set file permissions. For example,
+
+setmode myfile +r
+
+would make myfile read only.
+.RE
+.RE
+
+.SH NOTES
+Some servers are fussy about the case of supplied usernames, passwords, share
+names (aka service names) and machine names. If you fail to connect try
+giving all parameters in uppercase.
+
+It is often necessary to use the
+.B -n
+option when connecting to some types
+of servers. For example OS/2 LanManager insists on a valid netbios name
+being used, so you need to supply a valid name that would be known to
+the server.
+
+.B smbclient
+supports long file names where the server supports the LANMAN2
+protocol.
+
+.SH FILES
+Not applicable.
+
+.SH ENVIRONMENT VARIABLES
+.B USER
+.RS 3
+The variable USER may contain the username of the person using the client.
+This information is used only if the protocol level is high enough to support
+session-level passwords.
+.RE
+
+.SH INSTALLATION
+The location of the client program is a matter for individual system
+administrators. The following are thus suggestions only.
+
+It is recommended that the client software be installed under the /usr/local
+hierarchy, in a directory readable by all, writeable only by root. The client
+program itself should be executable by all. The client should NOT be setuid
+or setgid!
+
+The client log files should be put in a directory readable and writable only
+by the user.
+
+To test the client, you will need to know the name of a running Lan manager
+server. It is possible to run the smbd (see
+.B smbd(8)) as an ordinary user - running that server as a daemon on a
+user-accessible port (typically any port number over 1024) would
+provide a suitable test server.
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the client software, so it is possible that your version of
+the client has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B smbd(8)
+
+.SH DIAGNOSTICS
+[This section under construction]
+
+Most diagnostics issued by the client are logged in a specified log file. The
+log file name is specified at compile time, but may be overridden on the
+command line.
+
+The number and nature of diagnostics available depends on the debug level used
+by the client. If you have problems, set the debug level to 3 and peruse the
+log files.
+
+Most messages are reasonably self-explanatory. Unfortunately, at time of
+creation of this man page the source code is still too fluid to warrant
+describing each and every diagnostic. At this stage your best bet is still
+to grep the source code and inspect the conditions that gave rise to the
+diagnostics you are seeing.
+
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+This man page written by Karl Auer (Karl.Auer@anu.edu.au)
+
+See
+.B smb.conf(5) for a full list of contributors and details on how to
+submit bug reports, comments etc.
diff --git a/docs/manpages/smbd.8 b/docs/manpages/smbd.8
new file mode 100644
index 0000000000..bae41b2c47
--- /dev/null
+++ b/docs/manpages/smbd.8
@@ -0,0 +1,407 @@
+.TH SMBD 8 17/1/1995 smbd smbd
+.SH NAME
+smbd \- provide SMB (aka LanManager) services to clients
+.SH SYNOPSIS
+.B smbd
+[
+.B -D
+] [
+.B -a
+] [
+.B -d
+.I debuglevel
+] [
+.B -l
+.I log file
+] [
+.B -p
+.I port number
+] [
+.B -O
+.I socket options
+] [
+.B -s
+.I configuration file
+]
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B smbd
+is a server that can provide most SMB services. The
+server provides filespace and printer services to clients using the SMB
+protocol. This is compatible with the LanManager protocol, and can
+service LanManager clients.
+
+An extensive description of the services that the server can provide is given
+in the man page for the configuration file controlling the attributes of those
+services (see
+.B smb.conf(5)). This man page will not describe the services, but
+will concentrate on the administrative aspects of running the server.
+
+Please note that there are significant security implications to running this
+server, and
+.B smb.conf(5) should be regarded as mandatory reading before proceeding with
+installation.
+
+A session is created whenever a client requests one. Each client gets a copy
+of the server for each session. This copy then services all connections made
+by the client during that session. When all connections from its client are
+are closed, the copy of the server for that client terminates.
+
+The configuration file is automatically reloaded if it changes. You
+can force a reload by sending a SIGHUP to the server.
+
+.SH OPTIONS
+.B -D
+
+.RS 3
+If specified, this parameter causes the server to operate as a daemon. That is,
+it detaches itself and runs in the background, fielding requests on the
+appropriate port.
+
+By default, the server will NOT operate as a daemon.
+.RE
+
+.B -a
+
+.RS 3
+If this parameter is specified, the log files will be overwritten with each
+new connection. By default, the log files will be appended to.
+.RE
+
+.B -d
+.I debuglevel
+.RS 3
+
+debuglevel is an integer from 0 to 5.
+
+The default value if this parameter is not specified is zero.
+
+The higher this value, the more detail will be logged to the log files about
+the activities of the server. At level 0, only critical errors and serious
+warnings will be logged. Level 1 is a reasonable level for day to day running
+- it generates a small amount of information about operations carried out.
+
+Levels above 1 will generate considerable amounts of log data, and should
+only be used when investigating a problem. Levels above 3 are designed for
+use only by developers and generate HUGE amounts of log data, most of which
+is extremely cryptic.
+.RE
+
+.B -l
+.I log file
+
+.RS 3
+If specified,
+.I logfile
+specifies a base filename into which operational data from the running server
+will be logged.
+
+The default base name is specified at compile time.
+
+The base name is used to generate actual log file names. For example, if the
+name specified was "log", the following files would be used for log data:
+
+.RS 3
+log.debug (containing debugging information)
+
+log.in (containing inbound transaction data)
+
+log.out (containing outbound transaction data)
+.RE
+
+The log files generated are never removed by the server.
+.RE
+
+.B -O
+.I socket options
+.RS 3
+
+See the socket options section of smb.conf(5) for details
+
+.RE
+.B -p
+.I port number
+.RS 3
+
+port number is a positive integer value.
+
+The default value if this parameter is not specified is 139.
+
+This number is the port number that will be used when making connections to
+the server from client software. The standard (well-known) port number for the
+server is 139, hence the default. If you wish to run the server as an ordinary
+user rather than as root, most systems will require you to use a port number
+greater than 1024 - ask your system administrator for help if you are in this
+situation.
+
+This parameter is not normally specified except in the above situation.
+.RE
+
+.B -s
+.I configuration file
+
+.RS 3
+The default configuration file name is determined at compile time.
+
+The file specified contains the configuration details required by the server.
+The information in this file includes server-specific information such as
+what printcap file to use, as well as descriptions of all the services that the
+server is to provide. See
+.B smb.conf(5) for more information.
+.RE
+
+.SH FILES
+
+.B /etc/inetd.conf
+
+.RS 3
+If the server is to be run by the inetd meta-daemon, this file must contain
+suitable startup information for the meta-daemon. See the section
+"INSTALLATION" below.
+.RE
+
+.B /etc/rc
+
+.RS 3
+(or whatever initialisation script your system uses)
+
+If running the server as a daemon at startup, this file will need to contain
+an appropriate startup sequence for the server. See the section "INSTALLATION"
+below.
+.RE
+
+.B /etc/services
+
+.RS 3
+If running the server via the meta-daemon inetd, this file must contain a
+mapping of service name (eg., netbios-ssn) to service port (eg., 139) and
+protocol type (eg., tcp). See the section "INSTALLATION" below.
+.RE
+
+.B /usr/local/smb/smb.conf
+
+.RS 3
+This file describes all the services the server is to make available to
+clients. See
+.B smb.conf(5) for more information.
+.RE
+.RE
+
+.SH LIMITATIONS
+
+On some systems smbd cannot change uid back to root after a setuid() call.
+Such systems are called "trapdoor" uid systems. If you have such a system,
+you will be unable to connect from a client (such as a PC) as two different
+users at once. Attempts to connect the second user will result in "access
+denied" or similar.
+
+.SH ENVIRONMENT VARIABLES
+
+.B PRINTER
+
+.RS 3
+If no printer name is specified to printable services, most systems will
+use the value of this variable (or "lp" if this variable is not defined)
+as the name of the printer to use. This is not specific to the server,
+however.
+.RE
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the server software be installed under the
+/usr/local hierarchy, in a directory readable by all, writeable only
+by root. The server program itself should be executable by all, as
+users may wish to run the server themselves (in which case it will of
+course run with their privileges). The server should NOT be
+setuid. On some systems it may be worthwhile to make smbd setgid to an
+empty group. This is because some systems may have a security hole where
+daemon processes that become a user can be attached to with a
+debugger. Making the smbd file setgid to an empty group may prevent
+this hole from being exploited. This secrity hole and the suggested
+fix has only been confirmed on Linux at the time this was written. It
+is possible that this hole only exists in Linux, as testing on other
+systems has thus far shown them to be immune.
+
+The server log files should be put in a directory readable and writable only
+by root, as the log files may contain sensitive information.
+
+The configuration file should be placed in a directory readable and writable
+only by root, as the configuration file controls security for the services
+offered by the server. The configuration file can be made readable by all if
+desired, but this is not necessary for correct operation of the server and
+is not recommended. A sample configuration file "smb.conf.sample" is supplied
+with the source to the server - this may be renamed to "smb.conf" and
+modified to suit your needs.
+
+The remaining notes will assume the following:
+
+.RS 3
+smbd (the server program) installed in /usr/local/smb
+
+smb.conf (the configuration file) installed in /usr/local/smb
+
+log files stored in /var/adm/smblogs
+.RE
+
+The server may be run either as a daemon by users or at startup, or it may
+be run from a meta-daemon such as inetd upon request. If run as a daemon, the
+server will always be ready, so starting sessions will be faster. If run from
+a meta-daemon some memory will be saved and utilities such as the tcpd
+TCP-wrapper may be used for extra security.
+
+When you've decided, continue with either "RUNNING THE SERVER AS A DAEMON" or
+"RUNNING THE SERVER ON REQUEST".
+.SH RUNNING THE SERVER AS A DAEMON
+To run the server as a daemon from the command line, simply put the "-D" option
+on the command line. There is no need to place an ampersand at the end of the
+command line - the "-D" option causes the server to detach itself from the
+tty anyway.
+
+Any user can run the server as a daemon (execute permissions permitting, of
+course). This is useful for testing purposes, and may even be useful as a
+temporary substitute for something like ftp. When run this way, however, the
+server will only have the privileges of the user who ran it.
+
+To ensure that the server is run as a daemon whenever the machine is started,
+and to ensure that it runs as root so that it can serve multiple clients, you
+will need to modify the system startup files. Wherever appropriate (for
+example, in /etc/rc), insert the following line, substituting
+port number, log file location, configuration file location and debug level as
+desired:
+
+.RS 3
+/usr/local/smb/smbd -D -l /var/adm/smblogs/log -s /usr/local/smb/smb.conf
+.RE
+
+(The above should appear in your initialisation script as a single line.
+Depending on your terminal characteristics, it may not appear that way in
+this man page. If the above appears as more than one line, please treat any
+newlines or indentation as a single space or TAB character.)
+
+If the options used at compile time are appropriate for your system, all
+parameters except the desired debug level and "-D" may be omitted. See the
+section "OPTIONS" above.
+.SH RUNNING THE SERVER ON REQUEST
+If your system uses a meta-daemon such as inetd, you can arrange to have the
+smbd server started whenever a process attempts to connect to it. This requires
+several changes to the startup files on the host machine. If you are
+experimenting as an ordinary user rather than as root, you will need the
+assistance of your system administrator to modify the system files.
+
+You will probably want to set up the name server
+.B nmbd
+at the same time as
+the smbd - refer to the man page
+.B nmbd(8).
+
+First, ensure that a port is configured in the file /etc/services. The
+well-known port 139 should be used if possible, though any port may be used.
+
+Ensure that a line similar to the following is in /etc/services:
+
+.RS 3
+netbios-ssn 139/tcp
+.RE
+
+Note for NIS/YP users - you may need to rebuild the NIS service maps rather
+than alter your local /etc/services file.
+
+Next, put a suitable line in the file /etc/inetd.conf (in the unlikely event
+that you are using a meta-daemon other than inetd, you are on your own). Note
+that the first item in this line matches the service name in /etc/services.
+Substitute appropriate values for your system in this line (see
+.B inetd(8)):
+
+.RS 3
+netbios-ssn stream tcp nowait root /usr/local/smb/smbd -d1
+-l/var/adm/smblogs/log -s/usr/local/smb/smb.conf
+.RE
+
+(The above should appear in /etc/inetd.conf as a single line. Depending on
+your terminal characteristics, it may not appear that way in this man page.
+If the above appears as more than one line, please treat any newlines or
+indentation as a single space or TAB character.)
+
+Note that there is no need to specify a port number here, even if you are
+using a non-standard port number.
+
+Lastly, edit the configuration file to provide suitable services. To start
+with, the following two services should be all you need:
+
+.RS 3
+[homes]
+.RS 3
+ writable = yes
+.RE
+
+[printers]
+.RS 3
+ writable = no
+ printable = yes
+ path = /tmp
+ public = yes
+.RE
+.RE
+
+This will allow you to connect to your home directory and print to any printer
+supported by the host (user privileges permitting).
+.SH TESTING THE INSTALLATION
+If running the server as a daemon, execute it before proceeding. If
+using a meta-daemon, either restart the system or kill and restart the
+meta-daemon. Some versions of inetd will reread their configuration tables if
+they receive a HUP signal.
+
+If your machine's name is "fred" and your name is "mary", you should now be
+able to connect to the service "\\\\fred\\mary".
+
+To properly test and experiment with the server, we recommend using the
+smbclient program (see
+.B smbclient(1)).
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the server has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B hosts_access(5),
+.B inetd(8),
+.B nmbd(8),
+.B smb.conf(5),
+.B smbclient(1),
+.B testparm(1),
+.B testprns(1)
+
+.SH DIAGNOSTICS
+[This section under construction]
+
+Most diagnostics issued by the server are logged in a specified log file. The
+log file name is specified at compile time, but may be overridden on the
+command line.
+
+The number and nature of diagnostics available depends on the debug level used
+by the server. If you have problems, set the debug level to 3 and peruse the
+log files.
+
+Most messages are reasonably self-explanatory. Unfortunately, at time of
+creation of this man page the source code is still too fluid to warrant
+describing each and every diagnostic. At this stage your best bet is still
+to grep the source code and inspect the conditions that gave rise to the
+diagnostics you are seeing.
+
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+This man page written by Karl Auer (Karl.Auer@anu.edu.au)
+
+See
+.B smb.conf(5) for a full list of contributors and details on how to
+submit bug reports, comments etc.
diff --git a/docs/manpages/smbrun.1 b/docs/manpages/smbrun.1
new file mode 100644
index 0000000000..1608d3bb34
--- /dev/null
+++ b/docs/manpages/smbrun.1
@@ -0,0 +1,70 @@
+.TH SMBRUN 1 17/1/1995 smbrun smbrun
+.SH NAME
+smbrun \- interface program between smbd and external programs
+.SH SYNOPSIS
+.B smbrun
+.I shell-command
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B smbrun
+is a very small 'glue' program, which runs shell commands for
+the
+.B smbd
+daemon (see
+.B smbd(8)).
+
+It first changes to the highest effective user and group ID that it can,
+then runs the command line provided using the system() call. This program is
+necessary to allow some operating systems to run external programs as non-root.
+.SH OPTIONS
+.I shell-command
+
+.RS 3
+The shell command to execute.
+
+The command should have a fully-qualified path.
+.RE
+.SH ENVIRONMENT VARIABLES
+The PATH variable set for the environment in which
+.B smbrun
+is executed will affect what executables are located and executed if a
+fully-qualified path is not given in the command.
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the
+.B smbrun
+program be installed under the /usr/local hierarchy, in a directory readable
+by all, writeable only by root. The program should be executable by all.
+The program should NOT be setuid or setgid!
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the program has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B smbd(8),
+.B smb.conf(8)
+.SH DIAGNOSTICS
+If smbrun cannot be located or cannot be executed by
+.B smbd
+then appropriate messages will be found in the smbd logs. Other diagnostics are
+dependent on the shell-command being run. It is advisable for your shell
+commands to issue suitable diagnostics to aid trouble-shooting.
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+This man page was written by Karl Auer (Karl.Auer@anu.edu.au)
+
+See
+.B smb.conf(5) for a full list of contributors and details of how to
+submit bug reports, comments etc.
diff --git a/docs/manpages/smbstatus.1 b/docs/manpages/smbstatus.1
new file mode 100644
index 0000000000..76dc50cbb5
--- /dev/null
+++ b/docs/manpages/smbstatus.1
@@ -0,0 +1,52 @@
+.TH SMBSTATUS 1 17/1/1995 smbstatus smbstatus
+.SH NAME
+smbstatus \- report on current Samba connections
+.SH SYNOPSIS
+.B smbstatus
+[-d]
+[-s
+.I configuration file
+]
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B smbstatus
+is a very simple program to list the current Samba connections
+
+Just run the program and the output is self explanatory. You can offer
+a configuration filename to override the default. The default is
+CONFIGFILE from the Makefile.
+
+Option
+.I -d
+gives verbose output.
+
+.I -p
+print a list of smbd processes and exit. Useful for scripting.
+
+.SH ENVIRONMENT VARIABLES
+Not applicable.
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the
+.B smbstatus
+program be installed under the /usr/local hierarchy, in a directory readable
+by all, writeable only by root. The program itself should be executable by all.
+
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the program has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B smb.conf(5),
+.B smbd(8)
+
+See
+.B smb.conf(5) for a full list of contributors and details on how to
+submit bug reports, comments etc.
diff --git a/docs/manpages/smbtar.1 b/docs/manpages/smbtar.1
new file mode 100644
index 0000000000..0f1c38c271
--- /dev/null
+++ b/docs/manpages/smbtar.1
@@ -0,0 +1,167 @@
+.TH SMBTAR 1 18/2/96 smbtar smbtar
+.SH NAME
+smbtar \- shell script for backing up SMB shares directly to UNIX tape drive
+.SH SYNOPSIS
+.B smbtar
+.B \-s
+.I server
+.B [ \-p
+.I password
+.B ]
+.B [ \-x
+.I service
+.B ]
+.B [ \-X ]
+.B [ \-d
+.I directory
+.B ]
+.B [ \-u
+.I user
+.B ]
+.B [ \-t
+.I tape
+.B ]
+.B [ \-b
+.I blocksize
+.B ]
+.B [ \-N
+.I filename
+.B ]
+.B [ \-i ]
+.B [ \-r ]
+.B [ \-l ]
+.B [ \-v ]
+.I filenames...
+
+.SH DESCRIPTION
+This program is an extension to the Samba suite.
+
+.B smbtar
+is a very small shell script on top of smbclient, which dumps SMB
+shares directly to tape.
+
+.SH OPTIONS
+.B \-s
+.I server
+.RS 3
+The PC that the share resides upon.
+.RE
+
+.B \-x
+.I service
+.RS 3
+The share name on the PC to connect to. Default:
+.I backup.
+.RE
+
+.B \-X
+.RS 3
+Exclude mode. Exclude
+.I filenames...
+from tar create or restore.
+.RE
+
+.B \-d
+.I directory
+.RS 3
+Change to initial
+.I directory
+before restoring / backing up files.
+.RE
+
+.B \-v
+.RS 3
+Verbose mode.
+.RE
+
+.B \-p
+.I password
+
+.RS 3
+The password to use to access a share. Default: none
+.RE
+
+.B \-u
+.I user
+.RS 3
+The user id to connect as. Default: UNIX login name.
+.RE
+
+.B \-t
+.I tape
+.RS 3
+Tape device. May be regular file or tape device. Default: Tape environmental
+variable; if not set, a file called
+.I tar.out.
+.RE
+
+.B \-b
+.I blocksize
+.RS 3
+Blocking factor. Defaults to 20. See tar(1) for a fuller explanation.
+.RE
+
+.B \-N
+.I filename
+.RS 3
+Backup only files newer than filename. Could be used (for example) on a log
+file to implement incremental backups.
+.RE
+
+.B \-i
+.RS 3
+Incremental mode; tar files are only backed up if they have the
+archive bit set. The archive bit is reset after each file is read.
+.RE
+
+.B \-r
+.RS 3
+Restore. Files are restored to the share from the tar file.
+.RE
+
+.B \-l
+.RS 3
+Debug level. Corresponds to -d flag on smbclient(1).
+.RE
+
+.SH ENVIRONMENT VARIABLES
+The TAPE variable specifies the default tape device to write to. May
+be overidden with the -t option.
+
+.SH BUGS
+The smbtar script has different options from ordinary tar and tar
+called from smbclient.
+
+.SH CAVEATS
+Sites that are more careful about security may not like the way
+the script handles PC passwords. Backup and restore work on entire shares,
+should work on file lists.
+
+.SH VERSION
+This man page is correct for version 1.9.15p8 of the Samba suite.
+
+.SH SEE ALSO
+.B smbclient
+(8),
+.B smb.conf
+(8)
+.SH DIAGNOSTICS
+See diagnostics for
+.B smbclient
+command.
+
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+Ricky Poulten (poultenr@logica.co.uk) wrote the tar extension and this
+man page. The smbtar script was heavily rewritten and improved by
+Martin Kraemer <Martin.Kraemer@mch.sni.de>. Many thanks to everyone
+who suggested extensions, improvements, bug fixes, etc.
+
+See
+.B smb.conf
+(5) for a full list of contributors and details of how to submit bug reports,
+comments etc.
+
diff --git a/docs/manpages/testparm.1 b/docs/manpages/testparm.1
new file mode 100644
index 0000000000..4a0ffcbc48
--- /dev/null
+++ b/docs/manpages/testparm.1
@@ -0,0 +1,104 @@
+.TH TESTPARM 1 17/1/1995 testparm testparm
+.SH NAME
+testparm \- check an smbd configuration file for internal correctness
+.SH SYNOPSIS
+.B testparm
+[
+.I configfilename
+[
+.I hostname
+.I hostIP
+]
+]
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B testparm
+is a very simple test program to check an
+.B smbd
+configuration
+file for internal correctness. If this program reports no problems, you can use
+the configuration file with confidence that smbd will successfully
+load the configuration file.
+
+Note that this is NOT a guarantee that the services specified in the
+configuration file will be available or will operate as expected.
+
+If the optional host name and host IP address are specified on the
+command line, this test program will run through the service entries
+reporting whether the specified host has access to each service.
+.SH OPTIONS
+.I configfilename
+
+.RS 3
+This is the name of the configuration file to check.
+.RE
+
+.I hostname
+
+.RS 3
+This is the name of the host to check access on.
+
+If this parameter is supplied, the
+.I hostIP
+parameter must also be supplied, or strange things may happen.
+.RE
+
+.I hostIP
+
+.RS 3
+This is the IP number of the host specified in the previous parameter.
+
+This number must be supplied if the
+.I hostname
+parameter is supplied, or strange things may happen.
+.RE
+.SH FILES
+.B smb.conf
+.RS 3
+This is usually the name of the configuration file used by smbd.
+.RE
+.SH ENVIRONMENT VARIABLES
+Not applicable.
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the
+.B testparm
+program be installed under the /usr/local hierarchy, in a directory readable
+by all, writeable only by root. The program itself should be executable by all.
+The program should NOT be setuid or setgid!
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the program has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B smb.conf(5),
+.B smbd(8)
+.SH DIAGNOSTICS
+The program will issue a message saying whether the configuration file loaded
+OK or not. This message may be preceded by errors and warnings if the file
+did not load. If the file was loaded OK, the program then dumps all known
+service details to stdout.
+
+If a host name is specified but no host IP number, all bets are off.
+
+Other messages are self-explanatory.
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+The testparm program and this man page were written by Karl Auer
+(Karl.Auer@anu.edu.au)
+
+See
+.B samba(7) for a full list of contributors and details on how to
+submit bug reports, comments etc.
diff --git a/docs/manpages/testprns.1 b/docs/manpages/testprns.1
new file mode 100644
index 0000000000..f1c3d3ef02
--- /dev/null
+++ b/docs/manpages/testprns.1
@@ -0,0 +1,107 @@
+.TH TESTPRNS 1 17/1/1995 testprns testprns
+.SH NAME
+testprns \- check printer name for validity with smbd
+.SH SYNOPSIS
+.B testprns
+.I printername
+[
+.I printcapname
+]
+.SH DESCRIPTION
+This program is part of the Samba suite.
+
+.B testprns
+is a very simple test program to determine whether a given
+printer name is valid for use in a service to be provided by
+.B smbd.
+
+"Valid" in this context means "can be found in the printcap specified". This
+program is very stupid - so stupid in fact that it would be wisest to always
+specify the printcap file to use.
+.SH OPTIONS
+.I printername
+
+.RS 3
+The printer name to validate.
+
+Printer names are taken from the first field in each record in the printcap
+file, single printer names and sets of aliases separated by vertical bars
+("|") are recognised. Note that no validation or checking of the printcap
+syntax is done beyond that required to extract the printer name. It may
+be that the print spooling system is more forgiving or less forgiving
+than
+.B testprns
+however if
+.B testprns
+finds the printer then smbd should do as well.
+
+.RE
+
+.I printcapname
+
+.RS 3
+This is the name of the printcap file to search for the given printer name
+in.
+
+If no printcap name is specified,
+.B testprns
+will attempt to scan the printcap file specified at compile time
+(PRINTCAP_NAME).
+.RE
+.SH FILES
+.B /etc/printcap
+.RS 3
+This is usually the default printcap file to scan. See
+.B printcap(5)).
+.RE
+.SH ENVIRONMENT VARIABLES
+Not applicable.
+
+.SH INSTALLATION
+The location of the server and its support files is a matter for individual
+system administrators. The following are thus suggestions only.
+
+It is recommended that the
+.B testprns
+program be installed under the /usr/local hierarchy, in a directory readable
+by all, writeable only by root. The program should be executable by all.
+The program should NOT be setuid or setgid!
+.SH VERSION
+This man page is (mostly) correct for version 1.9.00 of the Samba suite, plus some
+of the recent patches to it. These notes will necessarily lag behind
+development of the software, so it is possible that your version of
+the program has extensions or parameter semantics that differ from or are not
+covered by this man page. Please notify these to the address below for
+rectification.
+.SH SEE ALSO
+.B printcap(5),
+.B smbd(8),
+.B smbclient(1)
+.SH DIAGNOSTICS
+If a printer is found to be valid, the message "Printer name <printername> is
+valid" will be displayed.
+
+If a printer is found to be invalid, the message "Printer name <printername>
+is not valid" will be displayed.
+
+All messages that would normally be logged during operation of smbd are
+logged by this program to the file
+.I test.log
+in the current directory. The program runs at debuglevel 3, so quite extensive
+logging information is written. The log should be checked carefully for errors
+and warnings.
+
+Other messages are self-explanatory.
+.SH BUGS
+None known.
+.SH CREDITS
+The original Samba software and related utilities were created by
+Andrew Tridgell (samba-bugs@anu.edu.au). Andrew is also the Keeper
+of the Source for this project.
+
+The testprns program and this man page were written by Karl Auer
+(Karl.Auer@anu.edu.au)
+
+See
+.B samba(7) for a full list of contributors and details of how to
+submit bug reports, comments etc.
diff --git a/docs/samba.lsm b/docs/samba.lsm
new file mode 100644
index 0000000000..503ba1ec94
--- /dev/null
+++ b/docs/samba.lsm
@@ -0,0 +1,26 @@
+Begin2
+Title = Samba
+Version = 1.8.0
+Desc1 = Samba is a SMB based file and print server for unix. It
+Desc2 = provides access to unix file and print services from
+Desc3 = SMB compatible clients such as WinNT, WfWg, OS/2
+Desc4 = and Pathworks. It also includes a ftp-style unix client
+Desc5 = and a netbios nameserver.
+Author = Andrew Tridgell
+AuthorEmail = samba-bugs@anu.edu.au
+Maintainer = Andrew Tridgell
+MaintEmail = samba-bugs@anu.edu.au
+Site1 = nimbus.anu.edu.au
+Path1 = pub/tridge/samba/
+File1 = samba-latest.tar.gz
+FileSize1 = 200K
+Required1 = Ansi-C compiler and a TCP/IP network.
+CopyPolicy1 = GNU Public License
+Keywords = LanManager, SMB, Networking
+Comment1 = To join the Samba mailing list send mail to
+Comment2 = listproc@listproc.anu.edu.au with a body of
+Comment3 = "subscribe samba Your Name"
+Entered = October 1994
+EnteredBy = Andrew Tridgell
+End
+
diff --git a/docs/textdocs/BROWSING.txt b/docs/textdocs/BROWSING.txt
new file mode 100644
index 0000000000..8a09d2274f
--- /dev/null
+++ b/docs/textdocs/BROWSING.txt
@@ -0,0 +1,145 @@
+BROWSING
+========
+
+Samba now fully supports browsing. The browsing is supported by nmbd
+and is also controlled by options in the smb.conf file (see
+smb.conf(5)).
+
+Samba can act as a browse master for a workgroup, but currently cannot
+act as a domain controller. The ability to be a domain controller will
+be added in a later version.
+
+To get browsing to work you need to run nmbd as usual, but will need
+to use the "workgroup" option in smb.conf to control what workgroup
+Samba becomes a part of.
+
+The -G option is most useful for simple setups where Samba is browsable
+in only one workgroup. In more complex cases the lmhosts file is
+better.
+
+Be very careful setting up your lmhosts file. An incorrectly setup
+lmhosts file can have disasterous results for your net!
+
+A simple lmhosts file might be:
+
+# This is a simple lmhosts file
+#
+# This is a host alias. Anyone querying this name
+# will get the specified IP
+192.0.2.17 SMBDATA
+#
+# first put ourselves in workgroup MYGROUP using
+# our own net address
+0.0.0.0 MYGROUP G
+
+Note in the above that I overrode what workgroup Samba is in using the
+G flag. Also note that the 0.0.0.0 address is used, which will be
+automatically replaced with the broadcast address for groups, and with
+the local IP address for other entries.
+
+Samba also has a useful option for a Samba server to offer itself for
+browsing on another subnet.
+
+This works by the lmhosts file specifying a broadcast address on the
+other network to use to find a browse master for the workgroup.
+
+For example if you wanted yourself to appear in the workgroup STAFF on
+the network which has a broadcast of 192.0.3.255 then this entry would
+do the trick:
+
+# put ourselves in the STAFF workgroup on the other subnet
+192.0.3.255 STAFF G
+
+Notice the G at the end! It is very important you include this as this
+entry without the G could cause a broadcast storm!
+
+If something doesn't work then hopefully the log.nmb file will
+help you track down the problem. Try a debug level of 2 or 3 for
+finding problems.
+
+Note that if it doesn't work for you, then you should still be able to
+type the server name as \\SERVER in filemanager then hit enter and
+filemanager should display the list of available shares.
+
+Some people find browsing fails because they don't have the global
+"guest account" set to a valid account. Remember that the IPC$
+connection that lists the shares is done as guest, and thus you must
+have a valid guest account.
+
+Also, a lot of people are getting bitten by the problem of too many
+parameters on the command line of nmbd in inetd.conf. This trick is to
+not use spaces between the option and the parameter (eg: -d2 instead
+of -d 2), and to not use the -B and -N options. New versions of nmbd
+are now far more likely to correctly find your broadcast and network
+addess, so in most cases these aren't needed.
+
+The other big problem people have is that their broadcast address,
+netmask or IP address is wrong (specified with the -B, -N and -I
+options to nmbd).
+
+FORCING SAMBA TO BE THE MASTER
+==============================
+
+Who becomes the "master browser" is determined by an election process
+using broadcasts. Each election packet contains a number of parameters
+which determine what precedence (bias) a host should have in the
+election. By default Samba uses a very low precedence and thus loses
+elections to just about anyone else.
+
+If you want Samba to win elections then just set the "os level" global
+option in smb.conf to a higher number. It defaults to 0. Using 33
+would make it win all elections over every other system (except other
+samba systems!)
+
+A "os level" of 2 would make it beat WfWg and Win95, but not NTAS. A
+NTAS domain controller uses level 32.
+
+The maximum os level is 255
+
+MAKING SAMBA THE DOMAIN MASTER
+==============================
+
+The domain master is responsible for collating the browse lists of
+multiple subnets so that browsing can occur between subnets. You can
+make samba act as the domain master by setting "domain master = yes"
+in smb.conf. By default it will not be a domain master.
+
+When samba is the domain master and the master browser it will listen
+for master announcements from other subnets and then contact them to
+synchronise browse lists.
+
+If you want samba to be the domain master then I suggest you also set
+the "os level" high enough to make sure it wins elections.
+
+NOTIFYING THE DOMAIN CONTROLLER
+===============================
+
+If you have a domain controller for the domain which Samba is a part
+of then you should add the line "domain controller = address" to
+smb.conf. "address" can either be a name available via DNS or a IP
+address or a broadcast address. If it is a broadcast address then
+Samba will look for a domain controller on that network.
+
+When Samba is the master browser it will regularly contact the domain
+controller to synchronise browse lists.
+
+
+NOTE ABOUT BROADCAST ADDRESSES
+==============================
+
+If your network uses a "0" based broadcast address (for example if it
+ends in a 0) then you will strike problems. Windows for Workgroups
+does not seem to support a 0's broadcast and you will probably find
+that browsing and name lookups won't work.
+
+You have a few options:
+
+1) change to a 1's broadcast on your unix server. These often end in
+.255 (check with your local network guru for details)
+
+2) set the nmbd broadcast to a 1's based address on the command line using
+the -B option. This only works if your network setup listens on both
+0s and 1s based broadcasts. The -B option can only control what
+address it sends to, not what it listens on.
+
+
diff --git a/docs/textdocs/BUGS.txt b/docs/textdocs/BUGS.txt
new file mode 100644
index 0000000000..e0fd695147
--- /dev/null
+++ b/docs/textdocs/BUGS.txt
@@ -0,0 +1,123 @@
+This file describes how to report Samba bugs.
+
+>> The email address for bug reports is samba-bugs@anu.edu.au <<
+
+(NOTE: This mail may not be in place yet. If you have troubles with it
+then use samba-bugs@arvidsjaur.anu.edu.au)
+
+
+Please take the time to read this file before you submit a bug
+report. Also, please see if it has changed between releases, as I
+may be changing the bug reporting mechanism sometime soon.
+
+Please also do as much as you can yourself to help track down the
+bug. I only develop Samba in my spare time and I receive far more mail
+about it than I can possibly answer, so you have a much higher chance
+of an answer and a fix if you send me a "developer friendly" bug
+report that lets me fix it fast.
+
+Do not assume that if you post the bug to the comp.protocols.smb
+newsgroup that I will read it. I do read all postings to the samba
+mailing list (see the README). If you suspect that your problem is not
+a bug but a configuration problem then it is better to send it to the
+Samba mailing list, as there are (at last count) 1900 other users on
+that list that may be able to help you.
+
+You may also like to look though the recent mailing list archives,
+which are conveniently accessible on the Samba web pages
+at http://lake.canberra.edu.au/pub/samba/
+
+
+GENERAL INFO
+------------
+
+Before submitting a bug report check your config for silly
+errors. Look in your log files for obvious messages that tell you that
+you've misconfigured something and run testparm to test your config
+file for correct syntax.
+
+If you include part of a log file with your bug report then be sure to
+annotate it with exactly what you were doing on the client at the
+time, and exactly what the results were.
+
+
+DEBUG LEVELS
+------------
+
+If the bug has anything to do with Samba behaving incorrectly as a
+server (like refusing to open a file) then the log files will probably
+be very useful. Depending on the problem a log level of between 3 and
+10 showing the problem may be appropriate. A higher level givesmore
+detail, but may use too much disk space.
+
+To set the debug level use "log level =" in your smb.conf. You may
+also find it useful to set the log level higher for just one machine
+and keep separate logs for each machine. To do this use:
+
+log file = /usr/local/samba/lib/log.%m
+include = /usr/local/samba/lib/smb.conf.%m
+
+then create a file "/usr/local/samba/lib/smb.conf.machine" where
+"machine" is the name of the client you wish to debug. In that file
+put any smb.conf commands you want, for example "log level=" may be
+useful. This also allows you to experiment with different security
+systems, protocol levels etc on just one machine.
+
+
+INTERNAL ERRORs
+---------------
+
+If you get a "INTERNAL ERROR" message in your log files it means that
+Samba got an unexpected signal while running. It is probably a
+segmentation fault and almost certainly means a bug in Samba (unless
+you have faulty hardware or system software)
+
+If the message came from smbd then it will probably be accompanied by
+a message which details the last SMB message received by smbd. This
+info is often very useful in tracking down the problem so please
+include it in your bug report.
+
+You should also detail how to reproduce the problem, if
+possible. Please make this reasonably detailed.
+
+You may also find that a core file appeared in a "corefiles"
+subdirectory of the directory where you keep your samba log
+files. This file is the most useful tool for tracking down the bug. To
+use it you do this:
+
+gdb smbd core
+
+adding appropriate paths to smbd and core so gdb can find them. If you
+don't have gdb then try "dbx". Then within the debugger use the
+command "where" to give a stack trace of where the problem
+occurred. Include this in your mail.
+
+If you known any assembly language then do a "disass" of the routine
+where the problem occurred (if its in a library routine then
+disassemble the routine that called it) and try to work out exactly
+where the problem is by looking at the surrounding code. Even if you
+don't know assembly then incuding this info in the bug report can be
+useful.
+
+
+ATTACHING TO A RUNNING PROCESS
+------------------------------
+
+Unfortunately some unixes (in particular some recent linux kernels)
+refuse to dump a core file if the task has changed uid (which smbd
+does often). To debug with this sort of system you could try to attach
+to the running process using "gdb smbd PID" where you get PID from
+smbstatus. Then use "c" to continue and try to cause the core dump
+using the client. The debugger should catch the fault and tell you
+where it occurred.
+
+
+PATCHES
+-------
+
+The best sort of bug report is one that includes a fix! If you send me
+patches please use "diff -u" format if your version of diff supports
+it, otherwise use "diff -c4". Make sure your do the diff against a
+clean version of the source and let me know exactly what version you
+used.
+
diff --git a/docs/textdocs/DIAGNOSIS.txt b/docs/textdocs/DIAGNOSIS.txt
new file mode 100644
index 0000000000..6681bdc4bc
--- /dev/null
+++ b/docs/textdocs/DIAGNOSIS.txt
@@ -0,0 +1,237 @@
+DIAGNOSING YOUR SAMBA SERVER
+============================
+
+This file contains a list of tests you can perform to validate your
+Samba server. It also tells you what the likely cause of the problem
+is if it fails any one of these steps. If it passes all these tests
+then it is probably working fine.
+
+You should do ALL the tests, in the order shown. I have tried to
+carefully choose them so later tests only use capabilities verified in
+the earlier tests.
+
+I would welcome additions to this set of tests. Please mail them to
+samba-bugs@anu.edu.au
+
+If you send me an email saying "it doesn't work" and you have not
+followed this test procedure then you should not be surprised if I
+ignore your email.
+
+
+ASSUMPTIONS
+-----------
+
+In all of the tests I assume you have a Samba server called BIGSERVER
+and a PC called ACLIENT. I also assume the PC is running windows for
+workgroups with a recent copy of the microsoft tcp/ip stack. The
+procedure is similar for other types of clients.
+
+I also assume you know the name of a available share in your
+smb.conf. I will assume this share is called "tmp". You can add a
+"tmp" share like by adding the following to smb.conf:
+
+[tmp]
+ comment = temporary files
+ path = /tmp
+ read only = yes
+
+
+THESE TESTS ASSUME VERSION 1.9.15 OR LATER OF THE SAMBA SUITE. SOME
+COMMANDS SHOWN DID NOT EXIST IN EARLIER VERSIONS
+
+
+TEST 1:
+-------
+
+run the command "testparm". If it reports any errors then your
+smb.conf configuration file is faulty.
+
+
+TEST 2:
+-------
+
+run the command "ping BIGSERVER" from the PC and "ping ACLIENT" from
+the unix box. If you don't get a valid response then your TCP/IP
+software is not correctly installed.
+
+Note that you will need to start a "dos prompt" window on the PC to
+run ping.
+
+If you get a message saying "host not found" or similar then your DNS
+software or /etc/hosts file is not correctly setup. It is possible to
+run samba without DNS entries for the server and client, but I assume
+you do have correct entries for the remainder of these tests.
+
+
+TEST 3:
+-------
+
+run the command "smbclient -L BIGSERVER -U%" on the unix box. You
+should get a list of available shares back.
+
+If you get a error message containing the string "Bad password" then
+you probably have either an incorrect "hosts allow", "hosts deny" or
+"valid users" line in your smb.conf, or your guest account is not
+valid. Check what your guest account is using "testparm" and
+temporarily remove any "hosts allow", "hosts deny", "valid users" or
+"invalid users" lines.
+
+If you get a "connection refused" response then the smbd server could
+not be run. If you installed it in inetd.conf then you probably edited
+that file incorrectly. If you installed it as a daemon then check that
+it is running, and check that the netbios-ssn port is in a LISTEN
+state using "netstat -a".
+
+If you get a "session request failed" then the server refused the
+connection. If it says "your server software is being unfriendly" then
+its probably because you have invalid command line parameters to smbd,
+or a similar fatal problem with the initial startup of smbd. Also
+check your config file for syntax errors with "testparm".
+
+TEST 4:
+-------
+
+run the command "nmblookup -B BIGSERVER __SAMBA__". You should get the
+IP address of your Samba server back.
+
+If you don't then nmbd is incorrectly installed. Check your inetd.conf
+if yu run it from there, or that the daemon is running and listening
+to udp port 137.
+
+One common problem is that many inetd implementations can't take many
+parameters on the command line. If this is the case then create a
+one-line script that contains the right parameters and run that from
+inetd.
+
+TEST 5:
+-------
+
+run the command "nmblookup -B ACLIENT '*'"
+
+You should get the PCs IP address back. If you don't then the client
+software on the PC isn't installed correctly, or isn't started, or you
+got the name of the PC wrong. Note that you probably won't get a "node
+status response" from the PC due to a bug in the microsoft netbios
+nameserver implementation (it responds to the wrong port number).
+
+TEST 6:
+-------
+
+run the command "nmblookup -d 2 '*'"
+
+This time we are trying the same as the previous test but are trying
+it via a broadcast to the default broadcast address. A number of
+Netbios/TCPIP hosts on the network should respond, although Samba may
+not catch all of the responses in the short time it listens. You
+should see "got a positive name query response" messages from several
+hosts.
+
+If this doesn't give a similar result to the previous test then
+nmblookup isn't correctly getting your broadcast address through its
+automatic mechanism. In this case you should experiment with the -B
+option which allows you to manually specify the broadcast address,
+overriding the automatic detection. You should try different broadcast
+addresses until your find the one that works. It will most likely be
+something like a.b.c.255 as microsoft tcpip stacks only listen on 1's
+based broadcast addresses. If you get stuck then ask your local
+networking guru for help (and show them this paragraph).
+
+If you find you do need the -B option (ie. the automatic detection
+doesn't work) then you should add the -B option with the right
+broadcast address for your network to the command line of nmbd in
+inetd.conf or in the script you use to start nmbd as a daemon. Once
+you do this go back to the "nmblookup __SAMBA__ -B BIGSERVER" test to
+make sure you have it running properly.
+
+If your PC and server aren't on the same subnet then you will need to
+use the -B option to set the broadcast address to the that of the PCs
+subnet.
+
+TEST 7:
+-------
+
+run the command "smbclient '\\BIGSERVER\TMP'". You should then be
+prompted for a password. You should use the password of the account
+you are logged into the unix box with. If you want to test with
+another account then add the -U <accountname> option to the command
+line.
+
+Once you enter the password you should get the "smb>" prompt. If you
+don't then look at the error message. If it says "invalid network
+name" then the service "tmp" is not correctly setup in your smb.conf.
+
+If it says "bad password" then the likely causes are:
+
+- you have shadow passords (or some other password system) but didn't
+compile in support for them in smbd
+- your "valid users" configuration is incorrect
+- you have a mixed case password and you haven't enabled the "password
+level" option at a high enough level
+- the "path =" line in smb.conf is incorrect. Check it with testparm
+
+Once connected you should be able to use the commands "dir" "get"
+"put" etc. Type "help <command>" for instructions. You should
+especially check that the amount of free disk space shown is correct
+when you type "dir".
+
+
+TEST 8:
+-------
+
+On the PC type the command "net view \\BIGSERVER". You will need to do
+this from within a "dos prompt" window. You should get back a list of
+available shares on the server.
+
+If you get a "network name not found" or similar error then netbios
+name resolution is not working. This is usually caused by a problem in
+nmbd. To overcome it you could do one of the following (you only need
+to choose one of them):
+
+- fixup the nmbd installation
+- add the IP address of BIGSERVER to the "wins server" box in the
+advanced tcp/ip setup on the PC.
+- enable windows name resolution via DNS in the advanced section of
+the tcp/ip setup
+- add BIGSERVER to your lmhosts file on the PC.
+
+If you get a "invalid network name" or "bad password error" then the
+same fixes apply as they did for the "smbclient -L" test above. In
+particular, make sure your "hosts allow" line is correct (see the man
+pages)
+
+
+TEST 9:
+--------
+
+run the command "net use x: \\BIGSERVER\TMP". You should be prompted
+for a password then you should get a "command completed successfully"
+message. If not then your PC software is incorrectly installed or your
+smb.conf is incorrect. make sure your "hosts allow" and other config
+lines in smb.conf are correct.
+
+It's also possible that the server can't work out what user name to
+connect you as. To see if this is the problem add the line "user =
+USERNAME" to the [tmp] section of smb.conf where "USERNAME" is the
+username corresponding to the password you typed. If you find this
+fixes things you may need the username mapping option.
+
+
+TEST 10:
+--------
+
+From file manager try to browse the server. Your samba server should
+appear in the browse list of your local workgroup (or the one you
+specified in the Makefile). You should be able to double click on the
+name of the server and get a list of shares. If you get a "invalid
+password" error when you do then you are probably running WinNT and it
+is refusing to browse a server that has no encrypted password
+capability and is in user level security mode.
+
+
+Still having troubles?
+----------------------
+
+Try the mailing list or newsgroup, or use the tcpdump-smb utility to
+sniff the problem.
+
+
diff --git a/docs/textdocs/DNIX.txt b/docs/textdocs/DNIX.txt
new file mode 100644
index 0000000000..51005e6ec8
--- /dev/null
+++ b/docs/textdocs/DNIX.txt
@@ -0,0 +1,69 @@
+DNIX has a problem with seteuid() and setegid(). These routines are
+needed for Samba to work correctly, but they were left out of the DNIX
+C library for some reason.
+
+For this reason Samba by default defines the macro NO_EID in the DNIX
+section of includes.h. This works around the problem in a limited way,
+but it is far from ideal, some things still won't work right.
+
+To fix the problem properly you need to assemble the following two
+functions and then either add them to your C library or link them into
+Samba.
+
+put this in the file setegid.s:
+
+ .globl _setegid
+_setegid:
+ moveq #47,d0
+ movl #100,a0
+ moveq #1,d1
+ movl 4(sp),a1
+ trap #9
+ bccs 1$
+ jmp cerror
+1$:
+ clrl d0
+ rts
+
+
+put this in the file seteuid.s:
+
+ .globl _seteuid
+_seteuid:
+ moveq #47,d0
+ movl #100,a0
+ moveq #0,d1
+ movl 4(sp),a1
+ trap #9
+ bccs 1$
+ jmp cerror
+1$:
+ clrl d0
+ rts
+
+after creating the above files you then assemble them using
+
+as seteuid.s
+as setegid.s
+
+that should produce the files seteuid.o and setegid.o
+
+then you need to add these to the LIBSM line in the DNIX section of
+the Samba Makefile. Your LIBSM line will then look something like this:
+
+LIBSM = setegid.o seteuid.o -ln
+
+You should then remove the line:
+
+#define NO_EID
+
+from the DNIX section of includes.h
+
+Then recompile and try it out!
+
+Note that this file was derived from an email from Peter Olsson
+<pol@leissner.se>. I don't have DNIX myself, so you're probably better
+off contacting Peter if you have problems.
+
+Andrew
+
diff --git a/docs/textdocs/DOMAIN.txt b/docs/textdocs/DOMAIN.txt
new file mode 100644
index 0000000000..31e19675fa
--- /dev/null
+++ b/docs/textdocs/DOMAIN.txt
@@ -0,0 +1,68 @@
+Samba now supports domain logons and network logon scripts. The
+support is still experimental, but it seems to work.
+
+The support is also not complete. Samba does not yet support the
+sharing of the SAM database with other systems yet, or remote
+administration. Support for these kind of things should be added
+sometime in the future.
+
+The domain support only works for WfWg and Win95 clients. Support for
+NT and OS/2 clients is still being worked on.
+
+Using these features you can make your clients verify their logon via
+the Samba server and make clients run a batch file when they logon to
+the network. The latter is particularly useful.
+
+To use domain logons you need to do the following:
+
+1) Setup nmbd and smbd and configure the smb.conf so that Samba is
+acting as the master browser. See INSTALL.txt and BROWSING.txt for
+details.
+
+2) create a share called [netlogon] in your smb.conf. This share should
+be readable by all users, and probably should not be writeable. This
+share will hold your network logon scripts.
+
+For example I have used:
+
+ [netlogon]
+ path = /data/dos/netlogon
+ writeable = no
+ guest ok = yes
+
+
+3) in the [global] section of smb.conf set the following:
+
+ domain logons = yes
+ logon script = %U.bat
+
+the choice of batch file is, of course, up to you. The above would
+give each user a separate batch file as the %U will be changed to
+their username automatically. The other standard % macros may also be
+used. You can make the btch files come from a subdirectory by using
+soemthing like:
+
+ logon script = scripts\%U.bat
+
+4) create the batch files to be run when the user logs in. If the batch
+file doesn't exist then no batch file will be run.
+
+In the batch files you need to be careful to use DOS style cr/lf line
+endings. If you don't then DOS may get confused. I suggest you use a
+DOS editor to remotely edit the files if you don't know how to produce
+DOS style files under unix.
+
+5) Use smbclient with the -U option for some users to make sure that
+the \\server\NETLOGON share is available, the batch files are visible
+and they are readable by the users.
+
+6) you will probabaly find that your clients automatically mount the
+\\SERVER\NETLOGON share as drive z: while logging in. You can put some
+useful programs there to execute from the batch files.
+
+
+NOTE: You must be using "security = user" or "security = server" for
+domain logons to work correctly. Share level security won't work
+correctly.
+
+
diff --git a/docs/textdocs/ENCRYPTION.txt b/docs/textdocs/ENCRYPTION.txt
new file mode 100644
index 0000000000..046b473e9a
--- /dev/null
+++ b/docs/textdocs/ENCRYPTION.txt
@@ -0,0 +1,333 @@
+ LanManager / Samba Password Encryption.
+ ---------------------------------------
+
+With the development of LanManager compatible password encryption for
+Samba, it is now able to validate user connections in exactly the same
+way as a LanManager or Windows NT server.
+
+This document describes how the SMB password encryption algorithm
+works and what issues there are in choosing whether you want to use
+it. You should read it carefully, especially the part about security
+and the "PROS and CONS" section.
+
+How does it work ?
+------------------
+
+ LanManager encryption is somewhat similar to UNIX password
+encryption. The server uses a file containing a hashed value of a
+users password. This is created by taking the users paintext
+password, capitalising it, and either truncating to 14 bytes (or
+padding to 14 bytes with null bytes). This 14 byte value is used as
+two 56 bit DES keys to encrypt a 'magic' eight byte value, forming a
+16 byte value which is stored by the server and client. Let this value
+be known as the *hashed password*.
+
+When a client (LanManager, Windows for WorkGroups, Windows 95 or
+Windows NT) wishes to mount a Samba drive (or use a Samba resource) it
+first requests a connection and negotiates the protocol that the client
+and server will use. In the reply to this request the Samba server
+generates and appends an 8 byte, random value - this is stored in the
+Samba server after the reply is sent and is known as the *challenge*.
+
+The challenge is different for every client connection.
+
+The client then uses the hashed password (16 byte value described
+above), appended with 5 null bytes, as three 56 bit DES keys, each of
+which is used to encrypt the challenge 8 byte value, forming a 24 byte
+value known as the *response*.
+
+In the SMB call SMBsessionsetupX (when user level security is
+selected) or the call SMBtconX (when share level security is selected)
+the 24 byte response is returned by the client to the Samba server.
+
+The Samba server then reproduces the above calculation, using it's own
+stored value of the 16 byte hashed password (read from the smbpasswd
+file - described later) and the challenge value that it kept from the
+negotiate protocol reply. It then checks to see if the 24 byte value it
+calculates matches the 24 byte value returned to it from the client.
+
+If these values match exactly, then the client knew the correct
+password (or the 16 byte hashed value - see security note below) and
+is this allowed access. If not then the client did not know the
+correct password and is denied access.
+
+Note that the Samba server never knows or stores the cleartext of the
+users password - just the 16 byte hashed function derived from it. Also
+note that the cleartext password or 16 byte hashed value are never
+transmitted over the network - thus increasing security.
+
+IMPORTANT NOTE ABOUT SECURITY
+-----------------------------
+
+The unix and SMB password encryption techniques seem similar on the
+surface. This similarity is, however, only skin deep. The unix scheme
+typically sends clear text passwords over the nextwork when logging
+in. This is bad. The SMB encryption scheme never sends the cleartext
+password over the network but it does store the 16 byte hashed value
+on disk. This is also bad. Why? Because the 16 byte hashed value is a
+"password equivalent". You cannot derive the users password from it,
+but it could potentially be used in a modified client to gain access
+to a server. This would require considerable technical knowledge on
+behalf of the attacker but is perfectly possible. You should thus
+treat the smbpasswd file as though it contained the cleartext
+passwords of all your users. Its contents must be kept secret, and the
+file should be protected accordingly.
+
+Ideally we would like a password scheme which neither requires plain
+text passwords on the net or on disk. Unfortunately this is not
+available as Samba is stuck with being compatible with other SMB
+systems (WinNT, WfWg, Win95 etc).
+
+
+PROS AND CONS
+-------------
+
+There are advantages and disadvantages to both schemes.
+
+Advantages of SMB Encryption:
+-----------------------------
+
+- plain text passwords are not passed across the network. Someone using
+a network sniffer cannot just record passwords going to the SMB server.
+
+- WinNT doesn't like talking to a server that isn't using SMB
+encrypted passwords. It will refuse to browse the server if the server
+is also in user level security mode. It will insist on promting the
+user for the password on each connection, which is very annoying. The
+only things you can do to stop this is to use SMB encryption.
+
+Advantages of non-encrypted passwords:
+--------------------------------------
+
+- plain text passwords are not kept on disk.
+
+- uses same password file as other unix services such as login and
+ftp
+
+- you are probably already using other services (such as telnet and
+ftp) which send plain text passwords over the net, so not sending them
+for SMB isn't such a big deal.
+
+- the SMB encryption code in Samba is new and has only had limited
+testing. We have tried hard to make it secure but in any new
+implementation of a password scheme there is the possability of an
+error.
+
+
+The smbpasswd file.
+-------------------
+
+ In order for Samba to participate in the above protocol it must
+be able to look up the 16 byte hashed value given a user name.
+Unfortunately, as the UNIX password value is also a one way hash
+function (ie. it is impossible to retrieve the cleartext of the users
+password given the UNIX hash of it) then a separate password file
+containing this 16 byte value must be kept. To minimise problems with
+these two password files, getting out of sync, the UNIX /etc/passwd and
+the smbpasswd file, a utility, mksmbpasswd.sh, is provided to generate
+a smbpasswd file from a UNIX /etc/passwd file.
+
+To generate the smbpasswd file from your /etc/passwd file use the
+following command :-
+
+cat /etc/passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd
+
+If you are running on a system that uses NIS, use
+
+ypcat passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd
+
+The mksmbpasswd.sh program is found in the Samba source directory. By
+default, the smbpasswd file is stored in :-
+
+/usr/local/samba/private/smbpasswd
+
+The owner of the /usr/local/samba/private directory should be set to
+root, and the permissions on it should be set to :-
+
+r-x------
+
+The command
+
+chmod 500 /usr/local/samba/private
+
+will do the trick. Likewise, the smbpasswd file inside the private
+directory should be owned by root and the permissions on is should be
+set to
+
+rw-------
+
+by the command :-
+
+chmod 600 smbpasswd.
+
+The format of the smbpasswd file is
+
+username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell
+
+Although only the username, uid, and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+sections are significant and are looked at in the Samba code.
+
+It is *VITALLY* important that there by 32 'X' characters between the
+two ':' characters - the smbpasswd and Samba code will fail to validate
+any entries that do not have 32 characters between ':' characters.
+
+When the password file is created all users have password entries
+consisting of 32 'X' characters. By default this disallows any access
+as this user. When a user has a password set, the 'X' characters change
+to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii
+representation of the 16 byte hashed value of a users password.
+
+To set a user to have no password (not recommended), edit the file
+using vi, and replace the first 11 characters with the asci text
+
+NO PASSWORD
+
+Eg. To clear the password for user bob, his smbpasswd file entry would
+look like :
+
+bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell
+
+If you are allowing users to use the smbpasswd command to set their own
+passwords, you may want to give users NO PASSWORD initially so they do
+not have to enter a previous password when changing to their new
+password (not recommended).
+
+Note : This file should be protected very carefully. Anyone with
+access to this file can (with enough knowledge of the protocols) gain
+access to your SMB server. The file is thus more sensitive than a
+normal unix /etc/passwd file.
+
+The smbpasswd Command.
+----------------------
+
+ The smbpasswd command maintains the 32 byte password field in
+the smbpasswd file. If you wish to make it similar to the unix passwd
+or yppasswd programs, install it in /usr/local/samba/bin (or your main
+Samba binary directory) and make it setuid root.
+
+Note that if you do not do this then the root user will have to set all
+users passwords.
+
+To set up smbpasswd as setuid root, change to the Samba binary install
+directory and then type (as root) :
+
+chown root smbpasswd
+chmod 4555 smbpasswd
+
+If smbpasswd is installed as setuid root then you would use it as
+follows.
+
+smbpasswd
+Old SMB password: <type old alue here - just hit return if there is NO PASSWORD>
+New SMB Password: < type new value >
+Repeat New SMB Password: < re-type new value >
+
+If the old value does not match the current value stored for that user,
+or the two new values do not match each other, then the password will
+not be changed.
+
+If invoked by an ordinary user it will only allow the user to change
+his or her own Samba password.
+
+If run by the root user smbpasswd may take an optional argument,
+specifying the user name whose SMB password you wish to change. Note
+that when run as root smbpasswd does not prompt for or check the old
+password value, thus allowing root to set passwords for users who have
+forgotten their passwords.
+
+smbpasswd is designed to work in the same way and be familiar to UNIX
+users who use the passwd or yppasswd commands.
+
+NOTE. As smbpasswd is designed to be installed as setuid root I would
+appreciate it if everyone examined the source code to look for
+potential security flaws. A setuid program, if not written properly can
+be an open door to a system cracker. Please help make this program
+secure by reporting all problems to me (the author, Jeremy Allison).
+
+My email address is :-
+
+jra@vantive.com
+
+Setting up Samba to support LanManager Encryption.
+--------------------------------------------------
+
+This is a very brief description on how to setup samba to support
+password encryption. More complete instructions will probably be added
+later.
+
+1) get and compile the libdes libraries. the source is available from
+nimbus.anu.edu.au in pub/tridge/libdes/libdes.tar.92-10-13.gz
+
+2) enable the encryption stuff in the Samba makefile, making sure you
+point it to the libdes library and include file (it needs des.h)
+The entries you need to uncomment are the four lines after the comment :-
+
+# This is for SMB encrypted (lanman) passwords.
+
+Note that you may have to change the variable DES_BASE to
+point at the place where you installed the DES library.
+
+3) compile and install samba as usual
+
+4) f your system can't compile the module getsmbpass.c then remove the
+-DSMBGETPASS define from the Makefile.
+
+5) enable encrypted passwords in smb.conf by adding the line
+"encrypt passwords = yes" in the [global] section
+
+6) create the initial smbpasswd password file in the place you
+specified in the Makefile. A simple way to do this based on your
+existing Makefile (assuming it is in a reasonably standard format) is
+like this:
+
+cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd
+
+Change ownership of private and smbpasswd to root.
+
+chown -R root /usr/local/samba/private
+
+Set the correct permissions on /usr/local/samba/private
+
+chmod 500 /usr/local/samba/private
+
+Set the correct permissions on /usr/local/samba/private/smbpasswd
+
+chmod 600 /usr/local/samba/private/smbpasswd
+
+note that the mksmbpasswd.sh script is in the samba source directory.
+
+If this fails then you will find that you will need entries that look
+like this:
+
+# SMB password file.
+tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh
+
+note that the uid and username fields must be right. Also, you must get
+the number of X's right (there should be 32).
+
+If you wish, install the smbpasswd program as suid root.
+
+chown root /usr/local/samba/bin/smbpasswd
+chmod 4555 /usr/local/samba/bin/smbpasswd
+
+7) set the passwords for users using the smbpasswd command. For
+example, as root you could do "smbpasswd tridge"
+
+8) try it out!
+
+Note that you can test things using smbclient, as it also now supports
+encryption.
+
+NOTE TO USA Sites that Mirror Samba
+-----------------------------------
+
+The DES library is considered a munition in the USA. Under US Law it is
+illegal to export this software, or to put it in a freely available ftp
+site.
+
+Please do not mirror the DES directory from the site on nimbus.anu.edu.au
+
+Thank you,
+
+Jeremy Allison.
+
diff --git a/docs/textdocs/HINTS.txt b/docs/textdocs/HINTS.txt
new file mode 100644
index 0000000000..953650bdd3
--- /dev/null
+++ b/docs/textdocs/HINTS.txt
@@ -0,0 +1,202 @@
+Here are some random hints that you may find useful. These really
+should be incorporated in the main docs someday.
+
+
+----------------------
+HINT: Always test your smb.conf with testparm before using it
+
+If your smb.conf file is invalid then samba will fail to load. Run
+testparm over it before you install it just to make sure there aren't
+any basic syntax or logical errors.
+
+
+----------------------
+HINT: Try printing with smbclient first
+
+If you have problems printing, test with smbclient first. Just connect using
+"smbclient '\\server\printer' -P" and use the "print" command.
+
+Once this works, you know that Samba is setup correctly for printing,
+and you should be able to get it to work from your PCs.
+
+This particularly helps in getting the "print command" right.
+
+
+----------------------
+HINT: Mount cdroms with conv=binary
+
+Some OSes (notably Linux) default to auto detection of file type on
+cdroms and do cr/lf translation. This is a very bad idea when use with
+Samba. It causes all sorts of stuff ups.
+
+To overcome this problem use conv=binary when mounting the cdrom
+before exporting it with Samba.
+
+
+----------------------
+HINT: Convert between unix and dos text formats
+
+Jim barry has written an excellent drag-and-drop cr/lf converter for
+windows. Just drag your file onto the icon and it converts the file.
+
+Get it from
+ftp://nimbus.anu.edu.au/pub/tridge/samba/contributed/fixcrlf.zip
+
+----------------------
+HINT: Use the "username map" option
+
+If the usernames used on your PCs don't match those used on the unix
+server then you will find the "username map" option useful.
+
+-----------------------
+HINT: Use "security = user" in [global]
+
+If you have the same usernames on the unix box and the PCs or have
+mapped them with the "username map" option then choose "security =
+user" in the [global] section of smb.conf.
+
+This will mean your password is checked only when you first connect,
+and subsequent connections to printers, disks etc will go more
+smoothly and much faster.
+
+The main problem with "security = user" if you use WfWg is that you
+will ONLY be able to connect as the username that you log into WfWg
+with. This is because WfWg silently ignores the password field in the
+connect drive dialog box if the server is in user security mode.
+
+------------------------
+HINT: Make your printers not "guest ok"
+
+If your printers are not "guest ok" and you are using "security =
+user" and have matching unix and PC usernames then you will attach to
+the printer without trouble as your own username. This will mean you
+will be able to delete print jobs (in 1.8.06 and above) and printer
+accounting will be possible.
+
+
+-----------------------
+HINT: Use a sensible "guest" account
+
+Even if all your services are not available to "guest" you will need a
+guest account. This is because the browsing is done as guest. In many
+cases setting "guest account = ftp" will do the trick. Using the
+default guest account or "guest account = nobody" will give problems on
+many unixes. If in doubt create another account with minimal
+privilages and use it instead. Your users don't need to know the
+password of the guest account.
+
+
+-----------------------
+HINT: Use the latest TCP/IP stack from microsoft if you use Windows
+for workgroups.
+
+The early TCP/IP stacks had lots of bugs.
+
+Microsoft has released an incremental upgrade to their TCP/IP 32-Bit
+VxD drivers. The latest release can be found on their ftp site at
+ftp.microsoft.com, located in /peropsys/windows/public/tcpip/wfwt32.exe.
+There is an update.txt file there that describes the problems that were
+fixed. New files include WINSOCK.DLL, TELNET.EXE, WSOCK.386, VNBT.386,
+WSTCP.386, TRACERT.EXE, NETSTAT.EXE, and NBTSTAT.EXE.
+
+
+-----------------------
+HINT: nmbd can act as a "WINS" server
+
+By default SMB clients use broadcasts to find shares. Recent clients
+(such as WfWg) can use a "wins" server instead, whcih reduces your
+broadcast traffic and allows you to find names across routers.
+
+Just point your WfWg, Win95 and NT clients at the Samba box in the WINS option.
+
+Note: nmbd does not support all WINS operations. Anyone out there have
+a spec they could send me?
+
+-----------------------
+HINT: you may need to delete your .pwl files when you change password.
+
+WfWg does a lousy job with passwords. I find that if I change my
+password on either the unix box or the PC the safest thing to do is to
+delete the .pwl files in the windows directory. The PC will complain about not finding the files, but will soon get over it, allowing you to enter the new password.
+
+If you don't do this you may find that WfWg remembers and uses the old
+password, even if you told it a new one.
+
+Often WfWg will totally ignore a password you give it in a dialog box.
+
+----------------------
+HINT: Using MS Access
+
+Here are some notes on running MS-Access on a Samba drive from Stefan
+Kjellberg <stefank@esi.com.au>
+
+1. Opening a database in 'exclusive' mode does NOT work. Samba ignores
+ r/w/share modes on file open.
+
+2. Make sure that you open the database as 'shared' and to 'lock modified
+ records'
+
+3. Of course locking must be enabled for the particular share (smb.conf)
+
+
+---------------------
+HINT: password cacheing in WfWg
+
+Here is a hint from michael@ecel.uwa.edu.au (Michael Simmons):
+
+In case people where not aware. There is a program call admincfg.exe
+on the last disk (disk 8) of the WFW 3.11 disk set. To install it
+type EXPAND A:\ADMINCFG.EX_ C:\WINDOWS\ADMINCFG.EXE Then add an icon
+for it via the "Progam Manager" "New" Menu. This program allows you
+to control how WFW handles passwords. ie disable Password Caching etc
+for use with "security = user"
+
+
+--------------------
+HINT: file descriptor limits
+
+If you have problems with the limits on the number of open files you
+can edit local.h to fix it.
+
+--------------------
+HINT: HPUX initgroups() problem
+
+here is a hint from Frank Wales [frank@arcglade.demon.co.uk]:
+
+HP's implementation of supplementary groups is, er, non-standard (for
+hysterical reasons). There are two group files, /etc/group and
+/etc/logingroup; the system maps UIDs to numbers using the former, but
+initgroups() reads the latter. Most system admins who know the ropes
+symlink /etc/group to /etc/logingroup (hard link doesn't work for reasons
+too stupid to go into here). initgroups() will complain if one of the
+groups you're in in /etc/logingroup has what it considers to be an invalid
+ID, which means outside the range [0..UID_MAX], where UID_MAX is (I think)
+60000 currently on HP-UX. This precludes -2 and 65534, the usual 'nobody'
+GIDs.
+
+Perhaps you could suggest to users that, if they encounter this problem,
+they make sure that the programs that are failing to initgroups() be
+run as users not in any groups with GIDs outside the allowed range.
+
+This is documented in the HP manual pages under setgroups(2) and passwd(4).
+
+
+---------------------
+HINT: Patch your SCO system
+
+If you run SCO Unix then you may need to get important TCP/IP patches
+for Samba to work correctly. Try
+
+Paul_Davis@mindlink.bc.ca writes:
+
+ I was having problems with Accpac using 1.9.02 on SCO Unix. One
+ posting function reported corrupted data. After installing uod385a,
+ the problem went away (a restore from backup and then another
+ run-thru).
+
+ It appears that the uod385a update for SCO may be fairly important for
+ a lot of different DOS and Windows software under Samba.
+
+ uod385a can be found at ftp.sco.com /SLS/uod385a.Z and uod385a.ltr.Z.
+
+
diff --git a/docs/textdocs/INSTALL.sambatar b/docs/textdocs/INSTALL.sambatar
new file mode 100644
index 0000000000..388e2a3eb6
--- /dev/null
+++ b/docs/textdocs/INSTALL.sambatar
@@ -0,0 +1,27 @@
+
+Please see the readme and the man page for general info.
+
+1) Follow the samba installation instructions.
+
+2) If all goes well, test it out by creating a share on your PC (called
+backup for example) then doing something like,
+
+ ./smbtar -s mypc -t /dev/rmt/0ubn -x backup
+
+substituting whatever your tape drive is for the -t option, or set your
+tape environmental variable.
+
+If all does not go well, feel free to mail the author (poultenr@logica.co.uk)
+about bug reports / help / money / pizza / etc.
+
+3) Read the man page and the NOTES file for more information
+
+4) Work smbtar into your usual nightly backup scheme (presuming you
+have one :-}).
+
+
+NOTE:
+
+If you have problems with smbtar then it's probably best to contact the
+author Ricky Poulten (poultenr@logica.co.uk).
+
diff --git a/docs/textdocs/PROJECTS b/docs/textdocs/PROJECTS
new file mode 100644
index 0000000000..cf903f2c6d
--- /dev/null
+++ b/docs/textdocs/PROJECTS
@@ -0,0 +1,96 @@
+ Samba Projects Directory
+ ========================
+
+
+>>>>> NOTE: THIS FILE IS NOW VERY OUT OF DATE <<<<<
+
+
+This is a list of who's working on what in Samba. It's not guaranteed
+to be uptodate or accurate but I hope it will help us getting
+coordinated.
+
+If you are working on something to do with Samba and you aren't here
+then please let me know! Also, if you are listed below and you have
+any corrections or updates then please let me know.
+
+Email contact:
+samba-bugs@anu.edu.au
+
+========================================================================
+Documentation and FAQ
+
+Docs and FAQ files for the Samba suite of software.
+
+Contact Karl.Auer@anu.edu.au
+
+Mark Preston is now working on a set of formatted docs for Samba.
+Contact mpreston@sghms.ac.uk
+
+Docs are currently up to date with version, 1.7.07. FAQ being added to
+as questions arise.
+
+Status last updated 27th September 1994
+========================================================================
+
+========================================================================
+Netbeui support
+
+This aims to produce patches so that Samba can be used with clients
+that do not have TCP/IP. It will try to remain as portable as possible.
+
+Contact Brian.Onn@Canada.Sun.COM (Brian Onn)
+
+The project is just startup up.
+
+Status last updated 4th October 1994
+========================================================================
+
+========================================================================
+Smbfs
+
+A mountable smb filesystem for Linux using the userfs userspace filesystem
+
+Contact lendecke@namu01.gwdg.de (Volker Lendecke)
+
+Currently this is at version 0.2. It works but is really only for
+people with some knowledge and experience of Linux kernel hacking.
+
+Status last updated 23rd August 1994
+========================================================================
+
+========================================================================
+Nmbd
+
+Aims to produce a complete rfc1001/1002 implementation. The current
+nmbd is a partial implementation.
+
+Contact Fabrice Cetre (cetre@ifhpserv.insa-lyon.fr)
+
+Status last updated 23rd August 1994
+========================================================================
+
+========================================================================
+Admin Tool
+
+Aims to produce a nice smb.conf editor and other useful tools for
+administering a Samba system.
+
+Contact: Steve Brown (steve@unicorn.dungeon.com)
+
+In the design phase.
+
+Status last updated 4th September 1994
+========================================================================
+
+
+========================================================================
+Lanman Client.
+
+Contact: john@amanda.xs4all.nl (John Stewart)
+
+Aims to produce a reliable LANMAN Client implementation for LINUX,
+and possibly other variations of UNIX. Project ably started by
+Tor Lillqvist; tml@hemuli.tte.vtt.fi
+
+Status last updated 17th January 1995
+========================================================================
diff --git a/docs/textdocs/Passwords.txt b/docs/textdocs/Passwords.txt
new file mode 100644
index 0000000000..e06876feca
--- /dev/null
+++ b/docs/textdocs/Passwords.txt
@@ -0,0 +1,42 @@
+NOTE ABOUT PASSWORDS
+====================
+
+Unix systems use a wide variety of methods for checking the validity
+of a password. This is primarily controlled with the Makefile defines
+mentioned in the Makefile.
+
+Also note that some clients (notably WfWg) uppercase the password
+before sending it. The server tries the password as it receives it and
+also after lowercasing it.
+
+The Samba server can also be configured to try different
+upper/lowercase combinations. This is controlled by the [global]
+parameter "password level". A level of N means to try all combinations
+up to N uppercase characters in the password. A high value can chew a
+fair bit of CPU time and can lower the security of your system. Do not
+use this options unless you really need it - the time taken for
+password checking can become so high that clients time out.
+
+If you do use the "password level" option then you might like to use
+-DUFC_CRYPT in your Makefile. On some machine this makes password
+checking _much_ faster. This is also useful if you use the @group
+syntax in the user= option.
+
+If your site uses AFS (the Andrew File System), you can use the AFS section
+in the Makefile. This will first attempt to authenticate a username and
+password to AFS. If that succeeds, then the associated AFS rights will be
+granted. Otherwise, the password checking routine falls back to whatever
+Unix password checking method you are using. Note that the AFS code is
+only written and tested for AFS 3.3 and later.
+
+
+SECURITY = SERVER
+=================
+
+Samba can use a remote server to do it's username/password
+validation. This allows you to have one central machine (for example a
+NT box) control the passwords for the Unix box.
+
+See the section on "security =" in smb.conf(5) for details.
+
+
diff --git a/docs/textdocs/README.DCEDFS b/docs/textdocs/README.DCEDFS
new file mode 100644
index 0000000000..f84b84bb68
--- /dev/null
+++ b/docs/textdocs/README.DCEDFS
@@ -0,0 +1,79 @@
+=============================================================================
+
+ Basic DCE/DFS Support for SAMBA 1.9.13
+
+ Jim Doyle <doyle@oec.com> 06-02-95
+
+=============================================================================
+
+Functionality:
+--------------
+
+ Per-instance authentication for DCE/DFS.
+
+Missing Functionality in this Implementation:
+---------------------------------------------
+
+ * No automatic refresh of credentials
+
+ To do so would not be that hard.. One could simply
+ stash the clear-text key in memory, spawn a key management
+ thread to wake up right before credentials expire and
+ refresh the login context.
+
+ * No UNIX Signals support (SIGCLD, SIGPIPE, SIGHUP, SIGBUS, SIGSEGV)
+
+
+ There is no support for signal processing in Samba daemons
+ that need to authenticate with DCE. The explanation for this
+ is that the smbd is linked against thread-safe libraries in
+ order to be able to use DCE authentication mechanisms.
+ Because smbd uses signal() and fork(), it represents the
+ worst case scenario for DCE portability. In order
+ to properly support signals in a forked server environment,
+ some rework of smbd is needed in order to properly
+ construct, shutdown and reconstruct asynchronous signal
+ handling threads and synchronous signal traps across the
+ parent and child. I have not had contiguous time to work
+ on it, I expect it to be a weeks worth of work to cleanly
+ integrate thread-safe signal handing into the code and
+ test it. Until I can get to this task, I will leave it up
+ to someone adventurous enough to engineer it and negotiate
+ with Andrew to integrate the changes into the mainline branch.
+
+ The lack of full signal support means that you cannot
+ rely upon SIGHUP-ing the parent daemon to refresh
+ the configuration data. Likewise, you cannot take advantage
+ of the builtin SIGBUS/SIGSEGV traps to diagnose failures.
+ You will have to halt Samba in order to make changes
+ and then have them take effect.
+
+ The SMBD server as it stands is suitable to use if you
+ already have experience with configuring and running
+ SAMBA.
+
+Tested Platforms:
+-----------------
+
+ HP-UX 9.05 / HP-UX DCE 1.2.1
+ AIX 3.2.5 / AIX DCE/6000 1.3
+ DEC OSF-1 3.0 / DEC DCE 1.3
+
+Building:
+---------
+
+ - Uncomment the the appropriate block in the Makefile
+ for the platform you wish to build on.
+
+ - Samples of Samba server configuration files for our
+ DFS environment are included in samples.dcedfs/
+
+
+
+Bugs, Suggestions, etc..
+--------------------------
+
+ Please post them to the mailing list.
+ That way I will see them and they will become part of
+ the archives so others can share the knowledge.
+
diff --git a/docs/textdocs/README.jis b/docs/textdocs/README.jis
new file mode 100644
index 0000000000..2ac6716a6f
--- /dev/null
+++ b/docs/textdocs/README.jis
@@ -0,0 +1,124 @@
+$B!|(B samba $BF|K\8lBP1~$K$D$$$F(B
+
+1. $BL\E*(B
+
+ $BF|K\8lBP1~$O!"(B
+
+ (1) MS-Windows $B>e$G!"4A;z%U%!%$%kL>$r$I$&$7$F$b07$&I,MW$N$"$k%"%W%j%1!<%7%g%s$,$A$c(B
+ $B$s$HF0:n$9$k!#Nc$($P!"(BMS-WORD 5 $B$J$I$O!"%$%s%9%H!<%k;~$K4A;z$N%U%!%$%kL>$r>!<j(B
+ $B$K$D$1$F$7$^$$$^$9!#$3$&$$$C$?>l9g$K$A$c$s$HBP1~$G$-$k$h$&$K$9$k!#(B
+
+ (2) UNIX $B$O!":G6a$G$O$[$H$s$I$N$b$N$,(B 8 bits $B$N%U%!%$%kL>$r%5%]!<%H$7$F$$$^$9$,!"(B
+ $BCf$K$O!"$3$l$r%5%]!<%H$7$F$$$J$$$b$N$b$"$j$^$9!#$3$N$h$&$J>l9g$G$b!"(B(1)$B$NL\E*(B
+ $B$,K~B-$G$-$k$h$&$K$9$k!#(B
+
+ $B$rL\E*$H$7$F$$$^$9!#$=$N$?$a!"F|K\8lBP1~$O!"I,MW:G>.8B$7$+9T$J$C$F$*$j$^$;$s!#(B
+
+2. $BMxMQJ}K!(B
+
+(1) $BDI2C$7$?%Q%i%a!<%?(B
+
+ smb.conf $B%U%!%$%k$N(B global $B%;%/%7%g%s$K0J2<$N%Q%i%a!<%?$r@_Dj$G$-$k$h$&$K$7$^$7$?!#(B
+
+ [global]
+ ....
+ coding system = <$B%3!<%I7O(B>
+
+ $B$3$3$G;XDj$5$l$?%3!<%I7O$,(B UNIX $B>e$N%U%!%$%k%7%9%F%`$N%U%!%$%kL>$N%3!<%I$K$J$j$^$9!#(B
+ $B@_Dj$G$-$k$b$N$O!"<!$N$h$&$K$J$C$F$$$^$9!#(B
+
+ sjis: SHIFT JIS (MS $B4A;z%3!<%I(B)
+ euc: EUC $B%3!<%I(B
+ hex: 7 bits $B$N(B ASCII $B%3!<%I0J30$N%3!<%I$r0J2<$N7A<0$GI=$9J}<0$G$9!#Nc$($P!"(B
+ '$B%*%U%#%9(B' $B$H$$$&L>A0$O!"(B':83:49:83:74:83:42:83:58' $B$N$h$&$K!"(B':' $B$N8e$K#27e(B
+ $B$N(B16$B?J?t$rB3$1$k7A<0$K$J$j$^$9!#(B
+ $B$3$3$G!"(B':' $B$rB>$NJ8;z$KJQ99$7$?$$>l9g$O!"(Bhex $B$N8e$m$K$=$NJ8;z$r;XDj$7$^$9!#(B
+ $BNc$($P!"(B@$B$rJQ$o$j$K;H$$$?$$>l9g$O!"(B'hex@'$B$N$h$&$K;XDj$7$^$9!#(B
+ JIS $B%3!<%I$K$D$$$F$O!"0J2<$NI=$r;2>H$7$F2<$5$$!#(B
+ $B(#(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(((!(!(!(!(!(!(!(!(!($(B
+ $B(";XDj(B $B("4A;z3+;O("4A;z=*N;("%+%J3+;O("%+%J=*N;("1Q?t3+;O("Hw9M(B $B("(B
+ $B('(!(!(!(+(!(!(!(!(+(!(!(!(!(+(!(!(!(!(+(!(!(!(!(+(!(!(!(!(+(!(!(!(!(!(!(!(!(!()(B
+ $B("(Bjis7 $B("(B\E$B $B("(B\E(J $B("(B0x0e $B("(B0x0f $B("(B\E(J $B("(Bjis 7$BC10LId9f(B $B("(B
+ $B("(Bjunet $B("(B\E$B $B("(B\E(J $B("(B\E(I $B("(B\E(J $B("(B\E(J $B("(B7bits $B%3!<%I(B $B("(B
+ $B("(Bjis8 $B("(B\E$B $B("(B\E(J $B("(B-- $B("(B-- $B("(B\E(J $B("(Bjis 8$BC10LId9f(B $B("(B
+ $B("(Bj7bb $B("(B\E$B $B("(B\E(B $B("(B0x0e $B("(B0x0f $B("(B\E(B $B("(B $B("(B
+ $B("(Bj7bj $B("(B\E$B $B("(B\E(J $B("(B0x0e $B("(B0x0f $B("(B\E(J $B("(Bjis7$B$HF1$8(B $B("(B
+ $B("(Bj7bh $B("(B\E$B $B("(B\E(H $B("(B0x0e $B("(B0x0f $B("(B\E(H $B("(B $B("(B
+ $B("(Bj7@b $B("(B\E$@ $B("(B\E(B $B("(B0x0e $B("(B0x0f $B("(B\E(B $B("(B $B("(B
+ $B("(Bj7@j $B("(B\E$@ $B("(B\E(J $B("(B0x0e $B("(B0x0f $B("(B\E(J $B("(B $B("(B
+ $B("(Bj7@h $B("(B\E$@ $B("(B\E(H $B("(B0x0e $B("(B0x0f $B("(B\E(H $B("(B $B("(B
+ $B("(Bj8bb $B("(B\E$B $B("(B\E(B $B("(B-- $B("(B-- $B("(B\E(B $B("(B $B("(B
+ $B("(Bj8bj $B("(B\E$B $B("(B\E(J $B("(B-- $B("(B-- $B("(B\E(J $B("(Bjis8$B$HF1$8(B $B("(B
+ $B("(Bj8bh $B("(B\E$B $B("(B\E(H $B("(B-- $B("(B-- $B("(B\E(H $B("(B $B("(B
+ $B("(Bj8@b $B("(B\E@@ $B("(B\E(B $B("(B-- $B("(B-- $B("(B\E(B $B("(B $B("(B
+ $B("(Bj8@j $B("(B\E$@ $B("(B\E(J $B("(B-- $B("(B-- $B("(B\E(J $B("(B $B("(B
+ $B("(Bj8@h $B("(B\E$@ $B("(B\E(H $B("(B-- $B("(B-- $B("(B\E(H $B("(B $B("(B
+ $B("(Bjubb $B("(B\E$B $B("(B\E(B $B("(B\E(I $B("(B\E(B $B("(B\E(B $B("(B $B("(B
+ $B("(Bjubj $B("(B\E$B $B("(B\E(J $B("(B\E(I $B("(B\E(J $B("(B\E(J $B("(Bjunet$B$HF1$8(B $B("(B
+ $B("(Bjubh $B("(B\E$B $B("(B\E(H $B("(B\E(I $B("(B\E(H $B("(B\E(H $B("(B $B("(B
+ $B("(Bju@b $B("(B\E$@ $B("(B\E(B $B("(B\E(I $B("(B\E(B $B("(B\E(B $B("(B $B("(B
+ $B("(Bju@j $B("(B\E$@ $B("(B\E(J $B("(B\E(I $B("(B\E(J $B("(B\E(J $B("(B $B("(B
+ $B("(Bju@h $B("(B\E$@ $B("(B\E(H $B("(B\E(I $B("(B\E(H $B("(B\E(H $B("(B $B("(B
+ $B(&(!(!(!(*(!(!(!(!(*(!(!(!(!(*(!(!(!(!(*(!(!(!(!(*(!(!(!(!(*(!(!(!(!(!(!(!(!(!(%(B
+
+ $B$$$:$l$N>l9g$b!"$9$G$KB8:_$7$F$$$kL>A0$KBP$7$F$O!"4A;z$N3+;O=*N;%7!<%1%s%9$O!"0J2<(B
+ $B$N$b$N$rG'<1$7$^$9!#(B
+ $B4A;z$N;O$^$j(B: \E$B $B$+(B \E$@
+ $B4A;z$N=*$j(B: \E(J $B$+(B \E(B $B$+(B \E(H
+
+(2) smbclient $B$N%*%W%7%g%s(B
+
+ $B%/%i%$%"%s%H%W%m%0%i%`$G$b!"4A;z$d2>L>$r4^$s$@%U%!%$%k$r07$($k$h$&$K!"<!$N%*%W%7%g%s(B
+ $B$rDI2C$7$^$7$?!#(B
+
+ -t <$B%?!<%_%J%k%3!<%I7O(B>
+
+ $B$3$3$G!"(B<$B%?!<%_%J%k%3!<%I7O(B>$B$K;XDj$G$-$k$b$N$O!">e$N(B<$B%3!<%I7O(B>$B$HF1$8$b$N$G$9!#(B
+
+(3) $B%G%U%)%k%H(B
+
+ $B%G%U%)%k%H$N%3!<%I7O$O!"%3%s%Q%$%k;~$K7h$^$j$^$9!#(B
+
+3. $B%3%s%Q%$%k;~$N@_Dj(B
+
+ Makefile $B$K@_Dj$9$k9`L\$r0J2<$K<($7$^$9!#(B
+
+(1) KANJI $B%U%i%0(B
+
+ $B%3%s%Q%$%k%*%W%7%g%s$K(B -DKANJI=\"$B%3!<%I7O(B\" $B$r;XDj$7$^$9!#$3$N%3!<%I7O$O(B 2. $B$G;X(B
+ $BDj$9$k$b$N$HF1$8$G$9!#Nc$($P!"(B-DKANJI=\"euc\" $B$r(BFLAGSM $B$K@_Dj$9$k$H(B UNIX $B>e$N%U%!(B
+ $B%$%kL>$O!"(BEUC $B%3!<%I$K$J$j$^$9!#$3$3$G;XDj$7$?%3!<%I7O$O!"%5!<%P5Z$S%/%i%$%"%s%H(B
+ $B%W%m%0%i%`$N%G%U%)%k%H$KCM$J$j$^$9!#(B
+
+3. $B@)8B;v9`(B
+
+(1) $B4A;z%3!<%I(B
+ smbd $B$rF0:n$5$;$k%[%9%H$N(B UNIX $B$,%5%]!<%H$7$F$$$J$$4A;z%3!<%I$O!"MxMQ$G$-$J$$$3$H$,(B
+ $B$"$j$^$9!#JQ$JF0:n$r$9$k$h$&$J$i(B hex $B$N;XDj$r$9$k$N$,NI$$$G$7$g$&!#(B
+
+(2) smbclient $B%3%^%s%I(B
+ $B%7%U%H%3!<%I$J$I$N4X78$G!"4A;z$d2>L>$r4^$s$@%U%!%$%kL>$N(B ls $B$NI=<($,Mp$l$k$3$H$,$"$j(B
+ $B$^$9!#(B
+
+(3) $B%o%$%k%I%+!<%I$K$D$$$F(B
+ $B$A$c$s$H$7$?%9%Z%C%/$,$h$/$o$+$i$J$+$C$?$N$G$9$,!"0l1~!"(BDOS/V $B$NF0:n$HF1$8F0:n$r9T$J(B
+ $B$&$h$&$K$J$C$F$$$^$9!#(B
+
+4. $B>c32Ey$N%l%]!<%H$K$D$$$F(B
+
+ $BF|K\8l$N%U%!%$%kL>$K4X$7$F!"J8;z2=$1Ey$N>c32$,$"$l$P!";d$K%l%]!<%H$7$FD:$1$l$P9,$$$G(B
+$B$9!#$?$@$7!"%*%j%8%J%k$+$i$NLdBjE@$d<ALd$K$D$$$F$O!"%*%j%8%J%k$N:n<T$XD>@\Ld$$9g$o$;$k(B
+$B$+!"$b$7$/$O%a!<%j%s%0%j%9%H$J$I$X%l%]!<%H$9$k$h$&$K$7$F2<$5$$!#(B
+
+5. $B$=$NB>(B
+
+ hex $B7A<0$NJQ49J}K!$O!"(B
+
+ $BBgLZ!wBgDM!&C^GH(B <ohki@gssm.otsuka.tsukuba.ac.jp>$B;a(B
+
+ $B$,:n$i$l$?%3!<%I$rMxMQ$7$F$$$^$9!#(B
+
+1994$BG/(B10$B7n(B28$BF|(B $BBh#1HG(B
+1995$BG/(B 8$B7n(B16$BF|(B $BBh#2HG(B
+$BF#ED(B $B?r(B fujita@ainix.isac.co.jp
+
diff --git a/docs/textdocs/README.sambatar b/docs/textdocs/README.sambatar
new file mode 100644
index 0000000000..26829952eb
--- /dev/null
+++ b/docs/textdocs/README.sambatar
@@ -0,0 +1,15 @@
+
+This is version 1.4 of my small extension to samba that allows PC shares
+to be backed up directly to a UNIX tape. It only has been tested under
+Solaris 2.3, Linux 1.1.59 and DG/UX 5.4r3.10 with version 1.9.13 of samba.
+
+See the file INSTALL for installation instructions, and
+the man page and NOTES file for some basic usage. Please let me know if you
+have any problems getting it to work under your flavour of Unix.
+
+This is only (yet another) intermediate version of sambatar.
+This version also comes with an extra gift, zen.bas, written in
+microsoft qbasic by a colleague. It is (apparently) based on a 70s
+British sci-fi series known as Blake's 7. If you have any questions
+about this program, or any suggestions (e.g. what about servillan.bas
+?), feel free to mail the author (of zen.bas) greenm@lilhd.logica.com.
diff --git a/docs/textdocs/SCO.txt b/docs/textdocs/SCO.txt
new file mode 100644
index 0000000000..1b3801471f
--- /dev/null
+++ b/docs/textdocs/SCO.txt
@@ -0,0 +1,12 @@
+There is an annoying TCPIP bug in SCO Unix. This causes orruption when
+transferring files with Samba.
+
+Geza Makay (makayg@math.u-szeged.hu) sends this information:
+
+The patch you need is UOD385 Connection Drivers SLS. It is available from
+SCO (ftp.sco.com, directory SLS, files uod385a.Z and uod385a.ltr.Z).
+
+You do not need anything else but the above patch. It installs in seconds,
+and corrected the Excel problem. We also had some other minor problems (not
+only with Samba) that disappeared by installing this patch.
+
diff --git a/docs/textdocs/SMBTAR.notes b/docs/textdocs/SMBTAR.notes
new file mode 100644
index 0000000000..a23cbf2b32
--- /dev/null
+++ b/docs/textdocs/SMBTAR.notes
@@ -0,0 +1,40 @@
+
+Intro
+-----
+
+sambatar is just a small extension to the smbclient program distributed with
+samba. A basic front end shell script, smbtar, is provided as an interface
+to the smbclient extensions.
+
+Extensions
+----------
+
+This release adds the following extensions to smbclient,
+
+tar [c|x] filename
+ creates or restores from a tar file. The tar file may be a tape
+or a unix tar file. tar's behaviour is modified with the newer and tarmode
+commands.
+
+tarmode [full|inc|reset|noreset]
+ With no arguments, tarmode prints the current tar mode (by default full,
+noreset). In full mode, every file is backed up during a tar command.
+In incremental, only files with the dos archive bit set are backed up.
+The archive bit is reset if in reset mode, or left untouched if in noreset.
+In reset mode, the share has to be writable, which makes sambatar even
+less secure. An alternative might be to use tarmode inc noreset which
+would implement an "expanding incremental" backup (which some may prefer
+anyway).
+
+setmode <setmode string> filename
+ This is a "freebie" - nothing really to do with sambatar. This
+is a crude attrib like command (only the other way around). Setmode string
+is a combination of +-rhsa. So for example -rh would reset the read only
+bit on filename.
+
+newer filename
+ This is in fact part of the 1.9.13 samba distribution, but comes
+into its own with sambatar. This causes tar (or get, mget, etc) to
+only copy files newer than the specified file name. Could be used
+against the previous nights (or whatever) log file to implement incremental
+backups. \ No newline at end of file
diff --git a/docs/textdocs/Speed.txt b/docs/textdocs/Speed.txt
new file mode 100644
index 0000000000..5dfd70323b
--- /dev/null
+++ b/docs/textdocs/Speed.txt
@@ -0,0 +1,272 @@
+This file tries to outline the ways to improve the speed of a Samba server.
+
+Andrew Tridgell
+January 1995
+
+
+COMPARISONS
+-----------
+
+The Samba server uses TCP to talk to the client. Thus if you are
+trying to see if it performs well you should really compare it to
+programs that use the same protocol. The most readily available
+programs for file transfer that use TCP are ftp or another TCP based
+SMB server.
+
+If you want to test against something like a NT or WfWg server then
+you will have to disable all but TCP on either the client or
+server. Otherwise you may well be using a totally different protocol
+(such as Netbeui) and comparisons may not be valid.
+
+Generally you should find that Samba performs similarly to ftp at raw
+transfer speed. It should perform quite a bit faster than NFS,
+although this very much depends on your system.
+
+Several people have done comparisons between Samba and Novell, NFS or
+WinNT. In some cases Samba performed the best, in others the worst. I
+suspect the biggest factor is not Samba vs some other system but the
+hardware and drivers used on the various systems. Given similar
+hardware Samba should certainly be competitive in speed with other
+systems.
+
+
+SOCKET OPTIONS
+--------------
+
+There are a number of socket options that can greatly affect the
+performance of a TCP based server like Samba.
+
+The socket options that Samba uses are settable both on the command
+line with the -O option, or in the smb.conf file.
+
+The "socket options" section of the smb.conf manual page describes how
+to set these and gives recommendations.
+
+Getting the socket options right can make a big difference to your
+performance, but getting them wrong can degrade it by just as
+much. The correct settings are very dependent on your local network.
+
+The socket option TCP_NODELAY is the one that seems to make the
+biggest single difference for most networks. Many people report that
+adding "socket options = TCP_NODELAY" doubles the read performance of
+a Samba drive. The best explanation I have seen for this is that the
+Microsoft TCP/IP stack is slow in sending tcp ACKs.
+
+
+READ SIZE
+---------
+
+The option "read size" affects the overlap of disk reads/writes with
+network reads/writes. If the amount of data being transferred in
+several of the SMB commands (currently SMBwrite, SMBwriteX and
+SMBreadbraw) is larger than this value then the server begins writing
+the data before it has received the whole packet from the network, or
+in the case of SMBreadbraw, it begins writing to the network before
+all the data has been read from disk.
+
+This overlapping works best when the speeds of disk and network access
+are similar, having very little effect when the speed of one is much
+greater than the other.
+
+The default value is 16384, but very little experimentation has been
+done yet to determine the optimal value, and it is likely that the best
+value will vary greatly between systems anyway. A value over 65536 is
+pointless and will cause you to allocate memory unnecessarily.
+
+
+MAX XMIT
+--------
+
+At startup the client and server negotiate a "maximum transmit" size,
+which limits the size of nearly all SMB commands. You can set the
+maximum size that Samba will negotiate using the "max xmit = " option
+in smb.conf.
+
+It defaults to 65536 bytes (the maximum), but it is possible that some
+clients may perform better with a smaller transmit unit. Trying values
+of less than 2048 is likely to cause severe problems.
+
+In most cases the default is the best option.
+
+
+LOCKING
+-------
+
+By default Samba does not implement strict locking on each read/write
+call (although it did in previous versions). If you enable strict
+locking (using "strict locking = yes") then you may find that you
+suffer a severe performance hit on some systems.
+
+The performance hit will probably be greater on NFS mounted
+filesystems, but could be quite high even on local disks.
+
+
+SHARE MODES
+-----------
+
+Some people find that opening files is very slow. This is often
+because of the "share modes" code needed to fully implement the dos
+share modes stuff. You can disable this code using "share modes =
+no". This will gain you a lot in opening and closing files but will
+mean that (in some cases) the system won't force a second user of a
+file to open the file read-only if the first has it open
+read-write. For many applications that do their own locking this
+doesn't matter, but for some it may.
+
+LOG LEVEL
+---------
+
+If you set the log level (also known as "debug level") higher than 2
+then you may suffer a large drop in performance. This is because the
+server flushes the log file after each operation, which can be very
+expensive.
+
+
+WIDE LINKS
+----------
+
+The "wide links" option is now enabled by default, but if you disable
+it (for better security) then you may suffer a performance hit in
+resolving filenames. The performance loss is lessened if you have
+"getwd cache = yes", which is now the default.
+
+
+READ RAW
+--------
+
+The "read raw" operation is designed to be an optimised, low-latency
+file read operation. A server may choose to not support it,
+however. and Samba makes support for "read raw" optional, with it
+being enabled by default.
+
+In some cases clients don't handle "read raw" very well and actually
+get lower performance using it than they get using the conventional
+read operations.
+
+So you might like to try "read raw = no" and see what happens on your
+network. It might lower, raise or not affect your performance. Only
+testing can really tell.
+
+
+WRITE RAW
+---------
+
+The "write raw" operation is designed to be an optimised, low-latency
+file write operation. A server may choose to not support it,
+however. and Samba makes support for "write raw" optional, with it
+being enabled by default.
+
+Some machines may find "write raw" slower than normal write, in which
+case you may wish to change this option.
+
+READ PREDICTION
+---------------
+
+Samba can do read prediction on some of the SMB commands. Read
+prediction means that Samba reads some extra data on the last file it
+read while waiting for the next SMB command to arrive. It can then
+respond more quickly when the next read request arrives.
+
+This is disabled by default. You can enable it by using "read
+prediction = yes".
+
+Note that read prediction is only used on files that were opened read
+only.
+
+Read prediction should particularly help for those silly clients (such
+as "Write" under NT) which do lots of very small reads on a file.
+
+Samba will not read ahead more data than the amount specified in the
+"read size" option. It always reads ahead on 1k block boundaries.
+
+
+MEMORY MAPPING
+--------------
+
+Samba supports reading files via memory mapping them. One some
+machines this can give a large boost to performance, on others it
+makes not difference at all, and on some it may reduce performance.
+
+To enable you you have to recompile Samba with the -DUSE_MMAP=1 option
+on the FLAGS line of the Makefile.
+
+Note that memory mapping is only used on files opened read only, and
+is not used by the "read raw" operation. Thus you may find memory
+mapping is more effective if you disable "read raw" using "read raw =
+no".
+
+
+SLOW CLIENTS
+------------
+
+One person has reported that setting the protocol to COREPLUS rather
+than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).
+
+I suspect that his PC's (386sx16 based) were asking for more data than
+they could chew. I suspect a similar speed could be had by setting
+"read raw = no" and "max xmit = 2048", instead of changing the
+protocol. Lowering the "read size" might also help.
+
+
+SLOW LOGINS
+-----------
+
+Slow logins are almost always due to the password checking time. Using
+the lowest practical "password level" will improve things a lot. You
+could also enable the "UFC crypt" option in the Makefile.
+
+CLIENT TUNING
+-------------
+
+Often a speed problem can be traced to the client. The client (for
+example Windows for Workgroups) can often be tuned for better TCP
+performance.
+
+See your client docs for details. In particular, I have heard rumours
+that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a
+large impact on performance.
+
+Also note that some people have found that setting DefaultRcvWindow in
+the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a
+big improvement. I don't know why.
+
+My own experience wth DefaultRcvWindow is that I get much better
+performance with a large value (16384 or larger). Other people have
+reported that anything over 3072 slows things down enourmously. One
+person even reported a speed drop of a factor of 30 when he went from
+3072 to 8192. I don't know why.
+
+It probably depends a lot on your hardware, and the type of unix box
+you have at the other end of the link.
+
+MY RESULTS
+----------
+
+Some people want to see real numbers in a document like this, so here
+they are. I have a 486sx33 client running WfWg 3.11 with the 3.11b
+tcp/ip stack. It has a slow IDE drive and 20Mb of ram. It has a SMC
+Elite-16 ISA bus ethernet card. The only WfWg tuning I've done is to
+set DefaultRcvWindow in the [MSTCP] section of system.ini to 16384. My
+server is a 486dx3-66 running Linux. It also has 20Mb of ram and a SMC
+Elite-16 card. You can see my server config in the examples/tridge/
+subdirectory of the distribution.
+
+I get 490k/s on reading a 8Mb file with copy.
+I get 441k/s writing the same file to the samba server.
+
+Of course, there's a lot more to benchmarks than 2 raw throughput
+figures, but it gives you a ballpark figure.
+
+I've also tested Win95 and WinNT, and found WinNT gave me the best
+speed as a samba client. The fastest client of all (for me) is
+smbclient running on another linux box. Maybe I'll add those results
+here someday ...
+
+
+COMMENTS
+--------
+
+If you've read this far then please give me some feedback! Which of
+the above suggestions worked for you?
+
+Mail the samba mailing list or samba-bugs@anu.edu.au
diff --git a/docs/textdocs/Support.txt b/docs/textdocs/Support.txt
new file mode 100644
index 0000000000..d71bdaf7b3
--- /dev/null
+++ b/docs/textdocs/Support.txt
@@ -0,0 +1,376 @@
+The Samba Consultants List
+==========================
+
+This is a list of people who are prepared to install and support Samba.
+Note that in most countries nobody should admit to "supplying" Samba, since
+there is then an implied warranty with possibly onerous legal obligations.
+Just downloading and installing it isn't supply in this sense, but advertising
+"run our Samba for best results" may be so.
+
+Being on this list does not imply any sort of endorsement by anyone, it is just
+provided in the hope that it will be useful.
+
+If you want to be added to the list, or want your entry modified then
+contact the address below. They are currently listed in the
+order that they were received. If it gets too big we may organise it
+by region. Please make sure to include a header line giving the region
+and country, eg CANBERRA - AUSTRALIA.
+
+You can contact the maintainers at samba-bugs@anu.edu.au
+
+
+------------------------------------------------------------------------------
+BRISBANE - AUSTRALIA
+
+Brett Worth
+Select Computer Technology - Brisbane
+431 Logan Road
+Stones Corner QLD 4120
+E-Mail: brett@sct.com.au
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+CANBERRA - AUSTRALIA
+
+Paul Blackman (ictinus@lake.canberra.edu.au, Ph. 06 2012518) is
+available for consultation. Paul's Samba background is with
+Solaris 2.3/4 and WFWG/Win95 machines. Paul is also the maintainer
+of the SAMBA Web Pages.
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+READING - ENGLAND
+
+Philip Hands | E-Mail: info@hands.com
+Philip Hands Computing Ltd. | Tel: +44 1734 476287 Fax: 1734 474655
+Unit 1, Cherry Close, Caversham, Reading RG4 8UP UK
+
+Samba experience: SVR4,SVR3.2 & Linux <--> WfWg, W3.1, OS2 and MS-LanMan
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+ILLONOIS - USA
+
+Information One, Inc.
+736 Hinman Ave, Suite 2W
+Evanston, IL 60202
+708-328-9137 708-328-0117 FAX
+info@info1.com
+
+Providing custom Internet and networking solutions.
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+Olympic Peninsula Consulting; 1241 Lansing Ave W., Bremerton, WA 98312-4343
+telephone 1+ 360 792 6938; mailto:opc@aa.net; http://www.aa.net/~opc;
+Unix Systems and TCP/IP Network design, programming, and administration.
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+SolutionS R Us has been in business for 3+ years providing viable 3rd
+party support in system/network administration. With our own Linux
+distribution which we're constantly improving to make it the best and
+using it to provide total solutions for companies which are open to
+using Linux.
+
+Mauro DePalma <mauro@sru.com>
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+BIELEFELD - GERMANY
+
+I am located in Bielefeld/Germany and have been doing Unix consultancy
+work for the past 8 years throughout Germany and the rest of Europe. I
+can be contacted by email at <jpm@mens.de> or via phone at +49 521
+9225922 or telefax at +49 521 9225924.
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+CANBERRA - AUSTRALIA
+
+Ben Elliston
+Faculty of Information Sciences and Engineering
+University of Canberra AUSTRALIA
+E-mail: ben@ise.canberra.edu.au (Uni)
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+PALERMO - ITALY
+
+Francesco Cardinale
+E-Mail: cardinal@palermo.italtel.it
+Samba experience: SVR3.2, SOLARIS, ULTRIX, LINUX <--> DOS LAN-MAN, WFW
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+SYDNEY - AUSTRALIA
+
+John Terpstra - Aquasoft (jht@aquasoft.com.au)
+Business: +612 524 4040
+Home: +612 540 3154
+Shoephone: +612 414 334422 (aka 0414 334422)
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+ONTARIO - CANADA
+
+Strata Software Limited, Kanata Ontario CANADA
+Tel: +1 (613) 591-1922 Fax: +1 (613) 591-3485
+Email: sales@strataware.com WWW: http://www.strataware.com/
+
+Strata Software Limited is a software development and consulting group
+specializing in data communications (TCP/IP and OSI), X.400, X.500 and
+LDAP, and X.509-based security. We have Samba experience with Windows NT,
+Windows 95, and Windows for Workgroups clients with Linux, Unixware
+(SVR4), and HP-UX servers.
+------------------------------------------------------------------------------
+
+-----------------------------------------------------------------------
+SYDNEY - AUSTRALIA
+
+We are a Unix & Windows developer with a consulting & support component.
+In business since 1981 with experience on Sun, hp, sgi, IBM rs6000 plus
+Windows, NT and Win95, Using Samba since September 94.
+CodeSmiths, 22 Darley Road, MANLY 2095 NSW; 977 1979; fax: 977 2116
+philm@esi.com.au (Australia; New South Wales; SYDNEY; North East)
+-----------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+EDINBUGH - SCOTLAND
+
+Charlie Hussey email charlie@edina.demon.co.uk
+Edina Software Limited tel 0131 657 1129
+4 James Street fax 0131 669 9092
+Edinburgh EH15 2DS
+
+SAMBA experience: SCO UNIX <=> WfWg
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+LONDON - ENGLAND
+
+Mark H. Preston,
+Network Analyst, | Email : mpreston@sghms.ac.uk
+Computer Unit, | Tel : +44 (0)181 725-5434
+St. George's Hospital Med School, | Fax : +44 (0)181 725-3583
+London SW17 ORE. | WWW : http://www.sghms.ac.uk
+
+Samba Experience:
+Server: Solaris 2.3 & 2.4, Irix 5.2 & 5.3
+Client: WinNT, Win95, WfWg, Win3.1, Ms-LanMan, DHCP support
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+SYDNEY - AUSTRALIA
+
+Pacific ESI has used and installed Samba since 1.6 on a range
+of machines running SunOS, BSD/OS, SCO/UNIX, HP/UX, and Solaris,
+and WfWG and Windows95. The largest system worked on to date
+involved an Australia wide network of machines with PCs and SUNs
+at the various nodes. The in-house testing site is a wide area
+network with three sites, remotely connected with PPP and with
+SUN servers at each site to all of which are connected several
+PCs running mainly WfWG.
+
+Stefan Kjellberg Pacific Engineering Systems
+International
+info@eram.esi.com.au Voice:+61-2-9063377
+... Fax:+61-2-9063468
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+CHANTILLY - USA
+
+Intelligent Decisions, Inc.
+ATTN: Richard Bullington
+14121 Parke Long Ct. #104
+Chantilly, VA 22021
+U.S.A.
+(703) 803-8070
+rbullington@intdec.com
+
+Samba experience: Linux, DEC ULTRIX <=> WFWG 3.11, Windows NT 3.5
+Specializing in World Wide Web related UNIX-to-PC connectivity.
+------------------------------------------------------------------------------
+
+------------------------------------------------------------------------------
+FORT COLLINS, CO - USA
+
+Granite Computing Solutions
+ATTN: Brian Grossman
+Box 270103
+Fort Collins, CO 80527-0103
+U.S.A.
+(970) 225-2370
+granite@fortnet.org
+
+Information services, including WfWG, NT, Apple <=> Unix interoperability.
+
+Our standard advertisement says:
+
+> Unix workstations, servers and custom systems <
+>> WWW and Unix education <<
+>>> Enterprise and departmental computing solutions <<<
+>>> Backup & restore <<<
+>> Software forensics <<
+> Data translation <
+------------------------------------------------------------------------------
+
+----------------------------------------------------------
+Adelaide, Australia
+
+NS Computer Software and Services P/L
+PO Box 86
+Ingle Farm
+SA 5098
+
+Contact: Richard Sharpe
+ Ph: +61-8-281-0063 (08-281-0063) AH
+ FAX:+61-8-250-2080 (08-250-2080)
+
+Experience with: ULTRIX, Digital UNIX, SunOS, WfW 3.11, Win95, WNT 3.51
+
+----------------------------------------------------------
+
+----------------------------------------------------------
+TECTONIC LIMITED
+WESTWOOD
+78 LOUGHBOROUGH ROAD
+QUORN
+LEICESTERSHIRE
+LE12 8DX
+
+TELEPHONE 01509-620922
+FAX 01509-620933
+
+CONTACT DAVID ROBINSON
+
+WE ARE UNIX ORIENTATED BUT ALSO SPECIALISE IN PC TO UNIX COMMUNICATIONS, WE
+KNOW AND UNDERSTAND PC-NFS, (HENCE OUR INTEREST IN SAMBA).
+WE SUPPORT SUNOS, SOLARIS 1.X AND 2.X, HP-UX 9.0 AND 10.0, OSF (or DEC UNIX,
+whichever you prefer), WinNT, WfWG and Win95.
+
+WE ARE ALREADY TALKING TO A COUPLE OF VERY LARGE SAMBA USERS HERE IN THE UK.
+WE WOULD LIKE TO SUPPORT THEM (AND MANY MORE), WOULD YOU PLEASE CONTACT ME ON:
+david@tectonic.demon.co.uk
+----------------------------------------------------------
+
+----------------------------------------------------------
+MIAMI, FL - USA
+
+Swaney & Associates, Inc.
+ATTN: Stephen Swaney
+ 2543 Lincoln Avenue
+ Miami, Florida 33133
+ U.S.A
+ (305) 860-0570
+
+Specializing in:
+ High Availability system & networks
+ UNIX to PC connectivity
+ Market Data systems
+ Messaging Systems (Sendmail & Microsoft Exchange)
+----------------------------------------------------------
+
+------------------------------------------------------------------------------
+NEW JERSEY - USA
+
+William J. Maggio
+LAN & Computer Integrators, Inc.
+242 Old New Brunswick Road Email: bmaggio@lci.com
+Suite 440 Voice: 908-981-1991
+Piscataway, NJ 08855 Fax : 908-981-1858
+
+ Specializing in Internet connectivity and security, Sun integration and
+ high speed, enterprise network design and deployment.
+------------------------------------------------------------------------------
+
+FAREHAM - ENGLAND
+
+High Field Technology Ltd
+Little Park Farm Road, Segensworth West,
+Fareham, Hants PO15 5SJ, UK.
+sales@hft.co.uk tel +44 148 957 0111 fax +44 148 957 0555
+
+Company skills: Real time hardware and software systems
+
+Samba experience: BSD/OS, Linux, LynxOS <==> WFWG, NT
+
+------------------------------------------------------------------------------
+
+-----------------------------------------------------------------------
+QUEBEC - CANADA
+
+Dataden Computer Systems
+Attn: Danny Arseneau
+arseneau@parkmed.com
+895 2nd Avenue
+Ile Bizard, Quebec
+Canada, H9C 1K3
+Tel: (514)891-2293
+Fax: (514)696-0848
+
+Dataden is company that specializes in Unix--TCP/IP networking.
+We have over 15 years of experience. We have been installing,
+configuring and maintaining Samba for clients for 1-1/2 years now. We
+have samba installations on Linx, SunOS and DEC OSF. Our biggest site
+has 4 Suns and 3 Linux servers running Samba which are serving a network
+of about 50 PC's running WFWg and Win95.
+-----------------------------------------------------------------------
+
+-----------------------------------------------------------------------
+CALIFORNIA - USA
+
+Ron Halstead
+Open Systems Consulting
+3098-4 Lakemont Drive
+San Ramon, CA 94583 (San Francisco Bay Area)
+(510) 735-7529
+halstead@ix.netcom.com
+-----------------------------------------------------------------------
+
+
+-----------------------------------------------------------------------
+MELBOURNE - AUSTRALIA
+
+Michael Ciavarella
+Cybersoruce Pty Ltd.
+8/140 Queen Street
+Melbourne VIC 3000
+Phone: +61-3-9642-5997
+Fax: +61-3-9642-5998
+Email: mikec@cyber.com.au
+WWW: http://www.cyber.com.au
+
+Cybersource specialises in TCP/IP network integration and Open Systems
+administration. Cybersource is an Australian-owned and operated
+company, with clients including some of Australia's largest financial,
+petrochemical and state government organisations.
+-----------------------------------------------------------------------
+
+-----------------------------------------------------------------------
+SOUTHERN CALIFORNIA - USA
+
+Michael St. Laurent
+Serving Los Angeles and Orange Counties. Please contact via email.
+rowl@earthlink.net
+Michael St. Laurent
+Hartwell Corporation
+------------------------------------------------------------------------------
+WASHINGTON DC METRO - USA
+
+Asset Software, Inc. has been running Samba since the 1.6 release on various
+platforms, including SunOS 4.x, Solaris 2.x, IRIX 4.x and 5.x, Linux 1.1x,
+1.2x, and 1.3x, and BSD UNIX 4.3 and above. We specialize in small office
+network solutions and provide services to enhance a small office's
+operations. Primarily a custom software operation, our vast knowledge of
+Windows, DOS, Unix, Windows NT, MacOS, and OS/2 enable us to provide quality
+technical assistance to the small office environment at a reasonable price.
+Our upcoming multi-mailbox mail client, IQ Mail, enables users with more
+than one mailbox to send and retrieve their mail from a single, consistent
+mail client running in Windows.
+
+David J. Fenwick Asset Software, Inc.
+President djf@assetsw.com
+------------------------------------------------------------------------------
+
diff --git a/docs/textdocs/UNIX-SMB.txt b/docs/textdocs/UNIX-SMB.txt
new file mode 100644
index 0000000000..b2c064215c
--- /dev/null
+++ b/docs/textdocs/UNIX-SMB.txt
@@ -0,0 +1,220 @@
+This is a short document that describes some of the issues that
+confront a SMB implementation on unix, and how Samba copes with
+them. They may help people who are looking at unix<->PC
+interoperability.
+
+It was written to help out a person who was writing a paper on unix to
+PC connectivity.
+
+Andrew Tridgell
+April 1995
+
+
+Usernames
+=========
+
+The SMB protocol has only a loose username concept. Early SMB
+protocols (such as CORE and COREPLUS) have no username concept at
+all. Even in later protocols clients often attempt operations
+(particularly printer operations) without first validating a username
+on the server.
+
+Unix security is based around username/password pairs. A unix box
+should not allow clients to do any substantive operation without some
+sort of validation.
+
+The problem mostly manifests itself when the unix server is in "share
+level" security mode. This is the default mode as the alternative
+"user level" security mode usually forces a client to connect to the
+server as the same user for each connected share, which is
+inconvenient in many sites.
+
+In "share level" security the client normally gives a username in the
+"session setup" protocol, but does not supply an accompanying
+password. The client then connects to resources using the "tree
+connect" protocol, and supplies a password. The problem is that the
+user on the PC types the username and the password in different
+contexts, unaware that they need to go together to give access to the
+server. The username is normally the one the user typed in when they
+"logged onto" the PC (this assumes Windows for Workgroups). The
+password is the one they chose when connecting to the disk or printer.
+
+The user often chooses a totally different username for their login as
+for the drive connection. Often they also want to access different
+drives as different usernames. The unix server needs some way of
+divining the correct username to combine with each password.
+
+Samba tries to avoid this problem using several methods. These succeed
+in the vast majority of cases. The methods include username maps, the
+service%user syntax, the saving of session setup usernames for later
+validation and the derivation of the username from the service name
+(either directly or via the user= option).
+
+File Ownership
+==============
+
+The commonly used SMB protocols have no way of saying "you can't do
+that because you don't own the file". They have, in fact, no concept
+of file ownership at all.
+
+This brings up all sorts of interesting problems. For example, when
+you copy a file to a unix drive, and the file is world writeable but
+owned by another user the file will transfer correctly but will
+receive the wrong date. This is because the utime() call under unix
+only succeeds for the owner of the file, or root, even if the file is
+world writeable. For security reasons Samba does all file operations
+as the validated user, not root, so the utime() fails. This can stuff
+up shared development diectories as programs like "make" will not get
+file time comparisons right.
+
+There are several possible solutions to this problem, including
+username mapping, and forcing a specific username for particular
+shares.
+
+Passwords
+=========
+
+Many SMB clients uppercase passwords before sending them. I have no
+idea why they do this. Interestingly WfWg uppercases the password only
+if the server is running a protocol greater than COREPLUS, so
+obviously it isn't just the data entry routines that are to blame.
+
+Unix passwords are case sensitive. So if users use mixed case
+passwords they are in trouble.
+
+Samba can try to cope with this by either using the "password level"
+option which causes Samba to try the offered password with up to the
+specified number of case changes, or by using the "password server"
+option which allows Samba to do it's validation via another machine
+(typically a WinNT server).
+
+Samba also doesn't support the password encryption method used by SMB
+clients. This is because the spec isn't sufficiently detailed for an
+implementation (although Jeremy Allison is working on it, to try and
+work it out). Also, there is a fundamental problem with what we
+understand so far in the algorithm, as it seems that the server would
+need to store somewhere on disk a reversibly encrypted (effectively
+plaintext) copy of the users password in order to use the
+algorithm. This goes against the unix policy that "even the super-user
+doesn't know your password" which comes from the use of a one-way hash
+function.
+
+Locking
+=======
+
+The locking calls available under a DOS/Windows environment are much
+richer than those available in unix. This means a unix server (like
+Samba) choosing to use the standard fcntl() based unix locking calls
+to implement SMB locking has to improvise a bit.
+
+One major problem is that dos locks can be in a 32 bit (unsigned)
+range. Unix locking calls are 32 bits, but are signed, giving only a 31
+bit range. Unfortunately OLE2 clients use the top bit to select a
+locking range used for OLE semaphores.
+
+To work around this problem Samba compresses the 32 bit range into 31
+bits by appropriate bit shifting. This seems to work but is not
+ideal. In a future version a separate SMB lockd may be added to cope
+with the problem.
+
+It also doesn't help that many unix lockd daemons are very buggy and
+crash at the slightest provocation. They normally go mostly unused in
+a unix environment because few unix programs use byte range
+locking. The stress of huge numbers of lock requests from dos/windows
+clients can kill the daemon on some systems.
+
+The second major problem is the "opportunistic locking" requested by
+some clients. If a client requests opportunistic locking then it is
+asking the server to notify it if anyone else tries to do something on
+the same file, at which time the client will say if it is willing to
+give up it's lock. Unix has no simple way of implementing
+opportunistic locking, and currently Samba has no support for it.
+
+Deny Modes
+==========
+
+When a SMB client opens a file it asks for a particular "deny mode" to
+be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE,
+DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be
+allowed by anyone else who tries to use the file at the same time. If
+DENY_READ is placed on the file, for example, then any attempt to open
+the file for reading should fail.
+
+Unix has no equivalent notion. To implement these Samba uses lock
+files based on the files inode and placed in a separate lock
+directory. These are clumsy and consume processing and file resources,
+so they are optional and off by default.
+
+Trapdoor UIDs
+=============
+
+A SMB session can run with several uids on the one socket. This
+happens when a user connects to two shares with different
+usernames. To cope with this the unix server needs to switch uids
+within the one process. On some unixes (such as SCO) this is not
+possible. This means that on those unixes the client is restricted to
+a single uid.
+
+Port numbers
+============
+
+There is a convention that clients on sockets use high "unprivilaged"
+port numbers (>1000) and connect to servers on low "privilaged" port
+numbers. This is enforced in Unix as non-root users can't open a
+socket for listening on port numbers less than 1000.
+
+Most PC based SMB clients (such as WfWg and WinNT) don't follow this
+convention completely. The main culprit is the netbios nameserving on
+udp port 137. Name query requests come from a source port of 137. This
+is a problem when you combine it with the common firewalling technique
+of not allowing incoming packets on low port numbers. This means that
+these clients can't query a netbios nameserver on the other side of a
+low port based firewall.
+
+The problem is more severe with netbios node status queries. I've
+found that WfWg, Win95 and WinNT3.5 all respond to netbios node status
+queries on port 137 no matter what the source port was in the
+request. This works between machines that are both using port 137, but
+it means it's not possible for a unix user to do a node status request
+to any of these OSes unless they are running as root. The answer comes
+back, but it goes to port 137 which the unix user can't listen
+on. Interestingly WinNT3.1 got this right - it sends node status
+responses back to the source port in the request.
+
+
+Protocol Complexity
+===================
+
+There are many "protocol levels" in the SMB protocol. It seems that
+each time new functionality was added to a Microsoft operating system,
+they added the equivalent functions in a new protocol level of the SMB
+protocol to "externalise" the new capabilities.
+
+This means the protocol is very "rich", offering many ways of doing
+each file operation. This means SMB servers need to be complex and
+large. It also means it is very difficult to make them bug free. It is
+not just Samba that suffers from this problem, other servers such as
+WinNT don't support every variation of every call and it has almost
+certainly been a headache for MS developers to support the myriad of
+SMB calls that are available.
+
+There are about 65 "top level" operations in the SMB protocol (things
+like SMBread and SMBwrite). Some of these include hundreds of
+sub-functions (SMBtrans has at least 120 sub-functions, like
+DosPrintQAdd and NetSessionEnum). All of them take several options
+that can change the way they work. Many take dozens of possible
+"information levels" that change the structures that need to be
+returned. Samba supports all but 2 of the "top level" functions. It
+supports only 8 (so far) of the SMBtrans sub-functions. Even NT
+doesn't support them all.
+
+Samba currently supports up to the "NT LM 0.12" protocol, which is the
+one preferred by Win95 and WinNT3.5. Luckily this protocol level has a
+"capabilities" field which specifies which super-duper new-fangled
+options the server suports. This helps to make the implementation of
+this protocol level much easier.
+
+There is also a problem with the SMB specications. SMB is a X/Open
+spec, but the X/Open book is far from ideal, and fails to cover many
+important issues, leaving much to the imagination.
+
diff --git a/docs/textdocs/WinNT.txt b/docs/textdocs/WinNT.txt
new file mode 100644
index 0000000000..b57abb7742
--- /dev/null
+++ b/docs/textdocs/WinNT.txt
@@ -0,0 +1,56 @@
+There are some particular issues with Samba and Windows NT
+
+=====================================================================
+One of the most annoying problems with WinNT is that NT refuses to
+connect to a server that is in user level security mode and that
+doesn't support password encryption unless it first prompts the user
+for a password.
+
+This means even if you have the same password on the NT box and the
+Samba server you will get prompted for a password. Entering the
+correct password will get you connected.
+
+The other major ramification of this feature of NT is that it can't
+browse a user level non-encrypted server unless it already has a
+connection open. This is because there is no spot for a password
+prompt in the browser window. It works fine if you already have a
+drive mounted (for example, one auto mounted on startup).
+
+Samba should support encrypted passwords soon, which will solve this
+problem.
+=====================================================================
+
+
+
+=====================================================================
+When you mount a printer using the print manager in NT you may find
+the following info from Matthew Harrell <harrell@leech.nrl.navy.mil>
+useful:
+
+------------
+ I noticed in your change-log you noted that some people were
+still unable to use print manager under NT. If this is the same problem
+that I encountered, it's caused by the length of time it takes NT to
+determine if the printer is ready.
+
+The problem occurs when you double-click on a printer to connect it to
+the NT machine. Because it's unable to determine if the printer is ready
+in the short span of time it has, it assumes it isn't and gives some
+strange error about not having enough resources (I forget what the error
+is). A solution to this that seems to work fine for us is to click
+once on the printer, look at the bottom of the window and wait until
+it says it's ready, then clilck on "OK".
+
+By the way, this problem probably occurs in our group because the
+Samba server doesn't actually have the printers - it queues them to
+remote printers either on other machines or using their own network
+cards. Because of this "middle layer", it takes an extra amount of
+time for the NT machine to get verification that the printer queue
+actually exists.
+
+I hope this helped in some way...
+-----------
+=====================================================================
+
+
+