How to prevent samba from holding a file lock after a client disconnects?

Here I have a Samba server (Debian 5.0) thats is configured to host Windows XP profiles.

Clients connects to this server and work on their profiles directly on the samba share (the profile is not copied locally).

Every now and then, a client may not shutdown properly and thus Windows does not free the file locks. When looking at the samba locking table, we can see that many files are still locked even though the client is not connected anymore. In our case, this seems to occur with lockfiles created by Mozilla Thunderbird and Firefox. Here's an example of the samba locking table:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

We can see that the files were opened by Windows and imposed a DENY_ALL lock.

Now when a client reconnects to this share and tries to open those files, samba says that they are locked and denies access.

Is there any way to work around this situation or am I missing something?

Edit: We would like to avoid disabling file locks on the samba server because there are good reasons to have those enabled.

the below steps have helped me resolve this exact issue on a number of occasions:

1. Login to the samba server.
2. Run a "smbstatus".
3. Find the pid of the process that has the lock on the file in the third section of the output.
4. Verify that it matches the expected user and hostname in the first and second sections of the smbstatus output.
5. Run "ps -ef" and see how long the smbd with that pid has been running.
6. If it has been running since before the computer was last rebooted, it's a left over smbd. Kill JUST THAT ONE smbd. (And make sure you get the right one -- it should be one that has a parent pid not equal to 1.)

Have a look at:

reset on zero vc = yes / no

and see if that will fix your problem or not.

From the smb.conf man page:

This boolean option controls whether an incoming session setup should kill other connections coming from the same IP. This matches the default Windows 2003 behavior. Setting this parameter to yes becomes necessary when you have a flaky network and windows decides to reconnect while the old connection still has files with share modes open. These files become inaccessible over the new connection. The client sends a zero VC on the new connection, and Windows 2003 kills all other connections coming from the same IP. This way the locked files are accessible again. Please be aware that enabling this option will kill connections behind a masquerading router.

Edit:
I just thought over another possible solution. You could do something like this on the share in question.

veto oplock files = /*.lock/

This would just prevent oplocks on .lock files.