13

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.

Jean-Francois Chevrette
  • 643
  • 2
  • 6
  • 8

7 Answers7

12

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.)
Socceroos
  • 221
  • 2
  • 3
  • 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 05:11
5

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.

chicks
  • 3,639
  • 10
  • 26
  • 36
3dinfluence
  • 12,409
  • 2
  • 27
  • 41
1

You can disable oplocks on a per-share basis with the following:

[acctdata]
oplocks = False
level2 oplocks = False

The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis in the smb.conf file. Alternately, you could disable oplocks on a per-file basis within the share:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

If you are experiencing problems with oplocks, as apparent from Samba's log entries, you may want to play it safe and disable oplocks and Level2 oplocks.

Disabling Kernel Oplocks Kernel oplocks is an smb.conf parameter that notifies Samba (if the UNIX kernel has the capability to send a Windows client an oplock break) when a UNIX process is attempting to open the file that is cached. This parameter addresses sharing files between UNIX and Windows with oplocks enabled on the Samba server: the UNIX process can open the file that is Oplocked (cached) by the Windows client and the smbd process will not send an oplock break, which exposes the file to the risk of data corruption. If the UNIX kernel has the ability to send an oplock break, then the kernel oplocks parameter enables Samba to send the oplock break. Kernel oplocks are enabled on a per-server basis in the smb.conf file.

kernel oplocks = yes

The default is no.

Source

acgbox
  • 243
  • 1
  • 5
  • 17
0

While googling my error, I crossed this page a lot. Maybe some one had the same problem and stranded also here:

failed to delete global key 'XXX': NT_STATUS_NOT_FOUND INTERNAL ERROR: Could not unlock share mode

I'd run low on space in /run/lock and this helped: mount -t tmpfs tmpfs /run/lock -o remount,size=85M

Lothrien
  • 1
0

I keep running into this thread trying to solve a similar issue. I need the Linux Samba server to process file locks against Window (10) file opens. I can't disable them. The applications depend on it. However, the server seems to lag on issuing and then releasing those locks. It will allow two processes (on separate machines) to open the same file, and it will prevent the program that "owns" the lock from deleting it when the file is closed (which should release the lock).

This isn't a consistent issue. It works correctly hundreds of times a day. It just causes a real mess when it doesn't work.

Reading a bit more on what an oplock actually is, if I disable those will the standard file locks still work? It sounds like an oplock is just a performance/caching mechanism that allows a process to "check out" the file and be responsible for it while checked out. If Windows is converting my "hard" file locks to oplocks, that could be my issue.

With oplocks disabled, I did this test. In one (Windows cmd.exe) process I opened a file for output and held it open. In another process, I tried to delete the file (del test.dat). The first time I tried, it returned with no error. When I tried again, I did get the access denied error. I could still see the file in the directory at that time. To make this even more fun, after I closed the file in the first process (with no errors), the file then disappeared from the folder as if the delete request had been cached and was waiting for the file lock to be released.

I'm going to reboot that PC since I restarted Samba and see if that makes any difference.

Bill Castle
  • 21
  • 4
0

Some very clever people at Samba decided to remove this option and there is no replacement for it.

So far for SMB compatibilty then, as this is indeed default win behaviour.

Unless a user is versed in the linux command line and how to kill open files/processes, you have to restart SMBD to or the server itself to clear this.

Wonderfully done, Samba.org.

Michael
  • 13
  • 3
  • Do you have a citation for this? – BE77Y Jan 02 '17 at 09:56
  • You'll have to look at a few to get there, but: https://lists.samba.org/archive/samba-technical/2011-July/078621.html (show the thought process and chaps pleading for it not to be removed) https://lists.samba.org/archive/samba-technical/2008-October/061703.html (shows the parameter has been removed in 4.0) – Michael Jan 08 '17 at 19:00
  • As of 2019, in Debian 9 - Samba 4.5.12, the `reset on zero vc` option is still listed in the manual, and also displayed by `testparm`. So either it is back, or it really had not been removed. – mivk Jun 27 '19 at 12:22
0

I was running into a similar problem, a client crashed while copying a large file and the file was locked after the reboot. Luckily this does not happen very often, but still it's quite annoying having to kill the samba process. reset on zero vc seemed to be just the solution, but it's supposedly removed from Samba4, though Version 4.7.6 on Fedora (27) still has it (possibly patched in by RH). It won't help much anyway, as the man page now says, that it only works with SMB1 ( which shouldn't be used any more) and does nothing on SMB2 and SMB3 connections, the only way left to handle this is mentioned in the thread linked by Micheal. I don't know the rationale behind the removal and what's so bad about reset on zero vc, I would consider using tcp timeout for this purpose more like a hack. Anyway something reasonable could be e.g.

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

This will kill the connection about 40 seconds (30+3*3) after the last communication, which is usually more than enough for noticing a crash and rebooting (given that the the server's tcp stack is smart enough to close the connection when the client rejects its keepalive packets after the reboot).

Note that this increases the load on your network, but I doubt that it's even noticeable even with a lot of clients.

Alexander Tolkachev
  • 4,513
  • 3
  • 14
  • 23
Jakob
  • 136
  • 4
  • Are you aware whether this helps with the bizarre Windows10 client "nobody nogroup" zombie thread problem? Many of my Windows10 clients at several sites have started to leave hundreds (occasionally thousands) of zombie threads which get assigned to "nobody nogroup" until their handler process is killed/retires. Normally setting `deadtime = 10` or so would clear it, but with the file locks lingering on SMB3_11 connections forever it has no effect, as deadtime won't be checked while filelocks for a PID still exist. Extremely frustrating. – zxq9 May 08 '18 at 05:17
  • I never heard of or experienced the problem you describe. `deadtime` does nothing if your clients have files open, so the question would be, which files they keep open. But that's probably a whole different issue than the one discussed here, so you should open a new question for this. My `socket options` suggestion only helps with connections that are not properly closed (because the clients crashes, a network outage etc.), but probably not if your WX clients just connect to the server without any further action or using some kind of anonymous session (which `nobody.nogroup` suggests). – Jakob May 09 '18 at 06:42
  • There seems to be one [question](https://serverfault.com/questions/747528/when-accessing-samba-shares-from-windows-10-smbstatus-is-reporting-duplicate-no) about this problem, but without a real solution. It sound like it could be a samba issue that could be fixed in a more recent version. – Jakob May 09 '18 at 06:49
  • There are quite a few mentions of this on the mailing list, no real solution presented anywhere, and no version I've tried (every current branch but 4.9) fixes the problem. It is only with Windows10 clients. The nobody:nogroup thing is perplexing, as guest are disabled globally, no shares accept them, and the PID of the nobody entries is always the same as a single valid entry with a valid username. So you see `12345 someuser somegroup...` on one entry, then 800 `12345 nobody nogroup ...` entries, but only a handful of file locks (not 800). Very weird. Affects 3 of my client sites now. – zxq9 May 09 '18 at 09:35
  • This only becomes a resource constraint on high-activity sites, which is why I think it receives so little attention. *Most* of the time there is not a problem, so people just don't notice it and it sorta-kinda clears itself up whenever the clients actually do close their connection. – zxq9 May 09 '18 at 09:37