Creating a file (not a directory) under any directores always failed with NT_STATUS_FILE_IS_A_DIRECTORY. After failed, a zero-byte file is created. To reprodule: 1) Compile Samba with configure --without-readline (*) (*) With "--with-readline", compile is failed on Mac OS X 10.6.7. 2) Create smb.conf for examples: [global] [homes] (*) writeable = yes browseable = no (*) Same problem occurs at other directories 3) Connect to the share from Windows For examples C:\> net use y: \\macosx\monyo /user:monyo Y:\> mkdir Test1 Y:\> cacls . Y:\ <Account Domain not found>F <Account Domain not found>R Everyone:R Y:\>cacls Test1 Y:\Test1 <Account Domain not found>F <Account Domain not found>R Everyone:R Y:\echo aaa > test1.txt <--- That's OK. Y:\>cd Test1 Y:\Test1>echo aaa > test1.txt Access is denied. <--- Failed. Y:\Test1>dir Volume in drive Y is monyo Volume Serial Number is 68E7-0433 Directory of Y:\Test1 2011/03/26 20:51 <DIR> . 2011/03/26 20:50 <DIR> .. 2011/03/26 20:51 0 test1.txt 1 File(s) 0 bytes 2 Dir(s) 22,608,707,584 bytes free I examine these environments: 1) Mac OS X 10.6.7 (x86) + gcc 4.2.1 (included in Xcode) 2) Mac OS X 10.4.11 (ppc) + gcc 4.0.0 (included in Xcode) Here is the output of "ls -lae" ----- # ls -lae /Users total 0 drwxr-xr-x 5 root admin 170 3 22 00:48 . drwxrwxr-t@ 34 root admin 1224 3 26 20:59 .. -rw-r--r-- 1 root wheel 0 7 1 2009 .localized drwxrwxrwt 4 root wheel 136 3 23 00:04 Shared drwxr-xr-x+ 21 monyo staff 714 3 26 20:50 monyo 0: group:everyone deny delete # ls -lae /Users/monyo total 24 drwxr-xr-x+ 21 monyo staff 714 3 26 20:50 . 0: group:everyone deny delete drwxr-xr-x 5 root admin 170 3 22 00:48 .. -rw------- 1 monyo staff 4 3 22 00:48 .CFUserTextEncoding -rw-r--r--@ 1 monyo staff 6148 3 22 09:00 .DS_Store drwx------ 2 monyo staff 68 3 26 20:25 .Trash -rw------- 1 monyo staff 0 3 23 08:02 .Xauthority drwxr-xr-x 2 monyo staff 68 3 26 02:45 .Xcode -rw------- 1 monyo staff 433 3 23 21:59 .bash_history drwx------ 3 monyo staff 102 3 22 00:57 .ssh drwx------+ 6 monyo staff 204 3 23 00:09 Desktop 0: group:everyone deny delete drwx------+ 5 monyo staff 170 3 26 02:45 Documents 0: group:everyone deny delete drwx------+ 4 monyo staff 136 3 22 00:48 Downloads 0: group:everyone deny delete drwx------+ 31 monyo staff 1054 3 26 02:50 Library 0: group:everyone deny delete drwx------+ 3 monyo staff 102 3 22 00:48 Movies 0: group:everyone deny delete drwx------+ 4 monyo staff 136 3 23 00:04 Music 0: group:everyone deny delete drwx------+ 4 monyo staff 136 3 22 00:48 Pictures 0: group:everyone deny delete drwxr-xr-x+ 5 monyo staff 170 3 22 00:48 Public 0: group:everyone deny delete drwxr-xr-x+ 5 monyo staff 170 3 26 20:59 Sites 0: group:everyone deny delete drwxr-xr-x 3 monyo staff 102 3 26 20:51 Test1 # ls -lae /Users/monyo/Test1 total 0 drwxr-xr-x 3 monyo staff 102 3 26 20:51 . drwxr-xr-x+ 21 monyo staff 714 3 26 20:50 .. 0: group:everyone deny delete -rwxr--r-- 1 monyo staff 0 3 26 20:51 test1.txt -----
Created attachment 6351 [details] Level 10 log when running "echo aaa > test1.txt" Please search the log with "NT_STATUS_FILE_IS_A_DIRECTORY".
Level 10 log where NT_STATUS_FILE_IS_A_DIRECTORY occurs. [2011/03/26 21:11:44.771694, 10] smbd/open.c:1715(open_file_ntcreate) open_file_ntcreate: fname=., after mapping access_mask=0x2019f [2011/03/26 21:11:44.771861, 10] lib/dbwrap_tdb.c:100(db_tdb_fetch_locked) Locking key 0200000E000000009FBB [2011/03/26 21:11:44.772155, 10] lib/dbwrap_tdb.c:129(db_tdb_fetch_locked) Allocated locked data 0x0x100a3b600 [2011/03/26 21:11:44.772541, 10] smbd/open.c:1034(delay_for_oplocks) delay_for_oplocks: oplock type 0x3 on file .[2011/03/26 21:11:44.772721, 10] smbd/open.c:1034(delay_for_oplocks) delay_for_oplocks: oplock type 0x3 on file . [2011/03/26 21:11:44.772807, 4] smbd/open.c:1977(open_file_ntcreate) calling open_file with flags=0x2 flags2=0x0 mode=0744, access_mask = 0x2019f, open_access_mask = 0x2019f [2011/03/26 21:11:44.773075, 10] smbd/open.c:170(fd_open) fd_open: name ., flags = 02 mode = 0744, fd = -1. Is a directory [2011/03/26 21:11:44.773167, 3] smbd/open.c:461(open_file) Error opening file . (NT_STATUS_FILE_IS_A_DIRECTORY) (local_flags=2) (flags=2) [2011/03/26 21:11:44.773380, 10] lib/dbwrap_tdb.c:42(db_tdb_record_destr) Unlocking key 0200000E000000009FBB [2011/03/26 21:11:44.773499, 5] smbd/files.c:497(file_free) freed files structure 11808 (0 used) [2011/03/26 21:11:44.773587, 10] smbd/open.c:3210(create_file_unixpath) create_file_unixpath: NT_STATUS_FILE_IS_A_DIRECTORY [2011/03/26 21:11:44.773673, 10] smbd/open.c:3463(create_file_default) create_file: NT_STATUS_FILE_IS_A_DIRECTORY[2011/03/26 21:11:44.773760, 3] smbd/error.c:80(error_packet_set) error packet at smbd/error.c(160) cmd=162 (SMBntcreateX) NT_STATUS_FILE_IS_A_DIRECTORY
On Sat, Mar 26, 2011 at 12:19:11PM +0000, samba-bugs@samba.org wrote: > https://bugzilla.samba.org/show_bug.cgi?id=8042 > > --- Comment #2 from TAKAHASHI Motonobu <monyo@samba.gr.jp> 2011-03-26 12:19:11 UTC --- > Level 10 log where NT_STATUS_FILE_IS_A_DIRECTORY occurs. That NT_STATUS_FILE_IS_A_DIRECTORY seems more like a OS/X artifact. The from my point of view more relevant error is further down: [2011/03/26 21:11:53.021828, 3] smbd/open.c:461(open_file) Error opening file Test1/test1.txt (NT_STATUS_ACCESS_DENIED) (local_flags=514) (flags=1538) Can you check you have the right permissions on Test1? Volker
Created attachment 6352 [details] Level 10 log when running "echo aaa > test1.txt" (In reply to comment #3) I'm sorry, the previous logfile is wrong. As you suspect, I created Test1 directory by root. I re-created Test1 directory by monyo, the user who connected from Windows and re-produced the issue. Please the logfile attached now.
On Sat, Mar 26, 2011 at 02:53:21PM +0000, samba-bugs@samba.org wrote: > Created attachment 6352 [details] > --> https://bugzilla.samba.org/attachment.cgi?id=6352 > Level 10 log when running "echo aaa > test1.txt" Ok, thanks. I modified smbclient to create a file with exactly the same flags as OS/X does it, but I could successfully create the file. Next steps to diagnose this would be a network trace and an strace (maybe ktrace/kdump or truss under OS/X ?) of smbd giving that error message. Volker
Created attachment 6369 [details] Packet caputure with Wireshark (In reply to comment #5) > Next steps to diagnose this would be a network trace and an > strace (maybe ktrace/kdump or truss under OS/X ?) of smbd > giving that error message. Here is some descriptions about the attached network trace. 192.168.135.128 is the Mac OS X box and 192.168.135.1 is Windows XP SP3 client. During capturing, I type these commands on Windows XP: ----- C:\>net use o: \\192.168.135.128\test1 C:\>o: (Start capturing) O:\>echo test1 > test1.txt <-- (1) O:\>cd work O:\work>echo test2 > test2.txt <-- (2) Access is denied. O:\work>echo test2a > test2.txt <-- (3) O:\work> (Stop capturing) ----- Frame No.1 and 3 are correspond to (1). Frame No.31 and 33 are correspond to (2). I cannot find any usefull information in Frame No.33. Frame No.35 and 37 are correspond to (3).
(In reply to comment #6) Some additional information: My smb.conf: ----- [global] [test1] path = /test1 writeable = yes ----- Informations about /test1: ----- sleopard-1:/ monyo$ ls -laR /test1 total 0 drwxrwxrwt 3 root admin 102 4 3 15:04 . drwxrwxr-t@ 34 root admin 1224 3 26 20:59 .. drwxr-xr-x 2 monyo admin 68 4 3 15:04 work /test1/work: total 0 drwxr-xr-x 2 monyo admin 68 4 3 15:04 . drwxrwxrwt 3 root admin 102 4 3 15:04 .. sleopard-1:/ monyo$ ----- Of course I connect with user 'monyo'.
That's interesting. In frame 33 we give the error message, but in frame 37 we give a correct result, and OS/X writes "test2a" into the file. I think at some point I need access to such a box to really diagnose this. All I have is an older OS/X, and I doubt Apple will sponsor a newer operating system. Volker
Ah, got it now. You tried twice. Had not read that initially. I definitely need to find such a box :-( Volker
(In reply to comment #8) > All I have is an older OS/X As I said Comment #0, > I examine these environments: > 1) Mac OS X 10.6.7 (x86) + gcc 4.2.1 (included in Xcode) > 2) Mac OS X 10.4.11 (ppc) + gcc 4.0.0 (included in Xcode) The same problem occurs in older platform (with newer Samba). So you may reproduce on your Mac OS X.
Created attachment 6370 [details] Patch for 3.5 Could reproduce it with an older OS/X. The critical feature is the case insensitive file system. This patch fixes it for me, can you give it a try? No way I could have found this just from the traces. Thanks, Volker
(In reply to comment #11) > Could reproduce it with an older OS/X. The critical feature is the case > insensitive file system. > > This patch fixes it for me, can you give it a try? In my x86 environment (Mac OS X 10.6.7), The issue is fixed. In my ppc environment (Mac OS X 10.4.11), I'm just compiling... Sorry, it's very old and slow iBook.
Comment on attachment 6370 [details] Patch for 3.5 That's amazing work ! I don't know how you found that :-). Now I finally understand the error, I don't think this change is in quite the correct place. Although it covers the problem path, it isn't defensive against other codepaths we might introduce that might end up using smb_fname. I will post a modified fix for you to review. Jeremy.
Created attachment 6373 [details] Modified fix - moves the location of the SET_STAT_INVALID. I think this patch is slightly better, as it covers all possible codepaths after the VFS_STAT returns != 0. It also fits better with the code patterns we have in the rest of the file, where we should always do: ------------------------------------------------------ if (posix_pathnames) { ret = SMB_VFS_LSTAT(conn, smb_fname); } else { ret = SMB_VFS_STAT(conn, smb_fname); } if (ret != 0) { SET_STAT_INVALID(smb_fname->st); } ------------------------------------------------------ (i.e. set the stat invalid as soon as possible after the stat call). Jeremy.
Created attachment 6374 [details] Fixed patch attribution - removed extraneous "else". Modified fix - moves the location of the SET_STAT_INVALID. I think this patch is slightly better, as it covers all possible codepaths after the VFS_STAT returns != 0. It also fits better with the code patterns we have in the rest of the file, where we should always do: ------------------------------------------------------ if (posix_pathnames) { ret = SMB_VFS_LSTAT(conn, smb_fname); } else { ret = SMB_VFS_STAT(conn, smb_fname); } if (ret != 0) { SET_STAT_INVALID(smb_fname->st); } ------------------------------------------------------ (i.e. set the stat invalid as soon as possible after the stat call). Jeremy.
(In reply to comment #15) > Created attachment 6374 [details] > Fixed patch attribution - removed extraneous "else". > > Modified fix - moves the location of the SET_STAT_INVALID. > > I think this patch is slightly better, as it covers all possible codepaths > after the VFS_STAT returns != 0. I examined this patch for Samba 3.5.8 on Mac OS X 10.6.7 and it works well. Thanks!
Pushed to v3-5-test. Will be included in the next release. Closing out bug report. Thanks!