Dirk Kleinhesselink
2007-Jun-28 18:14 UTC
[Samba] win2k/xp clients cannot copy files after samba upgrade
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
Andrew Morgan
2007-Jun-28 22:39 UTC
[Samba] win2k/xp clients cannot copy files after samba upgrade
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, > > DirkAnother 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
Possibly Parallel Threads
- Problems related to error status_file_locking_conflict
- error packet at smbd/blocking.c(318) cmd=36 (SMBlockingX) NT_STATUS_FILE_LOCK_CONFLICT
- HELP: XP cannot login to Samba 2.2.5
- Samba 2.2.5/XP-Pro with Domain Account
- Refused oplock on NFS mounted file system