Bug 12397 - Windows explorer can create four copies of new directory when inherited permissions don't allow reading perms on newly created directory
Summary: Windows explorer can create four copies of new directory when inherited permi...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.5.0
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2016-10-28 19:41 UTC by Steve French
Modified: 2016-10-28 20:07 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Steve French 2016-10-28 19:41:43 UTC
Ran into an interesting scenario, that causes Windows explorer to
create four copies of a new directory when the user thinks directory
creation has failed - not sure how likely it is in practice but saw
the following if you set particular permissions (basically parent
directory allows things to be created under it, but the inherited
permissions for children don't allow that user or group to read the
file or its attributes).

Going into exploer and clicking new results in a series of create
(directory) calls which appear to fail, but which end up creating four
directories e.g. "New folder (1)" through "New folder (4)"   (The
server is Samba 4.5.1, various Windows clients - I was experimenting
with Windows 8.1, but later clients fail too)

An example of what you see in the log (stripping some boring ctdb stuff out):

Windows checks if directory ("New folder (17)" in the case below)
exists - which it doesn't.  So it sends a create (directory, sharing =
none) request:

Directory gets created ok:
[2016/10/27 03:56:34.629381,  5] ../source3/smbd/open.c:3460(open_directory)
  open_directory: opening directory New folder (17), access_mask =
0x17019b, share_access = 0x0 create_options = 0x1, create_disposition
= 0x2, file_attributes = 0x10
[2016/10/27 03:56:34.629417,  5] ../source3/smbd/dosmode.c:206(unix_mode)
  unix_mode: unix_mode(New folder (17)) returning 0777

But we return an error on the create call (presumably because we don't
have permissions):

[2016/10/27 03:56:34.648221,  5] ../source3/smbd/files.c:128(file_new)
  allocated file structure fnum 2475839843 (3 used)

[2016/10/27 03:56:34.649379,  5] ../source3/smbd/open.c:3661(open_directory)
  open_directory: Could not open fd for New folder (17)

Explorer will then retry the create with different sharing mode
(read/write instead of none) which will of course fail with (what is
to explorer a surprising error) a NAME_COLLISION since the directory
does in fact now exits even though explorer thinks it shouldn't since
it got an error on the previous create of the directory.

[2016/10/27 03:56:34.811202,  2] ../source3/smbd/open.c:3501(open_directory)

  open_directory: unable to create New folder (17). Error was

[2016/10/27 03:56:34.811222,  3]

  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1]

So it then tries again by bumping the last digit of the file name up
by 1 (and repeats this, and will try 4 times total so end up with 4

I realize that the permissions are a little strange (and I wasn't the
one who set the strange permissions, one of our testers was
experimenting) - but ... shouldn't we try to back out the damage if a
directory create "succeeds" but we report failure?

(Opening a bug per jra's request)