RH6.0/Samba Oplock Problems (and fix)
Sean E. Millichamp
sean at compu-aid.com
Sun May 23 13:35:12 GMT 1999
To any one who is using Red Hat Linux 6.0 (or, presumably, any glibc2.1
I recently installed a new RH 6.0 system on Intel. After installing my
samba and my network application I noticed that I was experiencing oplock
problems that were not present with the same version of Samba on my RH 5.2
systems and caused my application to not function. Since the problem
seems to be with oplocks I don't know if this could cause data
corruption/inconsistency or not but I would assume so. I have tested this
both with Samba 2.0.3 (that ships with RH) and also Samba 2.0.4b. I have
also tried compiling Samba fresh (as opposed to using the binary RPMs).
Evidence of the problem are log entries like the following (gotten at
debug level=3 and higher)
[1999/05/22 14:42:06, 3] lib/util.c:fcntl_lock(2658)
fcntl lock gave errno 11 (Resource temporarily unavailable)
It seems that I only see "fcntl" when this error occurs so that may be a
safe expression to grep for if you want to look for it. I had quite a few
of these lines. Presumably my application trying to get to it's files
before it died a horrible death.
There are two fixes I've found for this so far:
1 - set oplocks = false for the system. The downside of this is that with
oplocks disabled you will have anywhere from a minor to a massive
2 - The better fix, IMHO, is to do the following
rpm -Uvh /path-to-redhat-6.0/compat-glibc-5.2-18.104.22.168.i386.rpm
In the "start)" case add
before the "daemon smbd -D" line
and then add
after the "daemon nmbd -D" line
(note: I haven't tried the above in a script yet, just manually with
manually executing smbd/nmbd but I see no reason why it would be any
different in a script)
As best I understand this, this points the dynamic linker to look in the
old glibc2.0 directory first to resolve objects. In this case it makes
Samba run as if it were still on a glibc2.0 (ie: RH 5.2) system and things
work fine again. It seems to run just fine like that and you can leave
oplocks enabled so your users/clients/self stop yelling at you :)
I don't know if this is a Samba bug for not following some new glibc2.1
API change or just a glibc2.1 bug. But Samba is the only application I've
had problems with so far so I'm starting here.
samba-bugs has been cc'd and I am also reporting this as a bug to Red Hat.
I consider this a pretty severe problem.
If anyone has any questions please feel free to ask me.
Sean E. Millichamp, Consultant
Ingematics - A Division of Compu-Aid, Inc.
More information about the samba