Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

Have a look at reset on zero vc 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.

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.

share|improve this answer

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.)
share|improve this answer
Also, you may find that some smbd pids have been running for a few hours and the files they've locked are the ones you need. As above, just kill these processes and you should be fine. If you inadvertently kill the main smbd process then you can restart it with this command: sudo /etc/init.d/smbd restart – Socceroos Jul 17 '13 at 5:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.