Bug 8042 - Newly create files are always failed with NT_STATUS_FILE_IS_A_DIRECTORY
Newly create files are always failed with NT_STATUS_FILE_IS_A_DIRECTORY
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.8
All Mac OS X
: P5 major
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-26 12:08 UTC by TAKAHASHI Motonobu
Modified: 2011-04-07 19:11 UTC (History)
0 users

See Also:


Attachments
Level 10 log when running "echo aaa > test1.txt" (49.13 KB, application/octet-stream)
2011-03-26 12:15 UTC, TAKAHASHI Motonobu
no flags Details
Level 10 log when running "echo aaa > test1.txt" (71.06 KB, application/gzip)
2011-03-26 14:53 UTC, TAKAHASHI Motonobu
no flags Details
Packet caputure with Wireshark (6.36 KB, application/octet-stream)
2011-04-03 05:59 UTC, TAKAHASHI Motonobu
no flags Details
Patch for 3.5 (1.07 KB, patch)
2011-04-03 12:11 UTC, Volker Lendecke
jra: review-
Details
Modified fix - moves the location of the SET_STAT_INVALID. (1.06 KB, patch)
2011-04-04 17:10 UTC, Jeremy Allison
no flags Details
Fixed patch attribution - removed extraneous "else". (1.13 KB, patch)
2011-04-04 17:21 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TAKAHASHI Motonobu 2011-03-26 12:08:53 UTC
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
-----
Comment 1 TAKAHASHI Motonobu 2011-03-26 12:15:53 UTC
Created attachment 6351 [details]
Level 10 log when running "echo aaa > test1.txt"

Please search the log with "NT_STATUS_FILE_IS_A_DIRECTORY".
Comment 2 TAKAHASHI Motonobu 2011-03-26 12:19:11 UTC
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
Comment 3 Volker Lendecke 2011-03-26 13:26:51 UTC
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
Comment 4 TAKAHASHI Motonobu 2011-03-26 14:53:20 UTC
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.
Comment 5 Volker Lendecke 2011-03-27 10:39:14 UTC
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
Comment 6 TAKAHASHI Motonobu 2011-04-03 05:59:48 UTC
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).
Comment 7 TAKAHASHI Motonobu 2011-04-03 06:05:40 UTC
(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'.
Comment 8 Volker Lendecke 2011-04-03 07:10:02 UTC
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
Comment 9 Volker Lendecke 2011-04-03 07:17:57 UTC
Ah, got it now. You tried twice. Had not read that initially. I definitely need to find such a box :-(

Volker
Comment 10 TAKAHASHI Motonobu 2011-04-03 08:30:27 UTC
(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.
Comment 11 Volker Lendecke 2011-04-03 12:11:45 UTC
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
Comment 12 TAKAHASHI Motonobu 2011-04-03 14:18:58 UTC
(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 13 Jeremy Allison 2011-04-04 17:04:51 UTC
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.
Comment 14 Jeremy Allison 2011-04-04 17:10:11 UTC
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.
Comment 15 Jeremy Allison 2011-04-04 17:21:18 UTC
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.
Comment 16 TAKAHASHI Motonobu 2011-04-05 23:33:45 UTC
(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!
Comment 17 Karolin Seeger 2011-04-07 19:11:49 UTC
Pushed to v3-5-test.
Will be included in the next release.
Closing out bug report.

Thanks!