added info about _not_ using \\SAMBA_SERVER\HOMES\profile - must use

\\SAMBA_SERVER\%U\profile for the profile path.  documented default
profile path changing to \\%L\%U\profile, so that w95 and NT can use
the same profile directory: you cannot use \\%L\%U for NT profiles.

lkcl
(This used to be commit 588039b6dfd1397532ef8969fb5f2bb3aafbddde)

2 files changed, 27 insertions, 26 deletions

diff --git a/docs/manpages/smb.conf.5 b/docs/manpages/smb.conf.5
index 1eed1fcd86..a0a96f26ff 100644
--- a/docs/manpages/smb.conf.5
+++ b/docs/manpages/smb.conf.5
@@ -1585,7 +1585,7 @@ see "debug level"
 .SS logon path (G)
 
 This parameter specifies the home directory where roaming profiles 
-(USER.DAT / USER.MAN files) are stored.
+(USER.DAT / USER.MAN files for Windows 95) are stored.
 
 This option takes the standard substitutions, allowing you to have
 separate logon scripts for each user or machine.  It also specifies
@@ -1603,11 +1603,16 @@ be made read-only.  It is not adviseable that the USER.DAT file be made
 read-only - rename it to USER.MAN to achieve the desired effect
 (a MANdatory profile).
 
+Windows clients can sometimes maintain a connection to the [homes]
+share, even though there is no user logged in.  Therefore, it is
+vital that the logon path does not include a reference to the
+homes share (i.e \\\\%L\\HOMES\profile_path will cause problems).
+
 .B Default:
- 	logon path = \\\\%L\\%U 
+ 	logon path = \\\\%L\\%U\\profile
 
 .B Example:
-	logon path = \\\\PROFILESERVER\\HOME_DIR\\%U
+	logon path = \\\\PROFILESERVER\\HOME_DIR\\%U\\PROFILE
 
 .SS logon script (G)
 
diff --git a/docs/textdocs/DOMAIN.txt b/docs/textdocs/DOMAIN.txt
index 547e1b6cf8..3cd8a125b7 100644
--- a/docs/textdocs/DOMAIN.txt
+++ b/docs/textdocs/DOMAIN.txt
@@ -1,30 +1,21 @@
 Contributor:	Samba Team
-Updated:	August 25, 1997
+Updated:	June 27, 1997
 
 Subject:	Network Logons and Roving Profiles
 ===========================================================================
 
 A domain and a workgroup are exactly the same thing in terms of network
-traffic, except for the client logon sequence. Some kind of distributed
-authentication database is associated with a domain (there are quite a few
-choices) and this adds so much flexibility that many people think of a
-domain as a completely different entity to a workgroup. From Samba's 
-point of view a client connecting to a service presents an authentication
-token, and it if it is valid they have access. Samba does not care what
-mechanism was used to generate that token in the first place.
+browsing.  The difference is that a distributable authentication
+database is associated with a domain, for secure login access to a
+network.  Also, different access rights can be granted to users if they
+successfully authenticate against a domain logon server (samba does not
+support this, but NT server and other systems based on NT server do).
 
 The SMB client logging on to a domain has an expectation that every other
 server in the domain should accept the same authentication information.
 However the network browsing functionality of domains and workgroups is
 identical and is explained in BROWSING.txt.
 
-There are some implementation differences: Windows 95 can be a member of
-both a workgroup and a domain, but Windows NT cannot. Windows 95 also
-has the concept of an "alternative workgroup". Samba can only be a
-member of a single workgroup or domain, although this is due to change
-with a future version when nmbd will be split into two daemons, one
-for WINS and the other for browsing (NetBIOS.txt explains what WINS is.)
-
 Issues related to the single-logon network model are discussed in this
 document.  Samba supports domain logons, network logon scripts, and user
 profiles.  The support is still experimental, but it seems to work.
@@ -32,10 +23,8 @@ profiles.  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 Windows NT-style SAM database with other systems.  However this is
 only one way of having a shared user database: exactly the same effect can
-be achieved by having all servers in a domain share a distributed NIS,
-Kerberos or other authentication database. These other options may or may
-not involve changes to the client software, that depends on the combination
-of client OS, server OS and authentication protocol.
+be achieved by having all servers in a domain share a distributed NIS or
+Kerberos authentication database.
 
 When an SMB client in a domain wishes to logon it broadcast requests for a
 logon server.  The first one to reply gets the job, and validates its
@@ -147,8 +136,9 @@ In the [global] section of smb.conf set the following (for example):
 
   logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
 
-The default for this option is \\%L\%U, namely \\sambaserver\username,
-The \\L%\%U services is created automatically by the [homes] service.
+The default for this option is \\%L\%U\profile, namely
+\\sambaserver\username\profile.  The \\L%\%U services is created
+automatically by the [homes] service.
 
 If you are using a samba server for the profiles, you _must_ make the
 share specified in the logon path browseable.  Windows 95 appears to
@@ -158,6 +148,10 @@ away.  It also attempts to create the components of the full path for
 you.  If the creation of any component fails, or if it cannot see any
 component of the path, the profile creation / reading fails.
 
+[lkcl 26aug96 - we have discovered a problem where Windows clients can
+maintain a connection to the [homes] share in between logins.  The
+[homes] share must NOT therefore be used in a profile path.]
+
 
 Windows 95
 ----------
@@ -281,8 +275,10 @@ to specify the location of the profile.  Samba cannot be a domain
 logon server for NT, therefore you will need to manually configure
 each and every account.  [lkcl 10aug97 - i tried setting the path
 in each account to \\samba-server\homes\profile, and discovered that
-this fails for some reason.  you have to have \\samba-server\user\profile,
-where user is the username created from the [homes] share].
+this fails because a background process maintains the connection to
+the [homes] share which does _not_ close down in between user logins.
+you have to have \\samba-server\user\profile, where user is the
+username created from the [homes] share].
 
 The entry for the NT 4.0 profile is a _directory_ not a file.  The NT
 help on profiles mentions that a directory is also created with a .PDS