[Samba] [PMX:##] Re: linux-to-linux samba weird problem

[Neal Murphy]

No ideas yet?

On Thursday, February 28, 2013 06:17:24 PM Neal Murphy wrote:
> 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