I recently installed my first production RH 6.0 system for a
client. It's use was primarily a file/print server
replacement for an old Netware 3.12 box we had installed
Upon installing/testing their primary (network) application
I encountered problems. Only one user could enter and use
the system at a time. After many hours of hunting I have
traced it to some problem between glibc2.1 and Samba.
problems accessing files in a shared/locked manner
Log entries such as:
[1999/05/22 14:42:07, 3] lib/util.c:fcntl_lock(2658)
fcntl lock gave errno 11 (Resource temporarily
in the [global] section set oplocks = false
This is the easiest but you might experience a severe
performance impact (I know my client wasn't happy with this
which is partly why I kept digging)
install the compat-glibc-5.2-22.214.171.124 RPM
Probably in the /etc/rc.d/init.d/smb script.
This seems to fix the problem and preserve the oplock
ability (and thus, the speed)
I marked this as high priority/high severity since Samba is,
at least from what I see, a major reason people use Linux.
You could theoretically get by without ever noticing this
problem if your uses of the server were minimal and two
people never tried accessing the same file at once but in
any serious server environment this could cause massive
failures and headaches (at the least) and maybe even severe
data loss (I'm not smart enough about oplocks, windows
filesharing/record locking, and samba to know if that is
true or not).
I suggest as a temporary solution releasing an initscripts
upgrade for all your users. Of course, you don't need me to
tell you how to do your job *laugh*.
Congrats on an otherwise great product! :)
If you need more info please feel free to contact me.
I meant releasing an update to the samba scripts, not initscripts.
Duh. Serves me right for trying to start work at 7:30 AM on a Sunday
Actually, I'm suprised it would run with the compat libs; that's
not really a solution. The correct solution would be to find
out what the conflict is with glibc2.1, and fix that.
In fact, testing reveals that samba shouldn't even *run* with
the glibc2.0 compat libs. Are you sure you aren't running an
older/rebuilt samba version? What happens if you shut down the
current version and run (from the command line)
Also, are you sharing local files, or files that are mounted
from another server?
What file is it that's having locking problems?
Well... even while doing it I knew that using the compat libs was
definily not the "correct" solution, not any more then globally
setting oplocks=false. But Samba ran, my application was happy so I
went with it. I certainly don't have the knowledge of Samba or the
programming experience to have fixed or further diagnosed such a
problem (tho I hope to change that some day). After having two weeks
with egg on my face I was desperate to give the client anything to
make things chug along.
All the files were on a standalone box, no network drive mounts.
There were a number of files that were having problems. Part of the
Business Works accounting package from State of the Art software
(www.sota.com). Business Works has been running flawlessly on my
office's various versions of Red Hat (currently 5.2) since we phased
Netware out about 3 years ago. I privately received email from
another Samba on RH 6.0 user who was experiencing similar locking
problems with Word/Excel documents. I can give you his email addy if
that would help.
I'm afraid that the testbed I was using has been disconnected so it
would be very hard at this point for me to try any additional
conditions at this time.
That might help. So far, I'm noticing identical locking
behavior between 5.2 & 6.0 here (I can't reproduce it.)
I have the Samba logs at both level 3 and level 12 from the failed
tests on Saturday. I can provide those if you would like (warning:
I could also maybe have the test network re-setup but it would take me
a day or two. I am currently working out of home so moving hardware
around in the office would be difficult :)
Also, I have the email from the other person who was having problems.
I can forward that to you if you tell me where you would like it sent.
On the samba mailing list Jeremy Allison said he thinks there is a
problem with how the Samba autoconf picks a 32 vs 64 bit locking
compatibility option with glibc2.1. I had neglected to mention it was
Windows 95 and not NT on that post and his reply specifically
mentioned NT having the bug. Whether it would apply to 95/98 too or
not I don't know.
Well, there is this in the Samba 2.0.4 changelog:
(on new parameters)
This parameter was added to get around a bug in Windows NT
when dealing with Samba running on 32-bit systems (such
as Linux x86). This bug causes NT to send 64 bit locking
requests to 32-bit systems even though Samba correctly
tells the NT client not to do so. This option causes Samba
to map the lock requests from 64 bits to 32 bits on these
If you could send the large stuff & the forwarded
e-mail to firstname.lastname@example.org (not bugzilla), I'll
look at it.
fixed in samba-2.0.4b-2, which will be in the next
Raw Hide release.
*** Bug 3715 has been marked as a duplicate of this bug. ***
> To any one who is using Red Hat Linux 6.0 (or, presumably,
> I recently installed a new RH 6.0 system on Intel. After
> samba and my network application I noticed that I was
> 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
> seems to be with oplocks I don't know if this could cause
> 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
> Evidence of the problem are log entries like the following
> 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
> 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
> performance hit.
> 2 - The better fix, IMHO, is to do the following
> rpm -Uvh
> edit /etc/rc.d/init.d/smb
> 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 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
> I don't know if this is a Samba bug for not following some
> API change or just a glibc2.1 bug. But Samba is the only
> 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.
Ok, I'm pretty sure what's going on here. I'm also CC:ingThe
problem is that WinNT has a bug in which it sends 64
bit lock range requests to systems that only have 32 bit
lock ranges available, despite being told via the protocol
not to do so (just another area they never tested I guess).
Samba is fully 64-bit clean on a 64 bit system and will
work fine on these systems. Unfortunately x86 linux is only
a 32 bit system. Samba 2.0.4 has a fix in it in that if it
detects it is running on a 32-bit system it will 'fold' the
64 bit lock range into 32 bits as best it can. It needs to
do this as applications like Word and Excel need byte range
locks to conflict correctly in order to detect multiple
on a file. This works all well and good on glibc2.0 systems
(which Samba detects as 32 bit lock aware).
But glibc2.1 lies on a Linux x86 system :-). It tells Samba
that it can do 64 bit lock reqests. It can't. What glibc2.1
does is just drop the top 32 bits of any range request. This
causes the bottom half of the lock ranges to collide with
earlier lock ranges - hence the messages you are getting.
Now Samba has the code to work correctly with glibc2.1, it
just needs to stop believing that glibc2.1 is a 64 bit lock
aware library on a 32 bit system. Personally I think this is
a glibc2.1 bug on x86 Linux. As Samba already contains the
correct code (as evidenced by the fact it works with the
glibc2.0 libraries) we need to find a way for the Samba
autoconf scripts to detect lying libc libraries and turn
on the 32-bit workaround automatically on Linux x86
this to Ulich Drepper who is the maintainer of the glibc
library at Cygnus & also Erik Troan at RedHat.
Commit pushed to master at https://github.com/openshift/origin
Merge pull request #4780 from rhcarvalho/issue2982-pushspec-in-build-status
Merged by openshift-bot