From: Vipin Khushu (VipinK@NEOSUSA.COM)
Date: Wed Nov 06 2002 - 10:36:54 EST
Thank you,
Vipin Khushu
781-794 8800 x244
-----Original Message-----
From: Jerry Gelaude [mailto:ggelaude@SUMINET.NET]
Sent: Tuesday, November 05, 2002 10:51 PM
To: aix-l@Princeton.EDU
Subject: Re: samba question
>From a www.google.com search on comp.* for newsgroups and "Samba the
semaphore time out period has expired" for key words.
Also, have you downloaded the "Samba Installation, Configuration, and
Sizing Guide"
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246004.pdf
Best of luck.
Jerry
Message 1 in thread
From: Mark Schwarz (markschwarz@tamu.edu)
Subject: semaphore timeout solution
View this article only
Newsgroups: comp.protocols.smb
Date: 2002-02-22 22:48:17 PST
Some of you may be having a problem with "Semaphore timeout period has
expired" errors when using Samba and Windows 2000. I've had this
problem twice. The first time, the problem went away by
itself after a few days. I think I finally found a solution this
time. I found this bit in the documentation from the latest Samba
release:
Locking
=======
The locking calls available under a DOS/Windows environment are much
richer than those available in unix. This means a unix server (like
Samba) choosing to use the standard fcntl() based unix locking calls
to implement SMB locking has to improvise a bit.
One major problem is that dos locks can be in a 32 bit (unsigned)
range. Unix locking calls are 32 bits, but are signed, giving only a
31 bit range. Unfortunately OLE2 clients use the top bit to select a
locking range used for OLE semaphores.
To work around this problem Samba compresses the 32 bit range into 31
bits by appropriate bit shifting. This seems to work but is not ideal.
In a future version a separate SMB lockd may be added to cope
with the problem.
It also doesn't help that many unix lockd daemons are very buggy and
crash at the slightest provocation. They normally go mostly unused in
a unix environment because few unix programs use byte range
locking. The stress of huge numbers of lock requests from dos/windows
clients can kill the daemon on some systems.
The second major problem is the "opportunistic locking" requested by
some clients. If a client requests opportunistic locking then it is
asking the server to notify it if anyone else tries to do something on
the same file, at which time the client will say if it is willing to
give up its lock. Unix has no simple way of implementing
opportunistic locking, and currently Samba has no support for it.
=======
To fix the "Semaphore timeout period has expired" problem on my Redhat
7.0 box I restarted the nfslock and smb daemons:
/etc/init.d/nfslock restart
/etc/init.d/smb restart
That fixed the problem.
I hope this works for you.
I've had no luck finding any other solutions in newsgroups, so I
thought I'd post a solution here.
- Mark
This is the only article in this thread
On Tue, 5 Nov 2002 14:02:19 -0500, you wrote:
>
>the semaphore time out period has expired
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:18 EDT