[Samba] linux-to-linux samba weird problem

[Neal Murphy]

On Wednesday, February 27, 2013 06:44:57 PM Jeremy Allison wrote:
> On Wed, Feb 27, 2013 at 04:00:23PM -0500, Neal Murphy wrote:
> > I've a weird problem with Samba. I'm using Samba to share a filesystem
> > between two linux systems because I believe I need byte range locking to
> > prevent multiple processes on different computers from reading/writing
> > the same ISAM records.
> > 
> > I have a Debian wheezy file server running Samba; no domain controller,
> > just a simple, single share. I have a debian wheezy KVM mounting a share
> > via CIFS, forcing UID and GID; UID/GID are the same on the two systems.
> > I use a credentials file with non-root user and password. I disabled
> > oplocks and client caching. The shared dir has ug+rw for all files, and
> > has ug+x for all dirs; the same non-root user and group owns all files
> > and dirs. I've even gone so far as to add ug+s on all dirs, to no avail.
> > General access seems to be OK. But there's a failure in one specific
> > instance.
> > 
> > On the KVM, I'm running unibasic (business basic). I wrote a program to
> > test record locking when reading indexed ISAM files. Running it on two
> > KVMs, I verified that record locking does work; the lock passed between
> > the two programs very nicely. But I encountered a problem when creating
> > indexed ISAM files.
> > 
> > When a UB program builds an indexed ISAM DB, it creates both a data file
> > and an index file on the file server. The problem is that it *always*
> > fails when a non-root user runs unibasic (it can't create the index
> > structure within the index file). But it succeeds when running the
> > program as root. Oddly, if I leave ug+s off the dirs on the server,
> > root:root will own one of the files in the pair (regardless of
> > forceuid/forcegid on the client mount).
> 
> How exactly does it fail ? This will help determine the problem.

Other than CIFS/Samba configs, here's all the information I have to provide at 
the moment; it *is* scanty. If tcpdump logs of failure (or even success) would 
be of help, I'll make them. But I'd have to scrub confidential data out. Or 
write a minimalist test case program.

The code snippet:
--------
  8680 SEARCH #N1,0,0;N$,R9,E
  8685 IF E=0 GOTO 8700
  8690 PRINT 'CR';"ERROR TYPE";E;"WHILE STRUCTURING DIRECTORIES"
  8695 STOP 
--------

The error is reported via E (E=5). From the manual:
      Indexed file structure error; given when key length DIM is less
      than the actual size of the key from an Index on Modes 2, 3, 6
      and 9. Indicates a DIMension error or structure problem, possibly
      a c-tree file structuring error. Printing the value of ERR(8) will
      provide a more concise description of the error.

The program's output:
--------
  ERROR TYPE 5 WHILE STRUCTURING DIRECTORIES


  STOP at statement: 8695;1 in: /srv/unibasic/data/1/ti.2preg

  close

  C-Tree Index File error; print ERR(8) for details, or var DIM < key len
--------

The available error #s (157, 110) index to the last line of output above; 157 
also indexes to "Data Read Error".

There is no related information in /var/log/* or /var/log/samba/* on either 
server or client. There are no related messages on the client's console; I 
don't have access to the server's console.

When viewed using 'od -c', the initial contents of the two files created (data 
and index) are reasonably similar to those created on the live system (running 
on SCO UNIX) and those created on this test system when root successfully runs 
the program.

There seems to be no problem when a non-root user reads existing ISAM data 
files, only when creating new ones.

Deep background: the program was written in 1985 and has been in constant use 
since. It ran on the original (Point 4?) Iris BASIC system, on the replacement 
DG NOVA, and via Unibasic on SCO UNIX and Linux.

Thanks!
Neal