Guys, I am facing some strange error with the open_file_ntcreate api in 3.0.28a version and symantec backup 1.12.5. We upgraded the samba from 3.0.14 to 3.0.28a for our NAS product. Everything was smooth until one of our customers found this issue with Symantec backup application. It doesn't work with NAS saying that file creation is not allowed. Here is the related log: Mar 4 19:40:45 Star-6K smbd[26735]: [2003/03/04 19:40:45, 0] smbd/open.c:open_file_ntcreate(1724) Mar 4 19:40:45 Star-6K smbd[26735]: Could not get share mode lock Mar 4 19:40:45 Star-6K smbd[26735]: [2003/03/04 19:40:45, 0] smbd/open.c:open_file_ntcreate(1724) Mar 4 19:40:45 Star-6K smbd[26735]: Could not get share mode lock Mar 4 19:40:45 Star-6K smbd[26735]: [2003/03/04 19:40:45, 0] smbd/open.c:open_file_ntcreate(1724) Mar 4 19:40:45 Star-6K smbd[26735]: Could not get share mode lock Mar 4 19:40:57 Star-6K smbd[26735]: [2003/03/04 19:40:57, 1] smbd/service.c:close_cnum(1231) Mar 4 19:40:57 Star-6K smbd[26735]: nas-pc25 (192.168.200.79) closed connection to service share1 Actually we had modified the smbd/open.c to have common file locking working. Here is the patch: diff -Naur source/smbd/open.c source/smbd/open.c --- source/smbd/open.c 2008-07-24 01:56:13.948660848 -0700 +++ source/smbd/open.c 2008-07-29 00:04:08.676849728 -0700 @@ -1718,15 +1718,17 @@ the kernel refuses the operations then the kernel is wrong. note that GPFS supports it as well - jmcd */ + if ( fsp->fh->fd > 0 ) { ret_flock = SMB_VFS_KERNEL_FLOCK(fsp, fsp->fh->fd, share_access); - if(ret_flock == -1 ){ - + if( file_existed && (ret_flock == 0) ){ + DEBUG(0, ("Could not get share mode lock\n")); TALLOC_FREE(lck); fd_close(conn, fsp); file_free(fsp); return NT_STATUS_SHARING_VIOLATION; } + } And the line number log corresponds to is locking code. Can anyone review this patch and let me know what's going wrong? Thanks Sagar
Created attachment 3997 [details] symantec backup log
Can you please send a debug level 10 log and a sniff? Thanks, Volker
Sorry for the delay. I checked with the ethereal and found that while creating some configuration files, it fails with sharing access violation. Especially while creating folder.cfg. Initial login succeeds but the successive lock fails. Thanks Sagar
Created attachment 4076
is this still an issue with 3.5 ?
no feedback since 2.5 years. I speculate that it works now. If not, please reopen. Thanks