Bug 6192 - open_file_ntcreate fails with symantec backup v 1.12.5
open_file_ntcreate fails with symantec backup v 1.12.5
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.28a
Other Windows XP
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-17 00:15 UTC by Sagar
Modified: 2013-09-02 14:30 UTC (History)
0 users

See Also:


Attachments
symantec backup log (6.32 KB, text/plain)
2009-03-17 00:16 UTC, Sagar
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sagar 2009-03-17 00:15:01 UTC
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
Comment 1 Sagar 2009-03-17 00:16:54 UTC
Created attachment 3997 [details]
symantec backup log
Comment 2 Volker Lendecke 2009-03-17 02:21:21 UTC
Can you please send a debug level 10 log and a sniff?  Thanks,  Volker 
Comment 3 Sagar 2009-04-20 10:50:48 UTC
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
Comment 4 Sagar 2009-04-20 10:53:07 UTC
Created attachment 4076
Comment 5 Björn Jacke 2011-03-01 05:31:50 UTC
is this still an issue with 3.5 ?
Comment 6 Björn Jacke 2013-09-02 14:30:15 UTC
no feedback since 2.5 years. I speculate that it works now. If not, please reopen. Thanks