[Samba] win2k/xp clients cannot copy files after samba upgrade

[Andrew Morgan]

On Thu, 28 Jun 2007, Dirk Kleinhesselink wrote:

> I have a linux server that I'm preparing to migrate our samba services to.
> It has been running as a stand alone server and I intend to set it up
> as a PDC - we have another old system working as a PDC now.
>
> Because of some problems during samba testing (quite awhile ago) I decided
> to upgrade the samba version running on the server - the original packaged
> samba was 3.0.20 and I downloaded 3.0.25a and built it.  Windows clients
> are getting this error when copying files to the server:
>
> "cannot copy {file}: The process cannot access the file because another
> process has locked a portion of the file"
>
> using smbclient from a linux machine does not give a problem and I can
> put files OK.  Windows clients can create and delete folders OK.  If I
> kill the new version and restart the old samba daemons, then things work
> fine.  With debug level 3, I can find this in the logs:
> cmd=47 SMBwriteX NT_STATUS_FILE_LOCK_CONFLICT
>
> I did some extensive testing with a similar install setup and
> did not have a problem until I realized that my test bed was running
> a hand built 2.6.14 kernel, whereas my server is running a 2.6.18 vendor
> supplied kernel.  I put the vendor supplied 2.6.18 kernel on my test
> machine and the problem then manifested itself.  I need the vendor supplied 
> kernel due to hardware setup on my server.  I tried a newer
> 2.6.19 kernel from them and still get the problem.
>
> More information - the problem is with shares that are nfs mounted.  I
> realize that sharing NFS mounted filesystems through samba may not be
> the most ideal, but I have a large fileserver that I don't want local
> users to have accounts on, yet be able to store data there.
>
> I tried setting kernel oplocks = no and oplocks = no  in the global
> parameters and this did not help.
>
> Anyone have any information that can help me resolve this situation ?
>
> Thanks for any help,
>
> Dirk

Another sysadmin where I work ran into this same problem and was able to 
fix it by setting:

strict locking = no

Apparently the default for this option changed in version 3.0.23.

 	Andy