[Samba] Re: locking.tdb: expand_file ftruncate to 8192 failed (Permission denied)

[Jeremy Allison]

On Thu, Sep 22, 2005 at 10:15:08AM +0200, Axel Thimm wrote:
> On Wed, Sep 21, 2005 at 04:34:32PM -0700, Jeremy Allison wrote:
> > On Thu, Sep 22, 2005 at 01:01:45AM +0200, Axel Thimm wrote:
> > > Should I generate a more verbose debug log (what log level
> > > settings?) and place it somewhere on the net?
> > > 
> > > I wonder how I'm triggering that code path, it certainly isn't seen by
> > > the typical RHEL4 installs. The lock directory is set to reside on a
> > > GFS filesystem, could that make a difference (shouldn't as it is
> > > supposed to be POSIX compliant local-fs-like filesystem)?
> > 
> > Oh almost certainly that's the problem. Did you test my test program
> > on a GFS filesystem ? Doesn't GFS use crypto credentials to prevent
> > people hijacking root ? If that's the case I bet they break POSIX
> > semantics w.r.t. this.
> > 
> > Why are you putting the locking db on a GFS filesystem anyway. That's
> > madness !
> 
> The reason is to have a poor-man's-clustered-samba by placing lock and
> private dir on a common share and have the relocated smbd/nmbd pairs
> access them. E.g. relocating within the cluster is effectively like
> restarting smbd/nmbd on a node.

That's never going to work (at least with acceptable speed). Talk
to Volker for details...
> 
> (gdb) run testfile thimm
> Starting program: /srv/physik.fu-berlin.de/data/samba-test/a.out testfile thimm
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
> (gdb) bt
> #0  0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
> #1  0x0000003e18a428dc in vfprintf () from /lib64/tls/libc.so.6
> #2  0x0000003e18a3f299 in buffered_vfprintf () from /lib64/tls/libc.so.6
> #3  0x0000003e18a3f479 in vfprintf () from /lib64/tls/libc.so.6
> #4  0x0000003e18a47d96 in fprintf () from /lib64/tls/libc.so.6
> #5  0x0000000000400b2b in main (argc=3, argv=0x7fbffff8a8) at test.c:55

Very strange - that's this line :

                fprintf(stderr, "failed to extend file %s - error %s\n",
                        argv[1], strerror(errno) );

I wonder if strerror is returning NULL ?

> > As I said, I bet GFS isn't POSIX complient. Don't put locking
> > tdb's on anything but local filesystems.
> 
> Well, GFS claims to be POSIX and local-like in any way. Maybe it is
> just a bug in GFS? Does POSIX ensure that you can open an fd under
> some user and not lose access right to the fd when dropping
> priviledges?

Yes. That's why we wrote it this way. It's a bug in GFS. Open it
with RedHat.

Jeremy.