Samba 3.5.x fails smbtorture4 BASE-CREATEX_SHAREMODES_DIR test: # source4/bin/smbtorture //samba_IP/Admin -U Admin%password BASE-CREATEX_SHAREMODES_DIR Using seed 1297258152 test: CREATEX_SHAREMODES_DIR WARNING!: (torture/basic/denytest.c:2366) Incorrect status NT_STATUS_OBJECT_NAME_NOT_FOUND - should be NT_STATUS_OK { .cxd_test = 2, .cxd_flags = 0x1, .cxd_access1 = 0, .cxd_sharemode1=0, .cxd_access2= 0, .cxd_sharemode2=0, .cxd_result = { NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OBJECT_NAME_NOT_FOUND, }, .cxd_result2 = { NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OK, NT_STATUS_OBJECT_NAME_NOT_FOUND, }}, ... failure: CREATEX_SHAREMODES_DIR [ (torture/basic/denytest.c:2372) Incorrect status NT_STATUS_OBJECT_NAME_NOT_FOUND - should be NT_STATUS_OK Test creates a directory (named createx_dir\) and a file in that directory (named createx_dir\known) using absolute path (Root FID is 0) via NTCreateAndX request. Then it tries to access the known file with relative path (Root FID is the FID returned during the creation of the parent directory). When doing this, it gets STATUS_OBJECT_NAME_NOT_FOUND. Seems like the issue is NOT related to sharemode at all: the test fails for all combinations of sharemode. The only reason of failure is relative path (non-zero Root FID). Problematic flow is: reply_ntcreate_and_X -> SMB_VFS_CREATE_FILE(vfswrap_create_file) -> create_file_default -> create_file_unixpath -> open_file_ntcreate. Key log messages are below: [2011/02/09 17:18:49.343654, 10] smbd/nttrans.c:501(reply_ntcreate_and_X) reply_ntcreate_and_X: flags = 0x0, access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 root_dir_fid = 0x2376, fname = known [2011/02/09 17:18:49.344665, 10] smbd/open.c:3541(create_file_default) create_file: access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x0 private_flags = 0x0 root_dir_fid = 0x2376, ea_list = 0x(nil), sd = 0x(nil), fname = known [2011/02/09 17:18:49.344853, 10] smbd/vfs.c:974(check_reduced_name) check_reduced_name realpath [createx_dir/known] -> [/home/Admin/createx_dir/known] [2011/02/09 17:18:49.344963, 10] smbd/open.c:3068(create_file_unixpath) create_file_unixpath: access_mask = 0x1f01ff file_attributes = 0x80, share_access = 0x0, create_disposition = 0x1 create_options = 0x0 oplock_request = 0x0 private_flags = 0x0 ea_list = 0x(nil), sd = 0x(nil), fname = createx_dir/known [2011/02/09 17:18:49.345267, 10] smbd/open.c:1612(open_file_ntcreate) open_file_ntcreate: fname=createx_dir/known, dos_attrs=0x80 access_mask=0x1f01ff share_access=0x0 create_disposition = 0x1 create_options=0x0 unix mode=0744 oplock_request=0 private_flags = 0x0 [2011/02/09 17:18:49.345487, 3] smbd/vfs.c:1036(check_reduced_name) check_reduced_name: createx_dir/known reduced to /home/Admin/createx_dir/known [2011/02/09 17:18:49.345559, 5] smbd/open.c:1702(open_file_ntcreate) open_file_ntcreate: FILE_OPEN requested for file createx_dir/known and file doesn't exist. [2011/02/09 17:18:49.345860, 10] smbd/open.c:3374(create_file_unixpath) create_file_unixpath: NT_STATUS_OBJECT_NAME_NOT_FOUND From my point of view, the reason of failure is: the file cannot be stat'ed correctly until related filename ('known') is mapped to absolute ('createx_dir/known'). So all STATs until the call create_file_default->get_relative_fid_filename are not successful. Still after filename translation no STAT call is done any more, so translated smb_fname parameter contains invalid stat buffer. create_file_default attaches this smb_fname to new (created by file_new) fsp and calls open_file_ntcreate. Then bool file_existed = VALID_STAT(smb_fname->st); inside open_file_ntcreate means that the file is considered as non-existent, so due used create_disposition=FILE_OPEN we cannot open it... ENOENT/NT_STATUS_OBJECT_NAME_NOT_FOUND are returned for existent file... P.S. Bug is reproducible for current samba 3.5.x (fetched from git). Thanks.
I have a patch for this currently under test. Give me a day or so... Thanks, Jeremy.
Created attachment 6268 [details] Patch for 3.5.x. Please test - if it passes your testing (it does here) I'll get Volker to review to get this into 3.5.next. Jeremy.
Yes, tested on samba 3.5.4 - provided patch works as expected: [source4]# ./bin/smbtorture //172.41.45.10/share -U Admin%password BASE-CREATEX_SHAREMODES_DIR Using seed 1267008222 test: CREATEX_SHAREMODES_DIR 4096/ 4096 (0 skipped) success: CREATEX_SHAREMODES_DIR Thanks for support!
Comment on attachment 6268 [details] Patch for 3.5.x. Volker, please review for 3.5.next. Submitter confirms it works (and checked into master and 3.6.0). Jeremy.
Comment on attachment 6268 [details] Patch for 3.5.x. Looks good, thanks.
Karolin, this is 916e82823b56a70d7761644b38a250ea8c38e204 in master. The attachment here is not git am -3 format. The mentioned hash is equivalent and cleanly was applicable for me with git am -3. Thanks, Volker
Pushed to v3-5-test. Closing out bug report. Thanks!