[Samba] Problems related to error status_file_locking_conflict

[Robert W. Smith]

OK. I think I have tracked this problem down and have been able to
backout out the recommended changes below. Here is what I found.

Somehow through the PAM authentication modules the users home
directories were being mounted on top of themselves as NFS4 shares on
the Samba server (this server can also share up the home directories
using NFS4 for the Linux users). I was using pam_mount.so on this server
but am not positive of the vector that really caused the users home
directories to mount when authenticated via samba.

By fixing pam_mount to not mount itself and then unmounting any
incorrect mounts I verified that this was causing the initial reported
symptoms. I then restored kernel oplocks = yes (default) and restore the
shares to the default oplocks settings and everything works as expected
and users log in times from login to desktop is back to ~10secs.

So, yea, I guess I did step on myself with this one but in the process I
learned alot more about how locking works in Linux and Samba.

Bob
Part-time self-inflicted Linux administrator
--bs

On Tue, 2010-08-24 at 07:04 +0200, Volker Lendecke wrote:

> On Mon, Aug 23, 2010 at 11:34:21PM -0400, Robert W. Smith wrote:
> > OK, so far I now understand that this is _NOT_ a general login issue
> > _NOR_ is it a MS credentials file issue either. This appears to be a
> > general locking issue in Samba and Linux. Here is a snippet of my
> > workstation log with another application that now no longer runs. The
> > SMB network transactions are the same as are the results for the user
> > (me, Quicken will no longer start and I am about to be hit with a late
> > charge $(
> > 
> > Note the delay between the linux_set_kernel_oplock failure and the
> > reporting of the SMB error NT_STATUS_FILE_LOCK_CONFLICT.
> 
> To avoid the issue, try "kernel oplocks = no". This does not
> really solve the issue, but might help you over the current
> problems.
> 
> Volker