[Samba] login to ms access db very slow on samba 3.x

Brian Cowan brcowan at gmail.com
Tue Jul 25 14:32:06 GMT 2006


Have you tried running network traces with Samba 2.x and 3.x and 
comparing the results. I suspect that at least one newer smb feature is 
killing you...

o.widmer at riskreturn.ch wrote:
> hi everybody
>
> we have been reading through the archives for quite some time now, and 
> could not find a solution to our problem. please excuse if we overlooked 
> something and our question was already answered elsewhere...
>
>
> we have Samba version 3.0.14a-Debian running on (you guessed it) debian 
> with kernel  2.6.8-2-386.
>
> ever since our migration from samba 2.x we have speed issues with an ms 
> access database which gets accessed by multiple users through an 
> access2000 runtime application running on windows clients (2000 and XP). 
> when users log in to the database, it takes >3min until the login-window 
> pops up and users can enter their credentials. since things are not slow 
> for the first user, but for every user that tries to login afterwards, we 
> are suspecting some problems with the lock file of the db or with file 
> ownership... also, transactions seem to be going on at normal speed once 
> after users are logged in (also for users who encounter the "slow login" 
> problem). 
>
> after reading through old postings, we have disabled oplocks and level2 
> oplocks, also Kernel oplocks, with no success. we made a new share 
> containing only the database file (which is about 410MB in size), with no 
> success. after comparing the old 2.x setup with the new one, we noticed 
> that on 2.x (where everything ran smooth) guest access was enabled and 
> everybody was accessing the DB as user "nobody" of group "nogroup", so we 
> tried the same setup on our 3.x server,  forcing user "nobody"  and group 
> "nogroup" on our new 3.x server, hoping that would solve the problem. 
> nada. 
>
> we have tried changing the tcp send/receive buffer size after reading 
> through tcpdump logs, but that was probably too far off. 
>
> it seemed to us that we were not the only ones with this specific problem, 
> but every hint we found was pointing to disabling oplocks - which we did. 
> maybe one of you guys can help us out? any hint or help will, of course, 
> be highly appreciated. maybe we have misconfigured something?
>
> oli
>
>
> relevant sections of
> /etc/samba/smb.conf:
> ****************************
>
> # Global parameters
> [global]
>
>         [.......]
>         veto oplock files = 
> /*.doc/*.xls/*.pdf/*.mdb/*.bsd/*.MDB/*.BSD/*.bsa/*.BSA/*.lbd/*.LBD/*.ldb/*.LDB/
>         veto files = 
> /lost*found/.bash_profile/.bashrc/aquota.*/.ARK_NOBACKUP/
>         lock spin time = 15
>         lock spin count = 100
>         socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2920
>         sync always = no
>         strict sync = no
>         kernel oplocks = No
>
>
> [.......]
>
> [dbs]
>         path = /var/samba/dbs
>         read only = no
>         guest ok = yes
>         oplocks = no
>         level2 oplocks = no
>         strict locking = no
>         fake oplocks = no
>         create mask = 0777
>         directory mask = 0770
>         force create mode = 0777
>         force user = nobody
>         force group = nogroup
>         veto oplock files = 
> /*.MDB/*.mdb/*.bsd/*.BSD/*.bsa/*.BSA/*.lbd/*.LBD/*.ldb/*.LDB/
>
> [.......]
>
>   



More information about the samba mailing list