Fixing Oops. Thought I had added these - but not!

2 files changed, 309 insertions, 0 deletions

diff --git a/docs/textdocs/Macintosh_Clients.txt b/docs/textdocs/Macintosh_Clients.txt
new file mode 100644
index 00000000000..dfac97e1aa2
--- /dev/null
+++ b/docs/textdocs/Macintosh_Clients.txt
@@ -0,0 +1,23 @@
+> Are there any Macintosh clients for Samba?
+
+Yes. Thursby now have a CIFS Client / Server called DAVE - see
+http://www.thursby.com/
+
+They test it against Windows 95, Windows NT and samba for
+compatibility issues.  At the time of writing, DAVE was at version
+1.0.1. The 1.0.0 to 1.0.1 update is available as a free download from
+the Thursby web site (the speed of finder copies has been greatly
+enhanced, and there are bug-fixes included).
+
+Alternatives - There are two free implementations of AppleTalk for
+several kinds of UNIX machnes, and several more commercial ones.
+These products allow you to run file services and print services
+natively to Macintosh users, with no additional support required on
+the Macintosh.  The two free omplementations are Netatalk,
+http://www.umich.edu/~rsug/netatalk/, and CAP,
+http://www.cs.mu.oz.au/appletalk/atalk.html.  What Samba offers MS
+Windows users, these packages offer to Macs.  For more info on these
+packages, Samba, and Linux (and other UNIX-based systems) see
+http://www.eats.com/linux_mac_win.html
+
+
diff --git a/docs/textdocs/Recent-FAQs.txt b/docs/textdocs/Recent-FAQs.txt
new file mode 100644
index 00000000000..8f2b50bf6c6
--- /dev/null
+++ b/docs/textdocs/Recent-FAQs.txt
@@ -0,0 +1,286 @@
+Contributor:	Samba-bugs@samba.anu.edu.au
+Date:		July 5, 1998
+Status:		Current
+
+=============================================================================
+Subject: Recent FAQ answers to common questions / problems
+=============================================================================
+Contents:	NetWkstaUserLogon
+		Not listening for calling name
+		System Error 1240
+		Trapdoor UID
+		User Access Control
+		Using NT to Browse Samba Shares
+		setup.exe and 16 bit programs
+		smbclient -N
+
+NetWkstaUserLogon
+=================
+FAQ answer about the new password server code:
+
+In 1.9.18 you can disable the NetWkstaUserLogon call at compile time
+in local.h and from 1.9.18p3 you can now disable it from an option in
+your smb.conf.
+
+The password server behaviour changed because we discovered that bugs
+in some NT servers allowed anyone to login with no password if they
+chose an account name that did not exist on the password server. The 
+NT password server was saying "yes, it's OK to login" even when the 
+account didn't exist at all! Adding the NetWkstaUserLogon call fixed 
+the problem, and follows the "recommended" method that MS have 
+recently documented for pass through authentication.
+
+The problem now is that some NT servers (in particular NT
+workstation?) don't support the NetWkstaUserLogon call. The call also
+doesn't work for accounts in trust relationships.
+
+The eventual solution for this will be to replace the password server
+code in Samba with NT domain code as that is developed. For now you 
+have the choice of compiling Samba either with or without the 
+NetWkstaUserLogon call in the password server code.
+
+In 1.9.18p3 the following was added (copied from the 1.9.18p3 release
+notes):
+
+In the [global] section of smb.conf :
+
+networkstation user login
+
+This code (submitted by Rob Nielsen) allows the code many people 
+were having problems with that queries an NT password server to 
+be turned off at runtime rather than compile time. Please see the 
+documentation in the smb.conf manual page for details. This is a 
+security option - it must only be turned off after checks have been
+made to ensure that your NT password server does not suffer from the
+bug this code was meant to protect against !
+
+In 1.9.18 you can enable/disable this call in local.h. In 1.9.17p5
+you could apply the following patch. Applying this patch will make
+the password server code behave like the code in earlier versions
+of Samba. If you do this then please ensure that you test to see
+that users are prevented from logging in if they give a bogus 
+username/password. You may have a NT server that is affected by the
+bug that this code is designed to avoid.
+
+
+--- password.c	1997/10/21 10:09:28	1.25.2.4
++++ password.c	1997/12/31 06:43:06
+@@ -1619,6 +1619,7 @@
+ 	}
+ 
+ 
++#if 0
+ 	if (!cli_NetWkstaUserLogon(&cli,user,local_machine)) {
+ 		DEBUG(1,("password server %s failed NetWkstaUserLogon\n", cli.desthost));
+ 		cli_tdis(&cli);
+@@ -1638,6 +1639,7 @@
+ 		cli_tdis(&cli);
+ 		return False;
+ 	}
++#endif
+ 
+ 	DEBUG(3,("password server %s accepted the password\n", cli.desthost));
+===============================================================================
+
+Not listening for calling name
+==============================
+
+> Session request failed (131,129) with myname=HOBBES destname=CALVIN
+> Not listening for calling name
+
+If you get this when talking to a Samba box then it means that your
+global "hosts allow" or "hosts deny" settings are causing the Samba 
+server to refuse the connection. 
+
+Look carefully at your "hosts allow" and "hosts deny" lines in the
+global section of smb.conf. 
+
+It can also be a problem with reverse DNS lookups not functioning 
+correctly, leading to the remote host identity not being able to
+be confirmed, but that is less likely.
+===============================================================================
+
+System Error 1240
+=================
+System error 1240 means that the client is refusing to talk
+to a non-encrypting server. Microsoft changed WinNT in service
+pack 3 to refuse to connect to servers that do not support
+SMB password encryption.
+
+There are two main solutions:
+
+1) enable SMB password encryption in Samba. See ENCRYPTION.txt in the 
+Samba docs
+
+2) disable this new behaviour in NT. See WinNT.txt in the 
+Samba docs
+===============================================================================
+
+Trapdoor UID
+============
+> Log message "you appear to have a trapdoor uid system" 
+
+This can have several causes. It might be because you are using a uid
+or gid of 65535 or -1. This is a VERY bad idea, and is a big security
+hole. Check carefully in your /etc/passwd file and make sure that no
+user has uid 65535 or -1. Especially check the "nobody" user, as many
+broken systems are shipped with nobody setup with a uid of 65535.
+
+It might also mean that your OS has a trapdoor uid/gid system :-)
+
+This means that once a process changes effective uid from root to
+another user it can't go back to root. Unfortunately Samba relies on
+being able to change effective uid from root to non-root and back
+again to implement its security policy. If your OS has a trapdoor uid
+system this won't work, and several things in Samba may break. Less
+things will break if you use user or server level security instead of
+the default share level security, but you may still strike
+problems.
+
+The problems don't give rise to any security holes, so don't panic,
+but it does mean some of Samba's capabilities will be unavailable.
+In particular you will not be able to connect to the Samba server as
+two different uids at once. This may happen if you try to print as a
+"guest" while accessing a share as a normal user. It may also affect
+your ability to list the available shares as this is normally done as
+the guest user.
+
+Complain to your OS vendor and ask them to fix their system.
+
+Note: the reason why 65535 is a VERY bad choice of uid and gid is that
+it casts to -1 as a uid, and the setreuid() system call ignores (with
+no error) uid changes to -1. This means any daemon attempting to run
+as uid 65535 will actually run as root. This is not good!
+===============================================================================
+
+User Access Control
+===================
+> In windows when i set up a share in "user mode" i get the message:
+>  "You cannot view the list of users at this time. Please try again later."
+> 
+> I know you have lists of users for access and aliasing purposes, but i
+> have read nothing to support the idea that these lists control the Domain
+> Users List...
+
+Samba does NOT at this time support user mode access control for Window 9x
+of for NT. This is a priority item and requires full implementation of the NT SMB 
+protocol calls. Samba-1.9.19 will go into alpha in about 2 months time and will
+have a more full implementation of the NT SMB protocols to support Domain Client
+interoperability. When we can see that this has been succesful we wil then implement
+the NT SMB Server components. This will probably be released as Samba-2.0
+
+Samba-1.9.18p5 is scheduled to go out within 14 days. This will close off the 1.9.18
+branch and then opens the way to progress 1.9.19.
+
+I hope this answers your concerns adequately.
+===============================================================================
+
+Using NT to Browse Samba Shares
+===============================
+> WIN-NT workstations (nt4.0, service pack 3) 
+> samba with
+>   security = user
+>   encrypt passwords = yes
+>   guest account = guest
+> 
+> start the explorer on a win-nt workstation and select network. I find
+> my unix server running samba, but I can not see the list of shares 
+> unless I am  a user, who is known in the smbpasswd of the unix machine.
+> The guest account "guest" exists on my unix machine. For testing I even
+> made him a regular user with a password.
+>
+> With my network monitor I can see, that the win-nt workstation uses the
+> current login, to connect to IPC$ on the samba server 
+> (for example "administrator"), not the guest account.
+
+This is exactly how Windows NT works. You MUST have a valid account on the Windows
+NT box you are trying to see the resource list on. If your currently logged in
+account details do NOT match an account on the NT machine you are trying to access
+then you will be presented with a logon box for that machine. When you enter the
+name of an account on that machine / domain, together with a valid password then
+the resource list is made available. If the account details are not correct then
+no resource list is shown.
+
+Samba follows the behaviour of Windows NT exactly.
+
+Warning:Warning:Warning:
+========================
+Samba can be compiled with the GUEST_SESSION_SETUP option at 0,1 or 2.
+The default is 0. If this is set to 1 or 2 then Windows NT machines that DO NOT
+have an account on the Samba server will see the resource list. The down side of this
+is that legitimate users may then be refused access to their legitimate resources.
+Setting this option creates serious security holes. DO NOT DO IT. Samba has the
+value of this option set at 0 - NOT WITHOUT REASON!!!!
+
+******> Warning:Warning:Warning: ****> Do not tamper with this setting!!!
+===============================================================================
+
+setup.exe and 16 bit programs
+=============================
+Running 16 bit programs from Windows NT on a Samba mapped drive
+---------------------------------------------------------------
+
+The Windows NT redirector has a bug when running against a 
+Samba or Windows 95 mapped drive and attempting to run a
+16 bit executable.
+
+The problem occurs when the pathname to a 16 bit executable
+contains a non 8.3 filename complient directory component,
+Windows NT will fail to load the program and complain it
+cannot find the path to the program.
+
+It can be verified that this is a bug in Windows NT and
+not Samba as the same problem can be reproduced exactly
+when attempting to run the same program with the same
+pathname from a Windows 95 server (ie. the problem still
+exists even with no Samba server involved).
+
+Microsoft have been made aware of this problem, it is
+unknown if they regard it as serious enough to provide
+a fix for this.
+
+One of the reasons this problem is reported frequently
+is that InstallShield setup.exe executables are frequently
+written as 16 bit programs, and so hit this problem.
+
+As a workaround, you may create (on a Samba server at
+least) a symbolic link with an 8.3 complient name to 
+the non 8.3 complient directory name, and then the 16
+bit program will run. Alternatively, use the 8.3
+complient mangled name to specify the path to run
+the binary.
+
+This will be fixed when Samba adds the NT-specific
+SMB calls (currently targeted for the next major
+Samba release), as once the NT SMB calls are used
+this problem no longer occurs (which is why the
+problem doesn't occur when running against a drive
+mapped to a Windows NT server).
+
+Regards,
+
+	Jeremy Allison.
+	Samba Team.
+===============================================================================
+
+smbclient -N
+============
+> When getting the list of shares available on a host using the command
+>   smbclient -N -L <server>
+> the program always prompts for the password if the server is a Samba server.
+> It also ignores the "-N" argument when querying some (but not all) of our
+> NT servers.
+
+No, it does not ignore -N, it is just that your server rejected the 
+null password in the connection, so smbclient prompts for a password
+to try again.
+
+To get the behaviour that you probably want use 
+	smbclient -L host -U%
+
+this will set both the username and password to null, which is
+an anonymous login for SMB. Using -N would only set the password
+to null, and this is not accepted as an anonymous login for most
+SMB servers.
+===============================================================================
+