samba - Apr 2002 - Copy to Samba server fails for some files containing extended attributes, works to NT server

We have found the following problem copying some files containing extended
attributes to our Samba servers.  The problem happens on our Samba servers
running RedHat Linux 7.2 + Samba 2.2.3a sharing ext3 filesystems and the
ones running AIX 4.3.3 + Samba 2.2.2 sharing the AFS filesystem.  Copying
the files to an NT server works OK.  The failure only happens for some
files with extended attributes, I am still trying to find out how to look
at the attributes to see what is different about the files that fail.

In the following output j: is a drive mapped to my home directory on a
Samba server, v: is a drive mapped to my home directory on an NT server,
junk is a file that has no extended attributes.

      Y:\lanman>copy junk j:
              1 file(s) copied.

      Y:\lanman>copy Makefile j:
      Access is denied.
              0 file(s) copied.

      Y:\lanman>copy Makefile v:
              1 file(s) copied.

      Y:\lanman>


Here is what I see that looks interesting in the Samba logs:

[2002/04/19 15:58:42, 3] smbd/process.c:process_smb(860)
  Transaction 88 of length 186
[2002/04/19 15:58:42, 3] smbd/process.c:switch_message(667)
  switch message SMBnttrans (pid 5072)
[2002/04/19 15:58:42, 3] lib/util.c:unix_clean_name(387)
  unix_clean_name [/test/Makefile]
[2002/04/19 15:58:42, 3] smbd/dosmode.c:unix_mode(111)
  unix_mode(test/Makefile) returning 0744
[2002/04/19 15:58:42, 3] lib/util.c:unix_clean_name(387)
  unix_clean_name [test/Makefile]
[2002/04/19 15:58:42, 2] smbd/open.c:open_file(213)
  jpjanosi opened file test/Makefile read=No write=Yes (numopen=1)
[2002/04/19 15:58:42, 2] smbd/close.c:close_normal_file(210)
  rchdnt\jpjanosi closed file test/Makefile (numopen=0)
[2002/04/19 15:58:42, 3] smbd/error.c:error_packet(91)
  error string = Operation not permitted
[2002/04/19 15:58:42, 3] smbd/error.c:error_packet(99)
  error packet at smbd/nttrans.c(1399) cmd=160 (SMBnttrans)
NT_STATUS_INVALID_LOCK_SEQUENCE


Thanks for any suggestions for tracking down this problem,

John Janosik
jpjanosi@us.ibm.com