Bug 11589 - When Create File request returns NT_STATUS_EAS_NOT_SUPPORTED a zero length file is left behind
When Create File request returns NT_STATUS_EAS_NOT_SUPPORTED a zero length fi...
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2015-11-03 20:06 UTC by John Mulligan
Modified: 2015-11-17 10:32 UTC (History)
2 users (show)

See Also:

packet capture (7.57 KB, application/x-xz)
2015-11-03 20:06 UTC, John Mulligan
no flags Details
Workaround/patch (494 bytes, patch)
2015-11-03 20:08 UTC, John Mulligan
no flags Details
git-am fix for 4.3.next, 4.2.next. (1.40 KB, patch)
2015-11-04 22:08 UTC, Jeremy Allison
uri: review+

Note You need to log in before you can comment on or make changes to this bug.
Description John Mulligan 2015-11-03 20:06:15 UTC
Created attachment 11572 [details]
packet capture

I have reproduced this behavior on Samba 4.2.4 as well as 4.1.17. Samba has SMB3 enabled. Copy a file with EAs from a Windows 8 or Windows Server 2012 client to a share that has "ea support" = no (the default) using explorer. Before the copy was started there is no file with that name in the directory. A dialog appears indicating that the file exists prompting the user to overwrite or skip. Skipping or using the compare option in Windows shows that the file on the share is zero length. Copying a file without EAs behaves as expected, producing no error dialogs.

I have attached a tcpump capture that shows the create file request contains "ExtA" ExtraInfo and gets a response from the server of STATUS_EAS_NOT_SUPPORTED. The windows server appears to retry only to get STATUS_OBJECT_NAME_COLLISION.

If I enable "ea support" on the share there is no error. When I do the same actions from a Windows Server 2008 system the error does not occur and looking at the packet capture for that system in wireshark indicates that it tries to set the EAs in a later request, after the create file and data copy succeed.

I did a quick pass over the source code in this area and it looks like there is a call to set_ea within create_file_unixpath that is called after the file is created but will always fail due to ea support being disabled. My uneducated opinion (:-)) is that smbd ought to either check if EAs are enabled when ea_list is not NULL before creating the file or clean up the file if set_ea fails.
Comment 1 John Mulligan 2015-11-03 20:08:06 UTC
Created attachment 11573 [details]

"Just for fun" I built samba with the following patch applied, this appears to resolve the problem for me.
Comment 2 Jeremy Allison 2015-11-03 20:09:01 UTC
Oh that's a really good catch - thanks !
Comment 3 Jeremy Allison 2015-11-03 20:14:09 UTC
Your patch looks like the correct one to me. Can you give me permission to post to samba-technical with your Signed-off-by please ?


Comment 4 John Mulligan 2015-11-03 20:32:57 UTC
Certainly, however I'm not sure what the proper procedure is for the Signed-off-by...
If its just a matter of putting it here in a comment then:

Signed-off-by: John Mulligan <phlogistonjohn@asynchrono.us>

otherwise please let me know what it is. Thank You.
Comment 5 Jeremy Allison 2015-11-03 20:45:36 UTC
(In reply to John Mulligan from comment #4)

For this patch your comment here is enough - thanks ! If you want to do more Samba patching you might want to send in this form:


Just do it once and then you're good to go for all future patches !


Comment 6 Jeremy Allison 2015-11-04 22:08:13 UTC
Created attachment 11578 [details]
git-am fix for 4.3.next, 4.2.next.

This is what went into master cherry-picked for 4.3.next, 4.2.next.
Comment 7 Uri Simchoni 2015-11-05 04:17:42 UTC
Karolin, please add the patch to 4.2.next and 4.3.next branches. Thanks!
Comment 8 Karolin Seeger 2015-11-16 09:21:43 UTC
Pushed to autobuild-v4-[3|2]-test.
Comment 9 Karolin Seeger 2015-11-17 10:32:01 UTC
(In reply to Karolin Seeger from comment #8)
Pushed to both branches.
Closing out bug report.