samba - Oct 2002 - Problems using WinXP-Pro client and Samba PDC

Hi All-

Some time ago (24 September 2002), I wrote the list about this problem with 
using a WinXP Pro client with a Samba PDC (see below for details).

In response, Kenneth Illingsworth (if I understood him correctly) suggested 
that the error message given by the Win XP client just might be accurate (ie. 
that when the client complains of "Insufficient Memory" and then
crashes
immediately, it might indeed be a problem with insufficient memory), and also 
suggested that I should make sure disk write caching was enabled for the 
client machine and that the amount of swap space was something like 2.5 times 
the amount of physical RAM.

I tried Ken's suggestion, verified that disk write caching was indeed
enabled,
increased the amount of swap space from the automatically configured amount 
(384 MB of swap with 128 MB of RAM) to 512 MB of swap.  Unfortunately, this 
did nothing to solve the problem, and I am now exactly where I stood when I 
originally posted the message below, so it seems my suspicion that the WinXP 
error message had nothing to do with the real problem was probably correct.

I've tried fiddling with various settings in the smb.conf file that seem to 
relate to file locking and stuff, but all to no avail.

Does anyone (please, please!) have any suggestions about what might be the 
problem or what to try experimenting with to try and solve the problem?

If not, is anyone else running a network with a samba PDC, at least one Win XP 
Pro client, at least one Win XP 2K client, and a database application run 
simultaneously on both of these clients (and perhaps others) using common 
files that are made available on the network using the disk share features of 
the samba PDC?  If so, perhaps someone could send me a copy of his/her 
smb.conf file for simple comparison.

My smb.conf file looks like this:

[global]
	workgroup = OLYMPUS
	netbios name = ARES
	server string = Samba %v on %h
	encrypt passwords = Yes
	map to guest = Bad User
	smb passwd file = /etc/samba/smbpasswd
	passwd program = /usr/bin/passwd %u
	unix password sync = Yes
	log level = 2
	syslog = 0
	socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
	character set = ISO8859-15
	domain admin group = admin
	add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
	logon path = \\%N\profile\%U
	domain logons = Yes
	os level = 64
	preferred master = True
	domain master = True
	wins support = Yes
	admin users = adam
	hosts allow = 192.168.69., 127.
	printing = lprng
	veto files = /*.eml/*.nws/riched20.dll/*.{*}/

[homes]
	comment = Home Directories
	read only = No
	create mask = 0640
	directory mask = 0750
	browseable = No

[printers]
	comment = All Printers
	path = /var/tmp
	create mask = 0600
	printable = Yes
	browseable = No

[netlogon]
	comment = The domain logon service
	path = /export/samba/logon
	browseable = No

[profile]
	comment = User profiles
	path = /export/samba/profile
	read only = No
	create mask = 0600
	directory mask = 0700
	browseable = No

> [Samba] Wierdness using Samba PDC with WinXP-Pro and Win2K-Pro clients
> Tue, 24 Sep 2002 12:49:31 -0400
> Hi All-
>
> I have just finished making a change to the server machine in a 3-node
> network.  Before, it was running Win2K Server, and now it's running
SuSE
> Linux 8.0 and the default samba package installed with that distribution
> (samba-2.2.3a-64).
>
> The Win2K Server OS was acting as the PDC for the LAN, and the two client
> machines (one running Win2K Pro and the other running WinXP Pro) were
> connected to the domain offered by that Win2K server.  Now, the same
> machine is running SuSE 8.0 and it is acting as the PDC for the LAN and the
> same two clients are now using the SuSE box as the PDC and they are now
> connected to the new domain created on the SuSE box.  The server also
> serves up an SMB share to the client machines.  The client machines map
> this network file share to the local F: drive for each client.
>
> This LAN is in a business office running a database application based upon
> FoxPro.  The file share served up by the server contains the database
> application executables and data.  The two client machines should both run
> copies of the database application simultaneously, and this worked without
> problems when the PDC and file share were being provided by Win2K server
> OS.
>
> But the wierdness is this:  The arrangement still works fine with the SuSE
> box as the PDC and SMB file server, BUT... ONLY if I start the database
> application on the Win2K client machine FIRST, and then, once it is
> running, I subsequently start the database application on the WinXP client.
> If I start up the apps on the clients in that order, then all is well, and
> the app apparently runs noticably faster on both clients with the SuSE box
> as the server than it did with Win2K server.
>
> But if I start up the app on the WinXP client first, and subsequently start
> up the app on the Win2K client, then the Win2K client is very, VERY slow in
> loading the app (maybe 5-10 times longer than usual) and the app running on
> the WinXP client crashes in flames with the next operation of any sort.
> The error message that it offers before going down is, "Insufficient
> Memory" which is undoubtedly completely unrelated to the real problem
(the
> client machine has 128 MB of RAM).
>
> The database application is pretty simple.  It is not a client/server
> application.  The very same executable file is fired up on each client, but
> the working directory for one client machine's application is different
> from that of the other client machine (this seems to be the way that the
> database application's programmers have implemented the system to avoid
> file locking problems---apparently, the data files that live in the
app's
> working directory are synchronized periodically with the app's main
> directory).
>
> More specifically, the working directories for each client are
> sub-directories of the file share served up by the server.  The working
> directory for the WinXP client is the database app's main directory,
and
> the working directory for the Win2K client is another directory.
>
> Domain logons all seem to work just fine, and all other aspects of
> filesystem browsing seem ok.
>
> To try and solve the problem myself, I have moved the XP client
machine's
> working directory to a separate directory from the app's main directory
> (just a thought).  This made no difference in the wierdness.  I also have
> read the smb.conf man page pretty thoroughly for the options that show up
> in the SWAT sections entitled: protocol options, tuning options, and
> locking options. Nothing there seems to address this issue.
>
> I've browsed through many of the archived articles for this list and
the
> older ntdom list, but there seems to be no searchable archives, so that was
> certainly not comprehensive.
>
> I have implemented the windows registry hack for the WinXP machine that
> allows it to be a member of this domain.
>
> Can anyone think of anything else that I should try?  I'm thinking that
> there must be some locking option that Windows XP handles incorrectly or
> something like that.  I'd really appreciate any thoughts on the issue.
>
> Thank you in advance for any help.
>
>
> -Joe

At 07:00 06-10-2002 -0400, you wrote:
>Hi All-
>
>Some time ago (24 September 2002), I wrote the list about this problem with
>using a WinXP Pro client with a Samba PDC (see below for details).
[snip]

         Well, I've read your LAN description and it mentions 4 things that 
are quite meaningful to me (as I had to fiddle with them too):

         1 Samba server that used to be Windows
         1 XP client
         1 W2K client
         1 Database app (a-ha! vital point!)

         I did read the rest of the problem and I have no idea if the 
"insufficient memory" message is truthful or not. The point is that I
had
to configure a LAN which had those 4 particularities, and a lot of trouble 
from the database-driven app (Access, FWIW) when it was acessed by 2 or 
more clients. To make a long story short, I solved a lot of trouble with 
the said app by configuring its' share like this:

         locking = yes
         oplocks = yes
         level 2 oplocks = yes
         share modes = no    <--- dangerous, I know, but this particular 
piece was vital

         You also need to ensure all directory/file modes are 
group-writable. That app was crashing when closing after 2 or more clients 
had opened it, and threw out some other stupid errors. This may not be the 
cure to your particular problem, but it sure took me a few days to come up 
with a solution to mine, which is similar. Hope this helps in any way.

         Bruno Ferreira

---
[This E-mail scanned for viruses by Declude Virus]