Hi Brian Thanks for the hint. Unfortunately I am not at all familiar with doing this. Would that involve strace? I took a glimpse at the man pages of strace, but I don't know if I could produce some useful output with it. But maybe I got you wrong and there's an easier way? I must admit that although I'm not totally samba-illiterate, I'm no pro either (obviously :)
cheers Oli Brian Cowan <[EMAIL PROTECTED]> wrote on 25.07.2006 16:32:06: > 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... > > [EMAIL PROTECTED] 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/ > > > > [.......] > > > > > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba