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) (NT_STATUS_ACCESS_DENIED) 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 NT_STATUS_OBJECT_NAME_COLLISION [2016/10/27 03:56:34.811222, 3] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_OBJECT_NAME_COLLISION] || at ../source3/smbd/smb2_create.c:293 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 directories). 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)