samba - Jun 2019 - error when trying to copy file from samba share to old Windows CE share

On Wed, Jun 19, 2019 at 2:57 PM Jeremy Allison <jra at samba.org>
wrote:
> Only wireshark traces and debug level 10 logs are
> going to help here I'm afraid.
I have the tcpdumps open in wireshark right now, and also have debug
10 logs. Do you want me to just email these directly to you or
something? I have been staring at wireshark for like 20 minutes now,
but don't really know what I am looking for. I have a dump of the same
file being transferred with the old samba vs new samba, but it looks
like they are currently using different protocol versions. I found the
packet where the data is being transferred and I can see a lot of
permission bits, etc.

Thanks,
Dan

On Wed, Jun 19, 2019 at 03:08:58PM -0400, Dan Arena
wrote:
> On Wed, Jun 19, 2019 at 2:57 PM Jeremy Allison <jra at samba.org>
wrote:
> > Only wireshark traces and debug level 10 logs are
> > going to help here I'm afraid.
> 
> I have the tcpdumps open in wireshark right now, and also have debug
> 10 logs. Do you want me to just email these directly to you or
> something? I have been staring at wireshark for like 20 minutes now,
> but don't really know what I am looking for. I have a dump of the same
> file being transferred with the old samba vs new samba, but it looks
> like they are currently using different protocol versions. I found the
> packet where the data is being transferred and I can see a lot of
> permission bits, etc.
Weren't you getting a NT_STATUS_NOT_IMPLEMENTED level
error return ?

Look for the specific error return you see on the WinCE
client in the trace.

On Wed, Jun 19, 2019 at 3:41 PM Jeremy Allison <jra at samba.org>
wrote:
> Weren't you getting a NT_STATUS_NOT_IMPLEMENTED level
> error return ?
>
> Look for the specific error return you see on the WinCE
> client in the trace.
Figured out the issue...

After comparing a good vs bad file copy in wireshark for a while, I
have found where it goes wrong. On the good copy I see an "NT Create
AndX Request" with a response that says it created the file. On the
bad copy it instead does a "NT Trans Request, NT CREATE" with an
additional "NT CREATE data" that has the SELinux context in it.
Comparing the old vs new smb.conf man page it looks like "ea support"
in the older samba version was default to no, while it is default to
yes in the newer samba version. Windows is some how storing those
extended attributes, and fails when trying to transfer a file with the
selinux extended attribute.

Setting "ea support = no" fixed the issue.

Thanks,
Dan