My users are also having severe lag issues now. Whenever they open Windows Explorer, there is up to a 5 minute lag before the window is opened and populated. This only happens to WinXPPro SP 2 clients that are part of the domain. If the system has not been joined to the domain, it doesn't have this problem. Any ideas? I had heard a while ago that there was a problem with WinXP Pro on a non-Active Directory domain. WinXP defaults to searching for AD listings for everything whenever you try to browse and has to time out EVERY TIME before it does a normal non-AD browse.

Not true. All of our clients are WinXP Pro (about 1500) and we don't have this problem.

Windows explorer operates off of netbios calls (meaning wins). You have wins support = yes in your smb.conf. Is this machine your wins server? If it is make sure that it is the only wins server on your network and the clients are pointed to it.

If it isn't change that to no and add to your smb.conf:
Note that you should only have two wins servers if you are using windows boxes for the wins servers and you have replication setup between them. Be sure and change the IP in the above example to whatever fits your network.

When you restart your services make sure that you do it in the order of nmb winbind (if your using that) and smb. I'm not sure how Debian does that-they may have it all bundled together. If its all bundled together make sure nmb is running:

Might as well check smb while you're at it. Just substitute smb for nmb.

On occassion I have seen these not come up right and the machine has to be rebooted.

I would also comment out as it is unnecessary at this point.

Try these and let me know.
John

Glad to hear. I've been stressing this for a while. All of my users have been having lag and general slow down issues ever since our Win2K server died and was replaced by this brand new Debian box.

Yes this machine is our only WINS server on the network. Yesterday I went to each client and made sure the IP address of the server showed up as the WINS server. For those that didn't already have it, I added it. Most of the users have been telling me that the lag problem has been fixed. Thanks John.

Debian makes it easy. The command:
restarts nmbd and smbd together. Checking ps afterwards shows both services up and running. Not using winbind.

Actually, that one is kinda necessary. One of our engineers (and a company founder) is unable to adapt to the fact that the old server has died and been replaced. I need to leave that as is for now.

So now I'm just back to the original problem of clients having their connection reset when they are working on files that are stored on the server.

I haven't forgotten about you just very busy at work with a project that could be going better.

I've been going over in my head trying to figure out what might be cause the drops but I haven't come up with anything concrete.

Here are some ideas though that are rolling around in my head:

Are there proper A and PTR records for the domain controller in dns

Can all of the clients properly resolve to the domain controller using nslookup

Are all of the NICs and Switches 100Mb or better

Is it at certain times of the day when this happens such as when morning, lunch and evening when people are logging off and on

Is the debian box using scsi disks

Can you set the log level in smb.conf to 10 for awhile and then check the smbd, nmbd and machine logs of people who are reporting problems
This will generate a lot of messages and can fill a disk in a hurry so don't leave it on long. BTW you don't need to restart samba when adjusting the log level.

Some food for thought

John

How are your users "connecting to their shares?" Specifically, are you using automount to mount their shares "on demand?" The default auto.smb (in my Fedora system) sets the --timeout parameter to ten minuets, and the cifs connection is automatically closed after there is no activity for that time.

If you're using automount, try changing the --timeout value. (Zero is "no timeout")

Note: If your system reboots when there are open cifs connections, the network connection may be terminated before the system attempts to close the connection, which can cause extremely long delays as each connection takes about 60 seconds to time out when the network is down. (Since dhcdbd is the first network related service to be stopped (on my system) during a shutdown or reboot, I patched the init script for the service to include the following in the stop function definition:)

Of course, if you aren't using automount this is off the mark. (Although you might want to consider setting it up to make life easier for your users.)

I can appreciate that. Things have been getting a little crazy here as well.

Just so you know, I remember an old mentor of mine mentioning a problem like this for WXPPro clients when they are DHCP clients. I went through and assigned each system here a static IP and it took care of a lot of these instances. It is still happening, so here are the answers to your queries:
Yes. The PDC is also the DNS for the domain.
Yes.
Yes. All switches are now 1Gb. Only a handful of systems have 1Gb NICs, but the rest are all 100Mb (in the process of upgrading to a gigabit network). None of the systems are running below 100Mb.
Not really, no. It happens at all hours of the day, during our heaviest loads and our lightest. We even have an engineer that is here on the weekends, pretty much by himself, and he still has problems then.
Yes. 4 250GB drives in a hardware RAID 5 array.
I'll give that a try and see what it pipes out. I appreciate you getting back to me. Thanks

-Dave

Ok. This is kinda odd. I set the log level to 10 and recreated the problem that everyone has been having (severe network lag, files stored on the server will disconnect after a short amount of time, etc). The log had numerous entries of smbd looking for shell32.dll in my roaming profile. That file was not in my roaming profile folder so there were a butt-load of failures and errors associated with it. I copied that file from my local system's %Windows%\System32 folder and suddenly cannot duplicate the problem anymore.

I can't see how or why Samba would expect that file to be part of a user's roaming profile, yet it does. Other than the changes suggested in previous posts, my smb.conf has not changed since this thread began. Does this strike anyone else as odd?

-Dave

Latest update:

I just received an email from one of my users who was working late last night. He was the acting IT person before I started with this company so has more than a reasonable amount of experience with computers. Here is his take on the subject:
The company's CEO followed this up with a comment about MS Excel giving him this trouble only 10-25% of the time now.

Help!

Hello Dave,

Somewhere along the line I missed that there are roaming profiles. If the users are storing large amounts of 'stuff' in their My Documents, My Pictures etc this can cause slow loading and a huge amount of network traffic.

Do all of these users actually roam and require this? We only do a select few who are actually all over the hospital and even then redirect their My Documents to their home drive.

The .dll sounds like some application that is trying to run when they log on. If there is an app doing this and they don't need it take it off of their workstations. Otherwise I would put the dll in their roaming profile if that'll move you closer to cleaning it up.

I know how you feel getting that sort of an email from someone when you know that you have the right answer. Been there and done that and worked night and day to get it resolved. If moving the .dll onto your workstation solved the problem then so be it and make it the same on all of them. Then do the research to see what is loading that uses that .dll. Fix the CEO's pc first, then other high level people then the guy who wrote the letter. Be sure that you stay in contact with the CEO and keep him apprised of what you are discovering and doing to fix it. That'll help you in the long run when you want to do something else.

I'm sure that you ran tests before putting it into production but it's worth saying again.

John

I had originally decided to go with roaming profiles so that each user's home directory would be backed up to tape each day. I'll find another answer for that and disable roaming profiles instead. I hope that will be sufficient.

Good advice concerning the higher-ups. I have been keeping them (CEO included) "in-the-loop" of the changes being made and they have seen improvement. The 10-25% is a heckuva lot better than the 60-75% that users were seeing when all this started. I feel rather lucky that I work in an environment where 90% of the users know better than to open strange emails, download stuff they shouldn't or generally try to mess up their systems with whatever free software appeals to an instant gratification need. Of course, it's that other 10% that I'm trying to protect the data from.

Thanks for your help thusfar, John. I'm hoping I won't need too much more

-Dave

Hey Dave

We've found that most of the users keep their documents either in a shared dept folder or in their My Documents. We set up a home drive via samba (and user manager) and another share for dept. shares. We remap the My Doc* folder to the home drive and use a logon script to map the dept. drive also in the smb.conf as well as user manager.

After this we start educating the users that workstations are not backed up (this is critical) and to not keep any documents there. If they are concerned about security the home drive answers that as no one, via the samba code (unless you set ACLs on them) can get into the home drive. We don't tell them about the ACLs part-just that the home drive is secure from everyone but them, that it is their own personal drive. I have yet to see this not satisfy them.

I really don't mind helping and using the things that I've learned to help someone else. I've received my share of help over the years and helping someone committed to making it work in their environment is a pleasure and small price to pay.

John

Ok. Now I'm a bit confused. How does one go about disabling roaming profiles? I thought that all you had to do was comment out the lines for profiles in smb.conf, but my system is giving errors about not finding the server copy of my profile. I know I missed something, but don't know what.

Dave
Open User Manager on Windows, double click the user name that you want to change, click the Profile button at the bottom of the box, find the text box titled "User Profile Path" and remove the path. If you're not using that find in your smb.conf the line that says and comment it out. Yours may look different on the RH side of the = sign

John

User Manager in Windows is for local users and groups, not domain users and groups. I ran the MMC (Microsoft Management Console) and could not find a snap-in for Domain Users and Groups.

I commented out that line in smb.conf. Will that be enough?

Dave

Yep commenting that line should be enough.

I was referring to the user manager for NT4 which is for domains since this is what Windows clients see the samba server as.

At any rate commenting that line should be enough since you're not using user manager.

John