After some time looking into this problem, I was able to track the slowness problem down to the smbpasswd file or what seems to be a problem with the smbpasswd file and having the "security" option set to "SHARE".
When we upgraded to 3.0.11, I moved over the previous smbpasswd file from 2.0.7, which has all the entries for the 3,192 associates we have. During the slowness I tried resetting some of the entries for those associates having the worst problem (smbpasswd <username> <passwd>), this did not work. I tried moving the entries for those associates to the top of the smbpasswd file, this did not work. It wasn't until I removed the smbpasswd file that I saw a difference. I then went in and removed the entry "smb passwd file=" via SWAT and things dramatically sped up with access times on the Windows clients. Can anyone shed some light on why this may be? Is this the way it's suppose to behave? Are the others having issues with printing slowness setup with the "security" option set to "SHARE" and a smbpasswd file specified? Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tim Kazsuk Senior Systems Engineer The Home Depot Supply Division ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Jeremy Allison [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 9:40 AM To: Kazsuk, Tim Cc: William Enestvedt; [email protected] Subject: Re: [Samba] Serious Slowness Issues with Printing On Fri, Jun 17, 2005 at 09:21:37AM -0400, Kazsuk, Tim wrote: > In our case, the jobs being sent to the printers are fairly small across > the board, with little or no graphics. The biggest problem is the time > it takes Office to open up with a Samba printer set as default on the > PC. If a fake local printer is installed and set as default, Office > opens up quickly, but when the end user has to print, going in to select > the printer can take some time to select on and then print to it. This > is becoming a big problem. > > I did compile the version I'm using, and for the most part took the > defaults on the options. > > I've looked at the underlying disks (iostat is showing no problems), but > not yet at the network settings on the server. We're running Gigabit > from the server to the switch, all desktops are 100 Full Duplex. Our > current settings are auto-auto on the Cisco switch side and auto-auto on > the desktop side for Speed-Duplex. Leaving them as auto-auto or locking > them down to 100 Full Duplex does not seem to make a difference. The main thing to look at is the network traffic between client and Samba server - ie. does the wait occur on the client when preparing the job or in the network traffic between client and server or at the server end once the job has been received at the server ? This is the first step you need to take in debugging a problem like this. The Samba server submits the job to the backend once it receives the EndJob RPC call. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
