Hi all,
I've got this very strange occurence....
A client has a Linux Samba Server - RedHat 7.1, Samba 2.2.1a. It is
fileserving in place of an NT Server, providing networked drives to a
network of only 3 client PC's - all Windows 98.
They currently have three networked DOS apps running off this Server, all
multi-user, all with no problems.
However, when I added another in today, I got a shock!
The first user can log into the App. When the second user tries to login in,
the Win98 client pauses for a while, then comes back with "unknown disc
error on drive Z:" (that being the mapped drive).
If I moved the Server files to a network drive housed on a Windows PC,
multiple users can log in okay! So the problem is with the Samba networked
drive.
I have bought the client's files back home, and have been reproducing the
problem here. It turns out that using Windows 2000 Pro multiple users can
run the app as required - so the problem occurs just on Windows 98.
Has anybody ever experienced this before? Can anybody help?
My SMB.CONF is included below, many many thanks for any help received!
Regards,
Greg Conway.
smb.conf:
[global]
workgroup = DEMO
netbios name = DEMOLUX
# netbios aliases = GMLFAXALIAS1 GMLFAXALIAS2
server string = DEMOLUX SAMBA %v on %L
security = domain
encrypt passwords = Yes
# unix password sync = no
smb passwd file = /etc/samba/smbpasswd
log file = /usr/local/logs/samba.log.%m
max log size = 1000
log level = 2
interfaces = 192.168.150.23 127.0.0.1
bind interfaces only = yes
socket address = 192.168.150.23
hosts allow = 192.168.150. 127.
# EXCEPT 192.168.150.1
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# IPTOS_LOWDELAY
# SO_BROADCAST
load printers = no
add user script = /usr/sbin/adduser -n -g samba -c Machine -d
/dev/null -s /bin/false %m$
logon path = \\DEMOLUX\profiles\%u
logon drive = U:
logon home = \\DEMOLUX\homes
logon script = login.bat
domain logons = Yes
os level = 64
preferred master = yes
domain master = true
local master = yes
dns proxy = no
wins support = yes
wins proxy = yes
# name resolve order = wins lmhosts hosts bcast
valid users = bill ben rod jane freddy
# map archive = true
# map system = true
# map hidden = true
[homes]
browseable = no
read only = no
[printers]
path = /var/spool/uucppublic # maybe change this!
min print space = 2048 # maybe this should be in [global]
printable = Yes
browseable = no
# valid users = bill
[profiles]
comment = DEMOLUX profiles drive
browseable = no
path = /export/samba/profiles
writeable = no
volume = DEMOLUX-PROFILES
[config]
comment = DEMOLUX config drive
path = /export/samba/config
writeable = yes
volume = DEMOLUX-CONFIG
[data]
comment = DEMOLUX data drive
path = /17gb/data
read only = No
volume = DEMOLUX-DATA
[users]
browseable = yes
path = /export/samba/users
comment = user home directories
read only = no
volume = DEMOLUX-USERS
[netlogon]
comment = DEMOLUX NETLOGON directory
browseable = no
path = /export/samba/netlogon
read only = no
volume = DEMOLUX-NETLOGON
[install]
comment = DEMOLUX installation files drive
browseable = yes
path = /export/nobackup/install
volume = DEMOLUX-INSTALL
read only = no
--
+-----------------------------------+
| Greg Conway, Technical Director |
| GML Networking Technologies |
+-----------------------------------+
Email/MSN: mailto:greg@gmlnt.com
ICQ#: 100219981
mobile tel.: +44 (0) 7974 666 967
mobile fax: +44 (0) 7970 087 935
Internet: http://www.gmlnt.com
office tel.: +44 (0) 1255 672 103
office fax: +44 (0) 1255 679 909
+-----------------------------------+
| GMLNT ** Sensible Smart Solutions |
+-----------------------------------+
***********************************************************************
This is a confidential communication between sender and addressee. If you are
not the intended recipient of this message, please notify the sender and do not
read, copy, use or disclose this communication to others. Any opinions or views
expressed are those of the individual, and unless otherwise stated, are not
those of the company. All attachments and intellectual rights remain the
property of GML (NT) Limited.
***********************************************************************
Can you post the samba messages is /var/log/messages when this happens?
Thanks.
-----Original Message-----
From: samba-admin@lists.samba.org [mailto:samba-admin@lists.samba.org]On
Behalf Of Greg Conway
Sent: Monday, January 28, 2002 8:04 PM
To: Samba
Subject: [Samba]DOS app won't run off a Samba drive!
Hi all,
I've got this very strange occurence....
A client has a Linux Samba Server - RedHat 7.1, Samba 2.2.1a. It is
fileserving in place of an NT Server, providing networked drives to a
network of only 3 client PC's - all Windows 98.
They currently have three networked DOS apps running off this Server, all
multi-user, all with no problems.
However, when I added another in today, I got a shock!
The first user can log into the App. When the second user tries to login in,
the Win98 client pauses for a while, then comes back with "unknown disc
error on drive Z:" (that being the mapped drive).
If I moved the Server files to a network drive housed on a Windows PC,
multiple users can log in okay! So the problem is with the Samba networked
drive.
I have bought the client's files back home, and have been reproducing the
problem here. It turns out that using Windows 2000 Pro multiple users can
run the app as required - so the problem occurs just on Windows 98.
Has anybody ever experienced this before? Can anybody help?
My SMB.CONF is included below, many many thanks for any help received!
Regards,
Greg Conway.
smb.conf:
[global]
workgroup = DEMO
netbios name = DEMOLUX
# netbios aliases = GMLFAXALIAS1 GMLFAXALIAS2
server string = DEMOLUX SAMBA %v on %L
security = domain
encrypt passwords = Yes
# unix password sync = no
smb passwd file = /etc/samba/smbpasswd
log file = /usr/local/logs/samba.log.%m
max log size = 1000
log level = 2
interfaces = 192.168.150.23 127.0.0.1
bind interfaces only = yes
socket address = 192.168.150.23
hosts allow = 192.168.150. 127.
# EXCEPT 192.168.150.1
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# IPTOS_LOWDELAY
# SO_BROADCAST
load printers = no
add user script = /usr/sbin/adduser -n -g samba -c Machine -d
/dev/null -s /bin/false %m$
logon path = \\DEMOLUX\profiles\%u
logon drive = U:
logon home = \\DEMOLUX\homes
logon script = login.bat
domain logons = Yes
os level = 64
preferred master = yes
domain master = true
local master = yes
dns proxy = no
wins support = yes
wins proxy = yes
# name resolve order = wins lmhosts hosts bcast
valid users = bill ben rod jane freddy
# map archive = true
# map system = true
# map hidden = true
[homes]
browseable = no
read only = no
[printers]
path = /var/spool/uucppublic # maybe change this!
min print space = 2048 # maybe this should be in [global]
printable = Yes
browseable = no
# valid users = bill
[profiles]
comment = DEMOLUX profiles drive
browseable = no
path = /export/samba/profiles
writeable = no
volume = DEMOLUX-PROFILES
[config]
comment = DEMOLUX config drive
path = /export/samba/config
writeable = yes
volume = DEMOLUX-CONFIG
[data]
comment = DEMOLUX data drive
path = /17gb/data
read only = No
volume = DEMOLUX-DATA
[users]
browseable = yes
path = /export/samba/users
comment = user home directories
read only = no
volume = DEMOLUX-USERS
[netlogon]
comment = DEMOLUX NETLOGON directory
browseable = no
path = /export/samba/netlogon
read only = no
volume = DEMOLUX-NETLOGON
[install]
comment = DEMOLUX installation files drive
browseable = yes
path = /export/nobackup/install
volume = DEMOLUX-INSTALL
read only = no
--
+-----------------------------------+
| Greg Conway, Technical Director |
| GML Networking Technologies |
+-----------------------------------+
Email/MSN: mailto:greg@gmlnt.com
ICQ#: 100219981
mobile tel.: +44 (0) 7974 666 967
mobile fax: +44 (0) 7970 087 935
Internet: http://www.gmlnt.com
office tel.: +44 (0) 1255 672 103
office fax: +44 (0) 1255 679 909
+-----------------------------------+
| GMLNT ** Sensible Smart Solutions |
+-----------------------------------+
***********************************************************************
This is a confidential communication between sender and addressee. If you
are not the intended recipient of this message, please notify the sender and
do not read, copy, use or disclose this communication to others. Any
opinions or views expressed are those of the individual, and unless
otherwise stated, are not those of the company. All attachments and
intellectual rights remain the property of GML (NT) Limited.
***********************************************************************
--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba
On Mon, 2002-01-28 at 21:03, Greg Conway wrote:> Hi all, > > I've got this very strange occurence.... > > A client has a Linux Samba Server - RedHat 7.1, Samba 2.2.1a. It is > fileserving in place of an NT Server, providing networked drives to a > network of only 3 client PC's - all Windows 98. > > They currently have three networked DOS apps running off this Server, all > multi-user, all with no problems. > > However, when I added another in today, I got a shock! > > The first user can log into the App. When the second user tries to login in, > the Win98 client pauses for a while, then comes back with "unknown disc > error on drive Z:" (that being the mapped drive). > > If I moved the Server files to a network drive housed on a Windows PC, > multiple users can log in okay! So the problem is with the Samba networked > drive. > > I have bought the client's files back home, and have been reproducing the > problem here. It turns out that using Windows 2000 Pro multiple users can > run the app as required - so the problem occurs just on Windows 98. > > Has anybody ever experienced this before? Can anybody help?Does this problem occur if you map the share to another drive other than drive z? Windows 9x uses drive z internally to map the netlogon share, so if your logon script contains a line such as "net use z: \\share\name", it may exhibit some unexpected behavior. This only happens with windows 95/98 according to Microsoft knowledge base. Can you try using a different drive letter to see if it helps? Kohei> My SMB.CONF is included below, many many thanks for any help received! > > Regards, > > Greg Conway. > > > smb.conf: > > [global] > > workgroup = DEMO > netbios name = DEMOLUX > # netbios aliases = GMLFAXALIAS1 GMLFAXALIAS2 > server string = DEMOLUX SAMBA %v on %L > > security = domain > encrypt passwords = Yes > # unix password sync = no > smb passwd file = /etc/samba/smbpasswd > > log file = /usr/local/logs/samba.log.%m > max log size = 1000 > log level = 2 > interfaces = 192.168.150.23 127.0.0.1 > bind interfaces only = yes > socket address = 192.168.150.23 > hosts allow = 192.168.150. 127. > # EXCEPT 192.168.150.1 > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 > # IPTOS_LOWDELAY > # SO_BROADCAST > > load printers = no > > add user script = /usr/sbin/adduser -n -g samba -c Machine -d > /dev/null -s /bin/false %m$ > > logon path = \\DEMOLUX\profiles\%u > logon drive = U: > logon home = \\DEMOLUX\homes > logon script = login.bat > > domain logons = Yes > os level = 64 > preferred master = yes > domain master = true > local master = yes > > dns proxy = no > > wins support = yes > wins proxy = yes > # name resolve order = wins lmhosts hosts bcast > > valid users = bill ben rod jane freddy > > # map archive = true > # map system = true > # map hidden = true > > [homes] > browseable = no > read only = no > > [printers] > path = /var/spool/uucppublic # maybe change this! > min print space = 2048 # maybe this should be in [global] > printable = Yes > browseable = no > # valid users = bill > > [profiles] > comment = DEMOLUX profiles drive > browseable = no > path = /export/samba/profiles > writeable = no > volume = DEMOLUX-PROFILES > > [config] > comment = DEMOLUX config drive > path = /export/samba/config > writeable = yes > volume = DEMOLUX-CONFIG > > [data] > comment = DEMOLUX data drive > path = /17gb/data > read only = No > volume = DEMOLUX-DATA > > [users] > browseable = yes > path = /export/samba/users > comment = user home directories > read only = no > volume = DEMOLUX-USERS > > [netlogon] > comment = DEMOLUX NETLOGON directory > browseable = no > path = /export/samba/netlogon > read only = no > volume = DEMOLUX-NETLOGON > > [install] > comment = DEMOLUX installation files drive > browseable = yes > path = /export/nobackup/install > volume = DEMOLUX-INSTALL > read only = no > > > > > -- > +-----------------------------------+ > | Greg Conway, Technical Director | > | GML Networking Technologies | > +-----------------------------------+ > Email/MSN: mailto:greg@gmlnt.com > ICQ#: 100219981 > mobile tel.: +44 (0) 7974 666 967 > mobile fax: +44 (0) 7970 087 935 > Internet: http://www.gmlnt.com > office tel.: +44 (0) 1255 672 103 > office fax: +44 (0) 1255 679 909 > +-----------------------------------+ > | GMLNT ** Sensible Smart Solutions | > +-----------------------------------+ > > *********************************************************************** > This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. > *********************************************************************** > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba >
Okay, let me do another try. By looking at your log files, I see that the program accesses several files with extensions like ".DBM" or ".DBZ". Are they database files? If so, can you try "veto oplock" on these files? I've learned through my past painful experience that databases have their own locking mechanisms that somehow don't mix well with oplocks. So what you could do is put: veto oplock files = /*.DBM/*.DBZ/ to not grant oplocks on these file types. You can also add more extensions to the above line that you think are also problematic. This is worth a try. Kohei On Mon, 2002-01-28 at 22:34, Greg Conway wrote:> Hi Kohei, > > Thanks for the reply. Yes, unfortunately, I have also tried drive R:, which > is a different Samba share on the same machine, and also X: here in my local > setup. > > But thanks anyway! > > Regards, > > Greg. > > > -----Original Message----- > > From: Kohei Yoshida [mailto:kyoshida@mesco.com] > > Sent: 29 January 2002 03:25 > > To: Greg Conway > > Cc: samba@lists.samba.org > > Subject: Re: [Samba]DOS app won't run off a Samba drive! > > > > > > On Mon, 2002-01-28 at 21:03, Greg Conway wrote: > > > Hi all, > > > > > > I've got this very strange occurence.... > > > > > > A client has a Linux Samba Server - RedHat 7.1, Samba 2.2.1a. It is > > > fileserving in place of an NT Server, providing networked drives to a > > > network of only 3 client PC's - all Windows 98. > > > > > > They currently have three networked DOS apps running off this > > Server, all > > > multi-user, all with no problems. > > > > > > However, when I added another in today, I got a shock! > > > > > > The first user can log into the App. When the second user tries > > to login in, > > > the Win98 client pauses for a while, then comes back with "unknown disc > > > error on drive Z:" (that being the mapped drive). > > > > > > If I moved the Server files to a network drive housed on a Windows PC, > > > multiple users can log in okay! So the problem is with the > > Samba networked > > > drive. > > > > > > I have bought the client's files back home, and have been > > reproducing the > > > problem here. It turns out that using Windows 2000 Pro multiple > > users can > > > run the app as required - so the problem occurs just on Windows 98. > > > > > > Has anybody ever experienced this before? Can anybody help? > > > > Does this problem occur if you map the share to another drive other than > > drive z? Windows 9x uses drive z internally to map the netlogon share, > > so if your logon script contains a line such as "net use z: > > \\share\name", it may exhibit some unexpected behavior. This only > > happens with windows 95/98 according to Microsoft knowledge base. > > > > Can you try using a different drive letter to see if it helps? > > > > Kohei > > > > > My SMB.CONF is included below, many many thanks for any help received! > > > > > > Regards, > > > > > > Greg Conway. > > > > > > > > > smb.conf: > > > > > > [global] > > > > > > workgroup = DEMO > > > netbios name = DEMOLUX > > > # netbios aliases = GMLFAXALIAS1 GMLFAXALIAS2 > > > server string = DEMOLUX SAMBA %v on %L > > > > > > security = domain > > > encrypt passwords = Yes > > > # unix password sync = no > > > smb passwd file = /etc/samba/smbpasswd > > > > > > log file = /usr/local/logs/samba.log.%m > > > max log size = 1000 > > > log level = 2 > > > interfaces = 192.168.150.23 127.0.0.1 > > > bind interfaces only = yes > > > socket address = 192.168.150.23 > > > hosts allow = 192.168.150. 127. > > > # EXCEPT 192.168.150.1 > > > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 > > > # IPTOS_LOWDELAY > > > # SO_BROADCAST > > > > > > load printers = no > > > > > > add user script = /usr/sbin/adduser -n -g samba -c Machine -d > > > /dev/null -s /bin/false %m$ > > > > > > logon path = \\DEMOLUX\profiles\%u > > > logon drive = U: > > > logon home = \\DEMOLUX\homes > > > logon script = login.bat > > > > > > domain logons = Yes > > > os level = 64 > > > preferred master = yes > > > domain master = true > > > local master = yes > > > > > > dns proxy = no > > > > > > wins support = yes > > > wins proxy = yes > > > # name resolve order = wins lmhosts hosts bcast > > > > > > valid users = bill ben rod jane freddy > > > > > > # map archive = true > > > # map system = true > > > # map hidden = true > > > > > > [homes] > > > browseable = no > > > read only = no > > > > > > [printers] > > > path = /var/spool/uucppublic # maybe change this! > > > min print space = 2048 # maybe this should be > > in [global] > > > printable = Yes > > > browseable = no > > > # valid users = bill > > > > > > [profiles] > > > comment = DEMOLUX profiles drive > > > browseable = no > > > path = /export/samba/profiles > > > writeable = no > > > volume = DEMOLUX-PROFILES > > > > > > [config] > > > comment = DEMOLUX config drive > > > path = /export/samba/config > > > writeable = yes > > > volume = DEMOLUX-CONFIG > > > > > > [data] > > > comment = DEMOLUX data drive > > > path = /17gb/data > > > read only = No > > > volume = DEMOLUX-DATA > > > > > > [users] > > > browseable = yes > > > path = /export/samba/users > > > comment = user home directories > > > read only = no > > > volume = DEMOLUX-USERS > > > > > > [netlogon] > > > comment = DEMOLUX NETLOGON directory > > > browseable = no > > > path = /export/samba/netlogon > > > read only = no > > > volume = DEMOLUX-NETLOGON > > > > > > [install] > > > comment = DEMOLUX installation files drive > > > browseable = yes > > > path = /export/nobackup/install > > > volume = DEMOLUX-INSTALL > > > read only = no > > > > > > > > > > > > > > > -- > > > +-----------------------------------+ > > > | Greg Conway, Technical Director | > > > | GML Networking Technologies | > > > +-----------------------------------+ > > > Email/MSN: mailto:greg@gmlnt.com > > > ICQ#: 100219981 > > > mobile tel.: +44 (0) 7974 666 967 > > > mobile fax: +44 (0) 7970 087 935 > > > Internet: http://www.gmlnt.com > > > office tel.: +44 (0) 1255 672 103 > > > office fax: +44 (0) 1255 679 909 > > > +-----------------------------------+ > > > | GMLNT ** Sensible Smart Solutions | > > > +-----------------------------------+ > > > > > > *********************************************************************** > > > This is a confidential communication between sender and > > addressee. If you are not the intended recipient of this message, > > please notify the sender and do not read, copy, use or disclose > > this communication to others. Any opinions or views expressed are > > those of the individual, and unless otherwise stated, are not > > those of the company. All attachments and intellectual rights > > remain the property of GML (NT) Limited. > > > *********************************************************************** > > > > > > -- > > > To unsubscribe from this list go to the following URL and read the > > > instructions: http://lists.samba.org/mailman/listinfo/samba > > > > > > > *********************************************************************** > This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. > *********************************************************************** >
I want to integrate Samba and HylaFax functionality. Basically throw Postscript files into a samba print share and have it faxed using Hyla Fax. Anyone have a little script they would like to share? Thanks.
Hi Dragos, Thanks for this. My apologies... with the "veto oplock files= " I was just adding this into the [global] section, yet you mentioned a [dos share] section below... maybe this is why the "veto" option did not fix things? what is the syntax here? [dos share] or similar? I will add the rest below now anyway! Thanks, Greg.> -----Original Message----- > From: Dragos [mailto:dragos.delcea@farmexim.ro] > Sent: 29 January 2002 13:04 > To: Greg Conway > Subject: Re: [Samba]DOS app won't run off a Samba drive! > > > On Tuesday 29 January 2002 02:53 pm, Greg Conway wrote: > > Hi Dragos, > > > > Yes, it is, Samba 2.2.1a (RPM) on Linux 7.1. > > > > Thanks! > > > > Greg. > take care, if you hit replay, the mails come only to me; you must > hit reply > all...now, let's get back to it > in the [global] section: > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 > kernel oplocks = no > max xmit = 16384 > max xmit = 32768 > read raw = no > write raw = no > read size = 32768 > > in the dos share section put > veto oplock files = ...... > > this setup is working for me since last summer redhat 7.1 also, 2.2.1a > compiled from source; pay attention to 'kernel oplocks' > parameter, it must be > 'no' (it is automatically yes on a 2.4 kernel, but it doesn't work as > advertised on it). > let me hear about your success (I hope!)... > > dragos*********************************************************************** This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. ***********************************************************************
Dragos, if it were possible I'd be on a plane to breed children for you!! It has worked! Many, many thanks. The interesting thig is, the below options have solved it. I have removed the "veto files" completely, but maybe the kernel oplocks section has helped or something? Anyway, no matter, the important thing is that it works, and I will have happy clients again :) Many, many thanks to you for all your help, and also Kohei and Sanjiv, I am a happy Linuxer once again! Regards, Greg.> -----Original Message----- > From: Dragos [mailto:dragos.delcea@farmexim.ro] > Sent: 29 January 2002 13:04 > To: Greg Conway > Subject: Re: [Samba]DOS app won't run off a Samba drive! > > > On Tuesday 29 January 2002 02:53 pm, Greg Conway wrote: > > Hi Dragos, > > > > Yes, it is, Samba 2.2.1a (RPM) on Linux 7.1. > > > > Thanks! > > > > Greg. > take care, if you hit replay, the mails come only to me; you must > hit reply > all...now, let's get back to it > in the [global] section: > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 > kernel oplocks = no > max xmit = 16384 > max xmit = 32768 > read raw = no > write raw = no > read size = 32768 > > in the dos share section put > veto oplock files = ...... > > this setup is working for me since last summer redhat 7.1 also, 2.2.1a > compiled from source; pay attention to 'kernel oplocks' > parameter, it must be > 'no' (it is automatically yes on a 2.4 kernel, but it doesn't work as > advertised on it). > let me hear about your success (I hope!)... > > dragos*********************************************************************** This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. ***********************************************************************
Enabled oplocks can also cause problems with some virus scanners. I found that McAffee running off a Windows client left all the files it scanned open if oplocks are enabled. Eventually the server ran out of file handles and came to a screeching halt. My general practice has been to disable them for all shares to reduce corruption in Access databases and Outlook *.pst files. Performance doesn't really seem much slower as a result. Regards, Glenn Scherb -----Original Message----- From: samba-admin@lists.samba.org [mailto:samba-admin@lists.samba.org] On Behalf Of Rashkae Sent: Tuesday, January 29, 2002 11:38 AM To: Greg Conway Cc: Samba Subject: RE: [Samba]DOS app won't run off a Samba drive! I will try to explain my limited understanding. Others can correct me and fill in the blanks as we go. :) Oplocks stand for Opportunistic Locking. Here's how it works. Client requests to open a file from the server. If no other clients are using that particular file, the server will grant the client an "opportunistic lock". This means that the client will cache a copy of the file in local memory. That way, read/write operations to the file don't have to go over the network. This is, of course, a significant performance boost. The server will not allow other clients to open the file, since the client local cached copy and the server copy are likely to be out of sync. The fun begins when a second client wants to open a file that is oplocked. The server must inform the original client that the lock will be broken. At this point, Client 1 is supposed to upload any changes to the file back to the server and continue on the way things would normally work. All read/write operations are performed over the network. Databases should lock on a record by record basis for write operations (Thereby being safe for multiple users.) If client 1 does not co-operate with the break request, the server has to force a break. The file to client 1 is closed in whatever state the cache was last synchronized with the server. For oplock granting and breaking to work properly requires handshaking between client user software, client os, server software, and server os. All possible combinations of the above have their own special quirks and behavior. (Note: it is only in recent versions of Linux Kernel that Linux OS participates in the matrix. This is where the kernel oplocks comes into play. If kernel oplocks are not enabled, linux will not know that a file in a samba share is 'locked', and will allow local linux users or NFS users to open the file without negotiating a break with the SMB client. Chaos ensues. On the other hand, if Unix processes other than Samba will not be opening the files for write, disabling kernel oplocks removes yet another possible source of problems, the server os.) Long ago when I was young and innocent, and administering NT 4 servers for a living, I worked out the rule of thumb of always disabling Oplocks whenever a database was involved. (In Windows, this can be done with a registry key, but it affects the whole system. Oplocks cannot be disabled on a file by file or share by share basis.) You can avoid much database corruption this way. *Especially* Dos Databases, since older DOS software was not "opportunistic lock aware" (quote from MS tech support.) Another neat trick Samba has is the ability to "fake oplocks". This will make samba always grant oplocks, to multiple simultaneous clients. This can be a boost to read-only shares, since the files will never be changed, it doesn't matter if all the clients and server are in sync. The problem with this, of course, is that no one can modify the file while SMB clients are using it. Otherwise, chaos ensues. :). This is probably only safe on CD-ROM shares. Oh, BTW, Samba enables oplocks by default. Personally, I am not a fan of performance over stability 'features.', but that's just MNSHO. I am not a coder or engineer, and probably misunderstand many of the concepts involved. I'm just the person who has to explain to clients why their database is hosed and the previous 2 weeks of tape backups are no good because nobody rotated the tapes and the one in the drive went bad long time ago. On Tue, 29 Jan 2002, Greg Conway wrote: Hi Rashkae, Well, all these "oplocks" are a little new to me! I have been running off the same smb.conf for the last six or seven machines, and this is the first time I have encountered problems since I spent a long time writing that original smb.conf! So do I presume... you can put a "oplocks" section in the [global] section, to enable oplocks - are they enabled by default? is this why I have never heard of them before? you can then put a "veto oplocks" section into individual shares ie [data], to remove oplocks from that particular share. Sorry to be thick, can somebody please explain to me in windows-users terms :) exactly what oplocks does? It is similar to SHARE.EXE? Why do my Win2k machines work be default but not my Win98 machines? Anyway, just interested in the hows and whys rather than blindly fixing things and not knowing how I did it!! Regards, Greg.> -----Original Message----- > From: Rashkae [mailto:rashkae@wealthmap.ca] > Sent: 29 January 2002 14:33 > To: Dragos > Cc: Greg Conway; Samba > Subject: Re: [Samba]DOS app won't run off a Samba drive! > > > Why not just disable openlocks entirely? Makes allot of sense to me > for a server that primarily dishes out multi-user files, oplocks at > best is a performance hindrance, at worst a dangerous database > corrupting monster. > > (I think your able to disable oplocks on a share by share basis, if > you have other shares where oplocks would be useful.) > > On Tue, 29 Jan 2002, Dragos wrote: > > glad to hear that it works...:) > however, keep the 'veto oplocks files' option handy, because when > you'll have more than one connection to the share (multiple win > clients working on the > database) things will slow down. > > dragos*********************************************************************** This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. *********************************************************************** -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Hi Sanjiv,
What I did in the end is add the following to my existing smb.conf, which
I've already posted:
kernel oplocks = no
max xmit = 16384
max xmit = 32768
read raw = no
write raw = no
read size = 32768
and then let out a loud whoop of joy! or should that be w00t? apparantly!
this web talk gets sillier and sillier... or I get older and older :(
anyway, yes that fixed it, and I'm very grateful to all involved in fixing
it! the real acid test is when I take the PC back tomorrow morning!
Regards,
Greg.
> -----Original Message-----
> From: Sanjiv Bawa [mailto:sbawa@tabmaster.com]
> Sent: 29 January 2002 16:02
> To: Greg Conway; dragos.delcea@farmexim.ro
> Cc: Samba
> Subject: RE: [Samba]DOS app won't run off a Samba drive!
>
>
> Did you turn off kernel oplocks only or oplocks in general?
>
> I had the same problem you guys are having.
>
> Thanks.
>
> -----Original Message-----
> From: samba-admin@lists.samba.org [mailto:samba-admin@lists.samba.org]On
> Behalf Of Greg Conway
> Sent: Tuesday, January 29, 2002 7:30 AM
> To: dragos.delcea@farmexim.ro
> Cc: Samba
> Subject: RE: [Samba]DOS app won't run off a Samba drive!
>
>
> Dragos, if it were possible I'd be on a plane to breed children for
you!!
>
> It has worked! Many, many thanks.
>
> The interesting thig is, the below options have solved it. I have removed
> the "veto files" completely, but maybe the kernel oplocks section
> has helped
> or something?
>
> Anyway, no matter, the important thing is that it works, and I will have
> happy clients again :)
>
> Many, many thanks to you for all your help, and also Kohei and
> Sanjiv, I am
> a happy Linuxer once again!
>
> Regards,
>
> Greg.
>
> > -----Original Message-----
> > From: Dragos [mailto:dragos.delcea@farmexim.ro]
> > Sent: 29 January 2002 13:04
> > To: Greg Conway
> > Subject: Re: [Samba]DOS app won't run off a Samba drive!
> >
> >
> > On Tuesday 29 January 2002 02:53 pm, Greg Conway wrote:
> > > Hi Dragos,
> > >
> > > Yes, it is, Samba 2.2.1a (RPM) on Linux 7.1.
> > >
> > > Thanks!
> > >
> > > Greg.
> > take care, if you hit replay, the mails come only to me; you must
> > hit reply
> > all...now, let's get back to it
> > in the [global] section:
> > socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
> > kernel oplocks = no
> > max xmit = 16384
> > max xmit = 32768
> > read raw = no
> > write raw = no
> > read size = 32768
> >
> > in the dos share section put
> > veto oplock files = ......
> >
> > this setup is working for me since last summer redhat 7.1 also, 2.2.1a
> > compiled from source; pay attention to 'kernel oplocks'
> > parameter, it must be
> > 'no' (it is automatically yes on a 2.4 kernel, but it
doesn't work as
> > advertised on it).
> > let me hear about your success (I hope!)...
> >
> > dragos
>
> ***********************************************************************
> This is a confidential communication between sender and addressee. If you
> are not the intended recipient of this message, please notify the
> sender and
> do not read, copy, use or disclose this communication to others. Any
> opinions or views expressed are those of the individual, and unless
> otherwise stated, are not those of the company. All attachments and
> intellectual rights remain the property of GML (NT) Limited.
> ***********************************************************************
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: http://lists.samba.org/mailman/listinfo/samba
>
***********************************************************************
This is a confidential communication between sender and addressee. If you are
not the intended recipient of this message, please notify the sender and do not
read, copy, use or disclose this communication to others. Any opinions or views
expressed are those of the individual, and unless otherwise stated, are not
those of the company. All attachments and intellectual rights remain the
property of GML (NT) Limited.
***********************************************************************
Hi John, Thanks for the comments, but the original problem was entirely to do with Win2K and Win98! I have a Linux Samba Server that provides network drives to a small LAN. The client already had three networked DOS apps running off this Samba Server. I added a fourth, and a problem reared it's ugly head.... One single user could access the net app, but when a second tried to log in, the Windows client froze for about 30 secs, then returned "Unknown disc error on drive X", and the app bombed out. Thanks to this group, I've solved the problem within twelve hours of my original posting! For which I am most grateful. For all those that missed it, adding the line 'kernel oplocks = no' fixed it. But your input is also very welcomed, thanks! Regards, Greg.> -----Original Message----- > From: Nelson, John P. [mailto:john.nelson@teradyne.com] > Sent: 29 January 2002 18:52 > To: 'greg@gmlnt.com' > Subject: Re: [Samba]DOS app won't run off a Samba drive! > > > >Hi Rashkae, > > You sent this to the list, so I assume you don't mind someone else poking > their nose in. > > I didn't see the original question (I just can't keep up with the > volume on > the Samba list). From the subject line, I think I know the > problem. There > is a bug in Win9x with long directory names in a network share. > If you try > to run a DOS program from a directory that contains "long" directory name > components (more than 8.3 filenames), it will not run properly. > This is not > specific to Samba - it behaves the same way if the files reside on an > NT/Win2k server (with the same pathname). The bug is in Win9X itself. > > I used to know what the failure mechanism was, but I forget now. > But if you > eliminate any "long" pathname components, it doesn't happen. And the > problem doesn't impact Windows NT client systems. It also doesn't impact > WIN32 applications. > > >Well, all these "oplocks" are a little new to me! > > Oplocks (short for opportunistics locks) are an optimization for better > performance! > > Oplocks allow a client to cache a file's data locally, without > the overhead > of continuously syncronizing with the server. The server can grant a read > oplock to multiple clients which allows them to cache the file contents > without checking for changes on the server - any network request to modify > the file will cause the server to revoke all read oplocks, which causes > clients to revert to normal behavior. A write oplock can only be > granted if > a single client has the file open - this allows the client to > cache changes > to the file locally - whenever another client requests any form > of access to > the file, the oplock is revoked and the client with the lock must > commit any > changes to the network copy. > > >you can put a "oplocks" section in the [global] section, to > enable oplocks > - > >are they enabled by default? > > Oplocks are enabled by default. It turns out that they result in a > significant improvement in throughput. > > The biggest problem with using oplocks is if you share files between unix > applications and PC clients - most unixes do not understand the oplock > protocol. Enabling oplocks may result in unexpected caching > behavior on the > PC clients. > > Other than that, there is no reason to disable oplocks. > Databases work fine > with oplocks - if more than one client tries to use the database, then > oplocks with be denied (or revoked). The only case where oplocks are a > problem would be a database that is shared between PC and unix client > applications. > > >you can then put a "veto oplocks" section into individual shares > ie [data], > >to remove oplocks from that particular share. > > "Veto oplocks" is used to remove oplock behavior from specific filenames. > If you want to remove oplocking behavior from a share, simply put > "oplocks > NO" in the definition of the share. > > >Why do my Win2k > >machines work be default but not my Win98 machines? > > I'm guessing that this has NOTHING to do with oplocks. Of > course, I haven't > heard the whole story, so I could be wrong. > > sincerely, > > - john nelson (john.nelson@teradyne.com)*********************************************************************** This is a confidential communication between sender and addressee. If you are not the intended recipient of this message, please notify the sender and do not read, copy, use or disclose this communication to others. Any opinions or views expressed are those of the individual, and unless otherwise stated, are not those of the company. All attachments and intellectual rights remain the property of GML (NT) Limited. ***********************************************************************